From Dick.Waite at softwareag.com Mon Aug 25 04:02:45 2014 From: Dick.Waite at softwareag.com (Waite, Dick) Date: Mon, 25 Aug 2014 10:02:45 +0000 Subject: [sles-beta] Any Idea when VMware will officaly support SLES/SLED 12? Message-ID: <46AC8C81C10B8C48820201DF2AE1D76D67AE2377@hqmbx6.eur.ad.sag> Grand Day SUSE, As VMware are a good friends of SUSE, do you have a ball-park date when they will support SLES/SLED 12 officially. At GA date would be grand but will they have anything for us to try before GA. As we are under NDA I feel it?s not a question I should ask them. Your open-vm-tools do keep me in the ball game but they do not have the same API as VMware tools, so the VMware tools throw a wobbly and tell you to install their stuff. Your open-vm-tools give a nag saying ?You know this software is unsupported?, which is grand while we are Beta but that will not go down well when it?s GA. Do you have any ?white? papers on how to migrate items you have dropped support for? The one I have nagged on about and created a SR 10894124441 (bug 880111) and it?s answer was not much use telling me to read the new Docu, or create a new SR? Support means when you create something your customers use you can not just drop it, there has to be a time when the new is available and so is the old, so that people can migrate, or migrate it for them under the covers. There were features of CRON which keep the systems clean and tidy, Ship shape and Bristol fashion. I?m sure the new features you have introduce do a better job otherwise we would still have the old, so why not lets us have a simple A4 white paper showing how to migrate the CRON /tmp, /var/tmp and the other good stuff to the new way or even migrate them ;o) Okay? end of sermon. This week we will start testing the compatibility our SAG applications with SLES12-RC2, Java (IBM) 7 and gcc runtime. I?ll not run any new gcc builds. __R Software AG ? Sitz/Registered office: Uhlandstra?e 12, 64297 Darmstadt, Germany ? Registergericht/Commercial register: Darmstadt HRB 1562 - Vorstand/Management Board: Karl-Heinz Streibich (Vorsitzender/Chairman), Dr. Wolfram Jost, Arnd Zinnhardt; - Aufsichtsratsvorsitzender/Chairman of the Supervisory Board: Dr. Andreas Bereczky - http://www.softwareag.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tparker at cbnco.com Mon Aug 25 14:30:08 2014 From: tparker at cbnco.com (Tom Parker) Date: Mon, 25 Aug 2014 16:30:08 -0400 Subject: [sles-beta] iSCSI Boot (with be2iscsi) fails after changing default boot option Message-ID: <53FB9CD0.80905@cbnco.com> Hello I installed SLES 12 RC2 today on an HP BL420c server with be2iscsi offload cards (HP FlexFabric FLB554) and iscsi boot. They show in the BIOS as: 04:00.2 Mass storage controller: Emulex Corporation OneConnect 10Gb iSCSI Initiator (be3) (rev 01) 04:00.3 Mass storage controller: Emulex Corporation OneConnect 10Gb iSCSI Initiator (be3) (rev 01) The installation went cleanly as did the first reboot. I then decided to set the server to boot into XEN by default and ran yast2 bootloader to change the setting. I then restarted the server and got. "No system disk or disk error" and a PXE boot process. Has anyone else seen this? I have now repeated the installation again and got the same result: My installation steps were PXE Boot and install over HTTP Setup iSCSI disks (everything was autodetected from the offload cards) Setup network with eth0 and eth1 enslaved to bond0 and a static ip on bond0 Configure Software (remove Gnome, add Xen Virtual Machine Host Server) Disable Kdump Set Default Target to Text Mode Install... ........ The first reboot after install works properly but the network settings are mangled by the bridge config (unrelated to the boot problem but still a serious bug) and wicked won't start. I then run yast2 bootloader - Bootloader Options - Default Boot Section -> "SUSE Linux Enterprize Server 12 (RC2), with Xen hypervisor" - OK shutdown -r now No disk detected and PXE boot screen... I will now do my 3rd clean install and file a SR... Tom From kukuk at suse.de Tue Aug 26 07:31:45 2014 From: kukuk at suse.de (Thorsten Kukuk) Date: Tue, 26 Aug 2014 15:31:45 +0200 Subject: [sles-beta] SLES12 RC2 x86_64 Login possible even though autoyast init-script is still runing In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0F9D2BF6@HXMB12.pnet.ch> References: <40637DBB36AF3941B243A286A432CA0B0F9D2BF6@HXMB12.pnet.ch> Message-ID: <20140826133145.GA29287@suse.de> Hi, On Tue, Aug 26, urs.frey at post.ch wrote: > Hi > > When trying to install SLES12 Rc2 x86_64 using autoyast with init-scripts within autoinst.xml the installation process does not wait until init-script has terminated. > So I can already see the final login screen even though my init-script within autoinst.xml is still running Yes, that's the new world of systemd: start every service as early as possible in parallel. > I consider this as bug. > Please fix this within autoyast I'm not sure if there is anything autoyast can do here. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg) From jreidinger at suse.com Tue Aug 26 07:37:00 2014 From: jreidinger at suse.com (Josef Reidinger) Date: Tue, 26 Aug 2014 15:37:00 +0200 Subject: [sles-beta] SLES12 RC2 x86_64 Login possible even though autoyast init-script is still runing In-Reply-To: <20140826133145.GA29287@suse.de> References: <40637DBB36AF3941B243A286A432CA0B0F9D2BF6@HXMB12.pnet.ch> <20140826133145.GA29287@suse.de> Message-ID: <20140826153700.506936f1@dhcp150.suse.cz> On Tue, 26 Aug 2014 15:31:45 +0200 "Thorsten Kukuk" wrote: > > Hi, > > On Tue, Aug 26, urs.frey at post.ch wrote: > > > Hi > > > > When trying to install SLES12 Rc2 x86_64 using autoyast with > > init-scripts within autoinst.xml the installation process does not > > wait until init-script has terminated. So I can already see the > > final login screen even though my init-script within autoinst.xml > > is still running > > Yes, that's the new world of systemd: start every service as early as > possible in parallel. > > > I consider this as bug. > > Please fix this within autoyast > > I'm not sure if there is anything autoyast can do here. Well, autoyast can add login to list of services that should be run after its init script here https://github.com/yast/yast-autoinstallation/blob/master/scripts/autoyast-initscripts.service#L3 Currently it lists only some specific stuff, that can be ignored on target device. So it is possible if it is consider as requested behavior to run scripts before login prompt. Josef > > Thorsten > From urs.frey at post.ch Tue Aug 26 07:43:42 2014 From: urs.frey at post.ch (urs.frey at post.ch) Date: Tue, 26 Aug 2014 13:43:42 +0000 Subject: [sles-beta] SLES12 RC2 x86_64 Login possible even though autoyast init-script is still runing In-Reply-To: <20140826133145.GA29287@suse.de> References: <40637DBB36AF3941B243A286A432CA0B0F9D2BF6@HXMB12.pnet.ch> <20140826133145.GA29287@suse.de> Message-ID: <40637DBB36AF3941B243A286A432CA0B0F9D2C28@HXMB12.pnet.ch> Hello Thorsten Thank you for your information. There may be one thing to consider: Until now I have in my autoinst.xml these entries under the tag multi-user at cron nscd openct postfix rsyslog sshd systemd-readahead-collect systemd-readahead-replay wicked wickedd-auto4 wickedd-dhcp4 wickedd-dhcp6 wickedd-nanny wickedd So I suppose, all these services get started. But if I do not define services here but script the startup at the end of my autoinst.xml init-script, I may get what I am looking for. But anyway: When there is no more synchronization possible between autoinst init-script and start of system services, just this autoinst init-script possibility gets useless and could be thrown out. >From my point of view, to have the possibility to run a fully unattended installation, the possibility to run autoinst init-script without user login is already allowed, is a basic need. Best regards Urs Frey????????????????????????????????????????????? Post CH AG Informationstechnologie IT Betrieb Webergutstrasse 12 3030 Bern (Zollikofen) Telefon : ++41 (0)58 338 58 70 FAX???? : ++41 (0)58 667 30 07 E-Mail:?? urs.frey at post.ch -----Urspr?ngliche Nachricht----- Von: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] Im Auftrag von Thorsten Kukuk Gesendet: Tuesday, August 26, 2014 3:32 PM An: sles-beta at lists.suse.com Betreff: Re: [sles-beta] SLES12 RC2 x86_64 Login possible even though autoyast init-script is still runing Hi, On Tue, Aug 26, urs.frey at post.ch wrote: > Hi > > When trying to install SLES12 Rc2 x86_64 using autoyast with init-scripts within autoinst.xml the installation process does not wait until init-script has terminated. > So I can already see the final login screen even though my init-script within autoinst.xml is still running Yes, that's the new world of systemd: start every service as early as possible in parallel. > I consider this as bug. > Please fix this within autoyast I'm not sure if there is anything autoyast can do here. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg) _______________________________________________ sles-beta mailing list sles-beta at lists.suse.com http://lists.suse.com/mailman/listinfo/sles-beta From urs.frey at post.ch Tue Aug 26 07:51:04 2014 From: urs.frey at post.ch (urs.frey at post.ch) Date: Tue, 26 Aug 2014 13:51:04 +0000 Subject: [sles-beta] SLES12 RC2 x86_64 Login possible even though autoyast init-script is still runing In-Reply-To: <20140826153700.506936f1@dhcp150.suse.cz> References: <40637DBB36AF3941B243A286A432CA0B0F9D2BF6@HXMB12.pnet.ch> <20140826133145.GA29287@suse.de> <20140826153700.506936f1@dhcp150.suse.cz> Message-ID: <40637DBB36AF3941B243A286A432CA0B0F9D2C39@HXMB12.pnet.ch> Hello Josef I do not understand what you exactly mean I need to run / free user login after successful termination of autoinst init-script But as far as I understand the unit file, the initscript runs after the listed services below h05cni:~ # cat /usr/lib/systemd/system/autoyast-initscripts.service [Unit] Description=Autoyast2 Init Scripts After=remote-fs.target network.target time-sync.target mail-transfer-agent.target hwscan.service ypbind.service YaST2-Second-Stage.service [Service] Type=oneshot Environment=TERM=linux ExecStartPre=-/usr/bin/plymouth --hide-splash ExecStart=/usr/lib/YaST2/bin/autoyast-initscripts.sh RemainAfterExit=yes TimeoutSec=0 [Install] WantedBy=default.target h05cni:~ # So I guess, this one here should be modified to run after init-script during installation using autoyast h05cni:~ # cat /usr/lib/systemd/system/systemd-logind.service # This file is part of systemd. # # systemd is free software; you can redistribute it and/or modify it # under the terms of the GNU Lesser General Public License as published by # the Free Software Foundation; either version 2.1 of the License, or # (at your option) any later version. [Unit] Description=Login Service Documentation=man:systemd-logind.service(8) man:logind.conf(5) Documentation=http://www.freedesktop.org/wiki/Software/systemd/logind Documentation=http://www.freedesktop.org/wiki/Software/systemd/multiseat Wants=user.slice After=nss-user-lookup.target user.slice # Ask for the dbus socket. If running over kdbus, the socket will # not be actually used. Wants=dbus.socket After=dbus.socket [Service] ExecStart=/usr/lib/systemd/systemd-logind Restart=always RestartSec=0 BusName=org.freedesktop.login1 CapabilityBoundingSet=CAP_SYS_ADMIN CAP_AUDIT_CONTROL CAP_CHOWN CAP_KILL CAP_DAC_READ_SEARCH CAP_DAC_OVERRIDE CAP_FOWNER CAP_SYS_TTY_CONFIG WatchdogSec=1min # Increase the default a bit in order to allow many simultaneous # logins since we keep one fd open per session. LimitNOFILE=16384 h05cni:~ # regards Urs Frey????????????????????????????????????????????? Post CH AG Informationstechnologie IT Betrieb Webergutstrasse 12 3030 Bern (Zollikofen) Telefon : ++41 (0)58 338 58 70 FAX???? : ++41 (0)58 667 30 07 E-Mail:?? urs.frey at post.ch -----Urspr?ngliche Nachricht----- Von: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] Im Auftrag von Josef Reidinger Gesendet: Tuesday, August 26, 2014 3:37 PM An: sles-beta at lists.suse.com Betreff: Re: [sles-beta] SLES12 RC2 x86_64 Login possible even though autoyast init-script is still runing On Tue, 26 Aug 2014 15:31:45 +0200 "Thorsten Kukuk" wrote: > > Hi, > > On Tue, Aug 26, urs.frey at post.ch wrote: > > > Hi > > > > When trying to install SLES12 Rc2 x86_64 using autoyast with > > init-scripts within autoinst.xml the installation process does not > > wait until init-script has terminated. So I can already see the > > final login screen even though my init-script within autoinst.xml > > is still running > > Yes, that's the new world of systemd: start every service as early as > possible in parallel. > > > I consider this as bug. > > Please fix this within autoyast > > I'm not sure if there is anything autoyast can do here. Well, autoyast can add login to list of services that should be run after its init script here https://github.com/yast/yast-autoinstallation/blob/master/scripts/autoyast-initscripts.service#L3 Currently it lists only some specific stuff, that can be ignored on target device. So it is possible if it is consider as requested behavior to run scripts before login prompt. Josef > > Thorsten > _______________________________________________ sles-beta mailing list sles-beta at lists.suse.com http://lists.suse.com/mailman/listinfo/sles-beta From jreidinger at suse.cz Tue Aug 26 07:57:28 2014 From: jreidinger at suse.cz (Josef Reidinger) Date: Tue, 26 Aug 2014 15:57:28 +0200 Subject: [sles-beta] SLES12 RC2 x86_64 Login possible even though autoyast init-script is still runing In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0F9D2C39@HXMB12.pnet.ch> References: <40637DBB36AF3941B243A286A432CA0B0F9D2BF6@HXMB12.pnet.ch> <20140826133145.GA29287@suse.de> <20140826153700.506936f1@dhcp150.suse.cz> <40637DBB36AF3941B243A286A432CA0B0F9D2C39@HXMB12.pnet.ch> Message-ID: <20140826155728.76851414@dhcp150.suse.cz> Hi Urs, you can modify autoyast-initscripts.service itself if you add in Unit "Before" part with required service which is in your case systemd-logind.service [1]. Question is if we can do it for everyone and change default. Josef [1] http://www.freedesktop.org/software/systemd/man/systemd.unit.html#Before= On Tue, 26 Aug 2014 13:51:04 +0000 wrote: > Hello Josef > > I do not understand what you exactly mean > I need to run / free user login after successful termination of > autoinst init-script But as far as I understand the unit file, the > initscript runs after the listed services below > > h05cni:~ # cat /usr/lib/systemd/system/autoyast-initscripts.service > [Unit] > Description=Autoyast2 Init Scripts > After=remote-fs.target network.target time-sync.target > mail-transfer-agent.target hwscan.service ypbind.service > YaST2-Second-Stage.service > > [Service] > Type=oneshot > Environment=TERM=linux > ExecStartPre=-/usr/bin/plymouth --hide-splash > ExecStart=/usr/lib/YaST2/bin/autoyast-initscripts.sh > RemainAfterExit=yes > TimeoutSec=0 > > [Install] > WantedBy=default.target > > h05cni:~ # > > So I guess, this one here should be modified to run after init-script > during installation using autoyast > > h05cni:~ # cat /usr/lib/systemd/system/systemd-logind.service > # This file is part of systemd. > # > # systemd is free software; you can redistribute it and/or modify it > # under the terms of the GNU Lesser General Public License as > published by # the Free Software Foundation; either version 2.1 of > the License, or # (at your option) any later version. > > [Unit] > Description=Login Service > Documentation=man:systemd-logind.service(8) man:logind.conf(5) > Documentation=http://www.freedesktop.org/wiki/Software/systemd/logind > Documentation=http://www.freedesktop.org/wiki/Software/systemd/multiseat > Wants=user.slice > After=nss-user-lookup.target user.slice > > # Ask for the dbus socket. If running over kdbus, the socket will > # not be actually used. > Wants=dbus.socket > After=dbus.socket > > [Service] > ExecStart=/usr/lib/systemd/systemd-logind > Restart=always > RestartSec=0 > BusName=org.freedesktop.login1 > CapabilityBoundingSet=CAP_SYS_ADMIN CAP_AUDIT_CONTROL CAP_CHOWN > CAP_KILL CAP_DAC_READ_SEARCH CAP_DAC_OVERRIDE CAP_FOWNER > CAP_SYS_TTY_CONFIG WatchdogSec=1min > > # Increase the default a bit in order to allow many simultaneous > # logins since we keep one fd open per session. > LimitNOFILE=16384 > h05cni:~ # > > regards > > > Urs Frey????????????????????????????????????????????? > Post CH AG > Informationstechnologie > IT Betrieb > Webergutstrasse 12 > 3030 Bern (Zollikofen) > Telefon : ++41 (0)58 338 58 70 > FAX???? : ++41 (0)58 667 30 07 > E-Mail:?? urs.frey at post.ch > > > -----Urspr?ngliche Nachricht----- > Von: sles-beta-bounces at lists.suse.com > [mailto:sles-beta-bounces at lists.suse.com] Im Auftrag von Josef > Reidinger Gesendet: Tuesday, August 26, 2014 3:37 PM An: > sles-beta at lists.suse.com Betreff: Re: [sles-beta] SLES12 RC2 x86_64 > Login possible even though autoyast init-script is still runing > > On Tue, 26 Aug 2014 15:31:45 +0200 > "Thorsten Kukuk" wrote: > > > > > Hi, > > > > On Tue, Aug 26, urs.frey at post.ch wrote: > > > > > Hi > > > > > > When trying to install SLES12 Rc2 x86_64 using autoyast with > > > init-scripts within autoinst.xml the installation process does not > > > wait until init-script has terminated. So I can already see the > > > final login screen even though my init-script within autoinst.xml > > > is still running > > > > Yes, that's the new world of systemd: start every service as early > > as possible in parallel. > > > > > I consider this as bug. > > > Please fix this within autoyast > > > > I'm not sure if there is anything autoyast can do here. > > Well, autoyast can add login to list of services that should be run > after its init script here > https://github.com/yast/yast-autoinstallation/blob/master/scripts/autoyast-initscripts.service#L3 > Currently it lists only some specific stuff, that can be ignored on > target device. So it is possible if it is consider as requested > behavior to run scripts before login prompt. > > Josef > > > > > Thorsten > > > > _______________________________________________ > sles-beta mailing list > sles-beta at lists.suse.com > http://lists.suse.com/mailman/listinfo/sles-beta > From urs.frey at post.ch Tue Aug 26 08:10:50 2014 From: urs.frey at post.ch (urs.frey at post.ch) Date: Tue, 26 Aug 2014 14:10:50 +0000 Subject: [sles-beta] SLES12 RC2 x86_64 Login possible even though autoyast init-script is still runing In-Reply-To: <20140826155728.76851414@dhcp150.suse.cz> References: <40637DBB36AF3941B243A286A432CA0B0F9D2BF6@HXMB12.pnet.ch> <20140826133145.GA29287@suse.de> <20140826153700.506936f1@dhcp150.suse.cz> <40637DBB36AF3941B243A286A432CA0B0F9D2C39@HXMB12.pnet.ch> <20140826155728.76851414@dhcp150.suse.cz> Message-ID: <40637DBB36AF3941B243A286A432CA0B0F9D2C72@HXMB12.pnet.ch> Hi Josef This would mean, that when entering autoinst init-script I would have to modify /usr/lib/systemd/system/autoyast-initscripts.service With the additional line h05cni:~ # cat /usr/lib/systemd/system/autoyast-initscripts.service [Unit] Description=Autoyast2 Init Scripts After=remote-fs.target network.target time-sync.target mail-transfer-agent.target hwscan.service ypbind.service YaST2-Second-Stage.service Before= systemd-logind.target [Service] Type=oneshot Environment=TERM=linux ExecStartPre=-/usr/bin/plymouth --hide-splash ExecStart=/usr/lib/YaST2/bin/autoyast-initscripts.sh RemainAfterExit=yes TimeoutSec=0 [Install] WantedBy=default.target h05cni:~ # Then reload/refresh systemd Because autoyast-init script does run only once I my leave it as is Maybe this is the systemD way Will have to test and go into it. Anyway again: Allowing login and this way pretending, the installation has already terminated is very ugly and really not for professional use. regards Urs Frey????????????????????????????????????????????? Post CH AG Informationstechnologie IT Betrieb Webergutstrasse 12 3030 Bern (Zollikofen) Telefon : ++41 (0)58 338 58 70 FAX???? : ++41 (0)58 667 30 07 E-Mail:?? urs.frey at post.ch -----Urspr?ngliche Nachricht----- Von: Josef Reidinger [mailto:jreidinger at suse.cz] Gesendet: Tuesday, August 26, 2014 3:57 PM An: Frey Urs, IT222 Cc: sles-beta at lists.suse.com Betreff: Re: [sles-beta] SLES12 RC2 x86_64 Login possible even though autoyast init-script is still runing Hi Urs, you can modify autoyast-initscripts.service itself if you add in Unit "Before" part with required service which is in your case systemd-logind.service [1]. Question is if we can do it for everyone and change default. Josef [1] http://www.freedesktop.org/software/systemd/man/systemd.unit.html#Before= On Tue, 26 Aug 2014 13:51:04 +0000 wrote: > Hello Josef > > I do not understand what you exactly mean > I need to run / free user login after successful termination of > autoinst init-script But as far as I understand the unit file, the > initscript runs after the listed services below > > h05cni:~ # cat /usr/lib/systemd/system/autoyast-initscripts.service > [Unit] > Description=Autoyast2 Init Scripts > After=remote-fs.target network.target time-sync.target > mail-transfer-agent.target hwscan.service ypbind.service > YaST2-Second-Stage.service > > [Service] > Type=oneshot > Environment=TERM=linux > ExecStartPre=-/usr/bin/plymouth --hide-splash > ExecStart=/usr/lib/YaST2/bin/autoyast-initscripts.sh > RemainAfterExit=yes > TimeoutSec=0 > > [Install] > WantedBy=default.target > > h05cni:~ # > > So I guess, this one here should be modified to run after init-script > during installation using autoyast > > h05cni:~ # cat /usr/lib/systemd/system/systemd-logind.service > # This file is part of systemd. > # > # systemd is free software; you can redistribute it and/or modify it > # under the terms of the GNU Lesser General Public License as > published by # the Free Software Foundation; either version 2.1 of > the License, or # (at your option) any later version. > > [Unit] > Description=Login Service > Documentation=man:systemd-logind.service(8) man:logind.conf(5) > Documentation=http://www.freedesktop.org/wiki/Software/systemd/logind > Documentation=http://www.freedesktop.org/wiki/Software/systemd/multiseat > Wants=user.slice > After=nss-user-lookup.target user.slice > > # Ask for the dbus socket. If running over kdbus, the socket will > # not be actually used. > Wants=dbus.socket > After=dbus.socket > > [Service] > ExecStart=/usr/lib/systemd/systemd-logind > Restart=always > RestartSec=0 > BusName=org.freedesktop.login1 > CapabilityBoundingSet=CAP_SYS_ADMIN CAP_AUDIT_CONTROL CAP_CHOWN > CAP_KILL CAP_DAC_READ_SEARCH CAP_DAC_OVERRIDE CAP_FOWNER > CAP_SYS_TTY_CONFIG WatchdogSec=1min > > # Increase the default a bit in order to allow many simultaneous > # logins since we keep one fd open per session. > LimitNOFILE=16384 > h05cni:~ # > > regards > > > Urs Frey????????????????????????????????????????????? > Post CH AG > Informationstechnologie > IT Betrieb > Webergutstrasse 12 > 3030 Bern (Zollikofen) > Telefon : ++41 (0)58 338 58 70 > FAX???? : ++41 (0)58 667 30 07 > E-Mail:?? urs.frey at post.ch > > > -----Urspr?ngliche Nachricht----- > Von: sles-beta-bounces at lists.suse.com > [mailto:sles-beta-bounces at lists.suse.com] Im Auftrag von Josef > Reidinger Gesendet: Tuesday, August 26, 2014 3:37 PM An: > sles-beta at lists.suse.com Betreff: Re: [sles-beta] SLES12 RC2 x86_64 > Login possible even though autoyast init-script is still runing > > On Tue, 26 Aug 2014 15:31:45 +0200 > "Thorsten Kukuk" wrote: > > > > > Hi, > > > > On Tue, Aug 26, urs.frey at post.ch wrote: > > > > > Hi > > > > > > When trying to install SLES12 Rc2 x86_64 using autoyast with > > > init-scripts within autoinst.xml the installation process does not > > > wait until init-script has terminated. So I can already see the > > > final login screen even though my init-script within autoinst.xml > > > is still running > > > > Yes, that's the new world of systemd: start every service as early > > as possible in parallel. > > > > > I consider this as bug. > > > Please fix this within autoyast > > > > I'm not sure if there is anything autoyast can do here. > > Well, autoyast can add login to list of services that should be run > after its init script here > https://github.com/yast/yast-autoinstallation/blob/master/scripts/autoyast-initscripts.service#L3 > Currently it lists only some specific stuff, that can be ignored on > target device. So it is possible if it is consider as requested > behavior to run scripts before login prompt. > > Josef > > > > > Thorsten > > > > _______________________________________________ > sles-beta mailing list > sles-beta at lists.suse.com > http://lists.suse.com/mailman/listinfo/sles-beta > From fcrozat at suse.com Tue Aug 26 08:19:58 2014 From: fcrozat at suse.com (Frederic Crozat) Date: Tue, 26 Aug 2014 16:19:58 +0200 Subject: [sles-beta] SLES12 RC2 x86_64 Login possible even though autoyast init-script is still runing In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0F9D2C72@HXMB12.pnet.ch> References: <40637DBB36AF3941B243A286A432CA0B0F9D2BF6@HXMB12.pnet.ch> <20140826133145.GA29287@suse.de> <20140826153700.506936f1@dhcp150.suse.cz> <40637DBB36AF3941B243A286A432CA0B0F9D2C39@HXMB12.pnet.ch> <20140826155728.76851414@dhcp150.suse.cz> <40637DBB36AF3941B243A286A432CA0B0F9D2C72@HXMB12.pnet.ch> Message-ID: <1409062798.22664.50.camel@par-r81vxc7.par.novell.com> Le mardi 26 ao?t 2014 ? 14:10 +0000, urs.frey at post.ch a ?crit : > Hi Josef > > This would mean, that when entering autoinst init-script I would have to modify > /usr/lib/systemd/system/autoyast-initscripts.service Just a general note regarding systemd service: Never ever modify a file in /usr/lib/systemd/system .. Instead, either: - create a copy in /etc/systemd/systemd, modify it there or - if you just need to add lines, create a file: /etc/systemd/system/name_of_the_service_file.d/foo.conf and in the file, add the lines you want like this: [Unit] my_additional_lines.. [Service] my_other_lines.. After any of those changes, run "systemctl daemon-reload" to have them used by systemd. -- Frederic Crozat Project Manager Enterprise Desktop SUSE From gregg at ricis.com Tue Aug 26 11:51:00 2014 From: gregg at ricis.com (Gregory D. Rosenberg) Date: Tue, 26 Aug 2014 12:51:00 -0500 Subject: [sles-beta] SLES12 RC2 x86_64 Login possible even though autoyast init-script is still runing In-Reply-To: <20140826133145.GA29287@suse.de> References: <40637DBB36AF3941B243A286A432CA0B0F9D2BF6@HXMB12.pnet.ch> <20140826133145.GA29287@suse.de> Message-ID: <170030E5-EB23-41C2-86DC-2C9380E2A343@ricis.com> Good afternoon, Surely there is still the notion of dependancies. You obviously will run into many issues without dependancies. Sure it would be OK to start services in parallel that depend on the network service, but starting them ahead of time would like cause many to fail. Is there a mechanism to deal with this potential mayhem? On Aug 26, 2014, at 08:31 CDT, Thorsten Kukuk wrote: > > Hi, > > On Tue, Aug 26, urs.frey at post.ch wrote: > >> Hi >> >> When trying to install SLES12 Rc2 x86_64 using autoyast with init-scripts within autoinst.xml the installation process does not wait until init-script has terminated. >> So I can already see the final login screen even though my init-script within autoinst.xml is still running > > Yes, that's the new world of systemd: start every service as early as > possible in parallel. > >> I consider this as bug. >> Please fix this within autoyast > > I'm not sure if there is anything autoyast can do here. > > Thorsten > > -- > Thorsten Kukuk, Senior Architect SLES & Common Code Base > SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg > GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg) > _______________________________________________ > sles-beta mailing list > sles-beta at lists.suse.com > http://lists.suse.com/mailman/listinfo/sles-beta P.S. Text the word BLIND to 85944 to donate $10 to the NFB Imagination Fund via your phone bill. The National Federation of the Blind knows that blindness is not the characteristic that defines you or your future. Every day we raise the expectations of blind people, because low expectations create obstacles between blind people and our dreams. You can have the life you want; blindness is not what holds you back. -- 73' & 75' Gregory D. Rosenberg AB9MZ gregg at ricis.com RICIS, Inc. 7849 Bristol Park Drive Tinley Park, IL 60477-4594 http://www.ricis.com 708-267-6664 Cell 708-444-2690 Office 708-444-1115 Fax (Please call before sending a fax) From urs.frey at post.ch Wed Aug 27 02:38:37 2014 From: urs.frey at post.ch (urs.frey at post.ch) Date: Wed, 27 Aug 2014 08:38:37 +0000 Subject: [sles-beta] SLES12 RC2 x86_64 Login possible even though autoyast init-script is still runing In-Reply-To: <20140826155728.76851414@dhcp150.suse.cz> References: <40637DBB36AF3941B243A286A432CA0B0F9D2BF6@HXMB12.pnet.ch> <20140826133145.GA29287@suse.de> <20140826153700.506936f1@dhcp150.suse.cz> <40637DBB36AF3941B243A286A432CA0B0F9D2C39@HXMB12.pnet.ch> <20140826155728.76851414@dhcp150.suse.cz> Message-ID: <40637DBB36AF3941B243A286A432CA0B0F9D2DFB@HXMB12.pnet.ch> Hello Josef I tried to modify /usr/lib/systemd/system/autoyast-initscripts.service and to set a Before= into the unit file (I know from Frederic: NEVER-Ever do modify under /usr/lib...! but just to test and on the search for a method...) h05cnh:/var/adm/autoinstall/logs # cat /usr/lib/systemd/system/autoyast-initscripts.service [Unit] Description=Autoyast2 Init Scripts After=remote-fs.target network.target time-sync.target mail-transfer-agent.target hwscan.service ypbind.service YaST2-Second-Stage.service Before=systemd-logind.service [Service] Type=oneshot Environment=TERM=linux ExecStartPre=-/usr/bin/plymouth --hide-splash ExecStart=/usr/lib/YaST2/bin/autoyast-initscripts.sh RemainAfterExit=yes TimeoutSec=0 [Install] WantedBy=default.target h05cnh:/var/adm/autoinstall/logs # BUT with this method only, I get the console login Prompt all-the same long before the autoinst init-script has terminated. ======================== So I got the idea, to simply disable system-logind at the begin of my autoinst init-script and re-enable at the end of my autoinst init-script It is easy to reproduce with autoyast. I try to disable the console login prompt, the my init-script does wait for 5min and should re-enable and finally show the console prompt after terminating my init-script. ================================= Unfortunately I got these error messages in my init-script.sh.log Logfile h05cnh:/var/adm/autoinstall/logs # cat init-script.sh.log + logdir=/var/adm/autoinstall/logs + logf=/var/adm/autoinstall/logs/init-script.sh.log + systemctl status systemd-logind systemd-logind.service - Login Service Loaded: loaded (/usr/lib/systemd/system/systemd-logind.service; static) Active: active (running) since Wed 2014-08-27 08:13:59 CEST; 2h 0min ago Docs: man:systemd-logind.service(8) man:logind.conf(5) http://www.freedesktop.org/wiki/Software/systemd/logind http://www.freedesktop.org/wiki/Software/systemd/multiseat Main PID: 10059 (systemd-logind) Status: "Processing requests..." CGroup: /system.slice/systemd-logind.service ??10059 /usr/lib/systemd/systemd-logind Aug 27 08:13:59 h05cnh systemd[1]: Started Login Service. Aug 27 08:13:59 h05cnh systemd-logind[10059]: New seat seat0. Aug 27 08:13:59 h05cnh systemd-logind[10059]: Watching system buttons on /dev/input/event2 (Power Button) + systemctl disable systemd-logind + systemctl stop systemd-logind +sleep 300 + systemctl enable systemd-logind The unit files have no [Install] section. They are not meant to be enabled using systemctl. Possible reasons for having this kind of units are: 1) A unit may be statically enabled by being symlinked from another unit's .wants/ or .requires/ directory. 2) A unit's purpose may be to act as a helper for some other unit which has a requirement dependency on it. 3) A unit may be started when needed via activation (socket, path, timer, D-Bus, udev, scripted systemctl call, ...). + systemctl start systemd-logind Job for systemd-logind.service canceled. + systemctl status systemd-logind h05cnh:/var/adm/autoinstall/logs # And I got the root console login prompt anyway, even though syewstemd-logind was dead (with systemctl status system-logind) So from my point of view the proper function of autoinst init-script is not given. This is really a bad situation. So I really need to run autoinst init-script without the possibility of already open root console login The problem is, that when trying to install software using zypper within autoinst post-script phase, zypper is locked by y2base process and zypper is not available Error: Could not update: Execution of '/usr/bin/zypper --quiet install --auto-agree-with-licenses --no-confirm pst-rubygem-stomp' returned 7: System management is locked by the application with pid 4778 (y2base). Close this application before trying again. Wrapped exception: Execution of '/usr/bin/zypper --quiet install --auto-agree-with-licenses --no-confirm pst-rubygem-stomp' returned 7: System management is locked by the application with pid 4778 (y2base). Close this application before trying again. Error: /Stage[main]/Admin::Mcollective/Package[pst-rubygem-stomp]/ensure: change from absent to latest failed: Could not update: Execution of ' /usr/bin/zypper --quiet install --auto-agree-with-licenses --no-confirm pst-rubygem-stomp' returned 7: System management is locked by the application with pid 4778 (y2base). Close this application before trying again. So within the autoyast process: post-script: zypper not usable because of being locked by y2base init-script: zypper usable, bat login already open, leading to early logins by inpatient installing operators. From my point of view the autoyast process itself has to be carefully reviewed in the context of systemD. It has become unusable now Maybe you have some ideas ?? Thank you very much for your feedback regards Urs Frey????????????????????????????????????????????? Post CH AG Informationstechnologie IT Betrieb Webergutstrasse 12 3030 Bern (Zollikofen) Telefon : ++41 (0)58 338 58 70 FAX???? : ++41 (0)58 667 30 07 E-Mail:?? urs.frey at post.ch -----Urspr?ngliche Nachricht----- Von: Josef Reidinger [mailto:jreidinger at suse.cz] Gesendet: Tuesday, August 26, 2014 3:57 PM An: Frey Urs, IT222 Cc: sles-beta at lists.suse.com Betreff: Re: [sles-beta] SLES12 RC2 x86_64 Login possible even though autoyast init-script is still runing Hi Urs, you can modify autoyast-initscripts.service itself if you add in Unit "Before" part with required service which is in your case systemd-logind.service [1]. Question is if we can do it for everyone and change default. Josef [1] http://www.freedesktop.org/software/systemd/man/systemd.unit.html#Before= On Tue, 26 Aug 2014 13:51:04 +0000 wrote: > Hello Josef > > I do not understand what you exactly mean > I need to run / free user login after successful termination of > autoinst init-script But as far as I understand the unit file, the > initscript runs after the listed services below > > h05cni:~ # cat /usr/lib/systemd/system/autoyast-initscripts.service > [Unit] > Description=Autoyast2 Init Scripts > After=remote-fs.target network.target time-sync.target > mail-transfer-agent.target hwscan.service ypbind.service > YaST2-Second-Stage.service > > [Service] > Type=oneshot > Environment=TERM=linux > ExecStartPre=-/usr/bin/plymouth --hide-splash > ExecStart=/usr/lib/YaST2/bin/autoyast-initscripts.sh > RemainAfterExit=yes > TimeoutSec=0 > > [Install] > WantedBy=default.target > > h05cni:~ # > > So I guess, this one here should be modified to run after init-script > during installation using autoyast > > h05cni:~ # cat /usr/lib/systemd/system/systemd-logind.service > # This file is part of systemd. > # > # systemd is free software; you can redistribute it and/or modify it > # under the terms of the GNU Lesser General Public License as > published by # the Free Software Foundation; either version 2.1 of > the License, or # (at your option) any later version. > > [Unit] > Description=Login Service > Documentation=man:systemd-logind.service(8) man:logind.conf(5) > Documentation=http://www.freedesktop.org/wiki/Software/systemd/logind > Documentation=http://www.freedesktop.org/wiki/Software/systemd/multiseat > Wants=user.slice > After=nss-user-lookup.target user.slice > > # Ask for the dbus socket. If running over kdbus, the socket will > # not be actually used. > Wants=dbus.socket > After=dbus.socket > > [Service] > ExecStart=/usr/lib/systemd/systemd-logind > Restart=always > RestartSec=0 > BusName=org.freedesktop.login1 > CapabilityBoundingSet=CAP_SYS_ADMIN CAP_AUDIT_CONTROL CAP_CHOWN > CAP_KILL CAP_DAC_READ_SEARCH CAP_DAC_OVERRIDE CAP_FOWNER > CAP_SYS_TTY_CONFIG WatchdogSec=1min > > # Increase the default a bit in order to allow many simultaneous > # logins since we keep one fd open per session. > LimitNOFILE=16384 > h05cni:~ # > > regards > > > Urs Frey????????????????????????????????????????????? > Post CH AG > Informationstechnologie > IT Betrieb > Webergutstrasse 12 > 3030 Bern (Zollikofen) > Telefon : ++41 (0)58 338 58 70 > FAX???? : ++41 (0)58 667 30 07 > E-Mail:?? urs.frey at post.ch > > > -----Urspr?ngliche Nachricht----- > Von: sles-beta-bounces at lists.suse.com > [mailto:sles-beta-bounces at lists.suse.com] Im Auftrag von Josef > Reidinger Gesendet: Tuesday, August 26, 2014 3:37 PM An: > sles-beta at lists.suse.com Betreff: Re: [sles-beta] SLES12 RC2 x86_64 > Login possible even though autoyast init-script is still runing > > On Tue, 26 Aug 2014 15:31:45 +0200 > "Thorsten Kukuk" wrote: > > > > > Hi, > > > > On Tue, Aug 26, urs.frey at post.ch wrote: > > > > > Hi > > > > > > When trying to install SLES12 Rc2 x86_64 using autoyast with > > > init-scripts within autoinst.xml the installation process does not > > > wait until init-script has terminated. So I can already see the > > > final login screen even though my init-script within autoinst.xml > > > is still running > > > > Yes, that's the new world of systemd: start every service as early > > as possible in parallel. > > > > > I consider this as bug. > > > Please fix this within autoyast > > > > I'm not sure if there is anything autoyast can do here. > > Well, autoyast can add login to list of services that should be run > after its init script here > https://github.com/yast/yast-autoinstallation/blob/master/scripts/autoyast-initscripts.service#L3 > Currently it lists only some specific stuff, that can be ignored on > target device. So it is possible if it is consider as requested > behavior to run scripts before login prompt. > > Josef > > > > > Thorsten > > > > _______________________________________________ > sles-beta mailing list > sles-beta at lists.suse.com > http://lists.suse.com/mailman/listinfo/sles-beta > From rbrown at suse.de Wed Aug 27 02:51:41 2014 From: rbrown at suse.de (Richard Brown) Date: Wed, 27 Aug 2014 10:51:41 +0200 Subject: [sles-beta] SLES12 RC2 x86_64 Login possible even though autoyast init-script is still runing In-Reply-To: <170030E5-EB23-41C2-86DC-2C9380E2A343@ricis.com> References: <40637DBB36AF3941B243A286A432CA0B0F9D2BF6@HXMB12.pnet.ch> <20140826133145.GA29287@suse.de> <170030E5-EB23-41C2-86DC-2C9380E2A343@ricis.com> Message-ID: <1409129501.18622.11.camel@ibrokeit.suse.de> On Tue, 2014-08-26 at 12:51 -0500, Gregory D. Rosenberg wrote: > Good afternoon, > > Surely there is still the notion of dependancies. You obviously will run into many issues without dependancies. Sure it would be OK to start services in parallel that depend on the network service, but starting them ahead of time would like cause many to fail. Is there a mechanism to deal with this potential mayhem? > Yes, systemd has much more robust understanding of dependencies than sysVinit Each service can define what it "requires" (Hard dependencies, Service A will not start without Service B, defined by adding "Requires= $otherService" in the appropriate .service file) as well as what it "wants" (Soft dependencies, Service A will still be able to start, but will require Service B if its enabled) Note, the above dependencies will normally start in parallel, which can be surprisingly useful, but in those cases where a service A absolutely must be started *after* service B, the additional parameter "After= $serviceB" can be added to the .service file of service A, making sure it will not start loading until service B is fully loaded (something which systemd can actually be aware of thanks to how it encapsulates its services in cgroups) > On Aug 26, 2014, at 08:31 CDT, Thorsten Kukuk wrote: > > > > > Hi, > > > > On Tue, Aug 26, urs.frey at post.ch wrote: > > > >> Hi > >> > >> When trying to install SLES12 Rc2 x86_64 using autoyast with init-scripts within autoinst.xml the installation process does not wait until init-script has terminated. > >> So I can already see the final login screen even though my init-script within autoinst.xml is still running > > > > Yes, that's the new world of systemd: start every service as early as > > possible in parallel. > > > >> I consider this as bug. > >> Please fix this within autoyast > > > > I'm not sure if there is anything autoyast can do here. > > > > Thorsten > > > > -- > > Thorsten Kukuk, Senior Architect SLES & Common Code Base > > SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg > > GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg) > > _______________________________________________ > > sles-beta mailing list > > sles-beta at lists.suse.com > > http://lists.suse.com/mailman/listinfo/sles-beta > > > > P.S. Text the word BLIND to 85944 to donate $10 to the NFB Imagination Fund via your phone bill. > > The National Federation of the Blind knows that blindness is not the characteristic that defines you or your future. Every day we raise the expectations of blind people, because low expectations create obstacles between blind people and our dreams. You can have the life you want; blindness is not what holds you back. > > -- > 73' & 75' > Gregory D. Rosenberg AB9MZ > gregg at ricis.com > > RICIS, Inc. > 7849 Bristol Park Drive > Tinley Park, IL 60477-4594 > http://www.ricis.com > > 708-267-6664 Cell > 708-444-2690 Office > 708-444-1115 Fax > (Please call before sending a fax) > > > > _______________________________________________ > sles-beta mailing list > sles-beta at lists.suse.com > http://lists.suse.com/mailman/listinfo/sles-beta -- Richard Brown QA Engineer openSUSE Chairman Phone +4991174053-361 SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg Geschaeftsfuehrer: Jeff Hawn, Jennifer Guild, Felix Imendoerffer, HRB 16746 (AG Nuernberg) From jreidinger at suse.cz Wed Aug 27 02:36:49 2014 From: jreidinger at suse.cz (Josef Reidinger) Date: Wed, 27 Aug 2014 10:36:49 +0200 Subject: [sles-beta] Installation failed on PowerKVM In-Reply-To: <53FE14BA0200006500009E9D@soto.provo.novell.com> References: <53FE14BA0200006500009E9D@soto.provo.novell.com> Message-ID: <20140827103649.7a7c8e3f@linux-5mqx.site> On Wed, 27 Aug 2014 02:26:18 -0600 "Ryo Murakawa" wrote: > Hi Expert > > Today I try to install SLES12-RC2 on PowerKVM on Power8. > But the installation terminated. Please check the attached figure. > > If there are some workarounds, please let me know. > > Regards. > > Ryo Hi Ryo, it looks like bug we have reported, but I cannot reproduce it reliably. Can you reproduce it with each installation? Does it happen with qt installation or with text mode ( from current reports it looks like only with qt ). And do you use some kind of remote installation ( vnc or ssh ) or direct one? I am still trying to debug what can cause it. Josef From rmurakawa at suse.com Wed Aug 27 04:13:14 2014 From: rmurakawa at suse.com (Ryo Murakawa) Date: Wed, 27 Aug 2014 04:13:14 -0600 Subject: [sles-beta] Installation failed on PowerKVM In-Reply-To: <20140827103649.7a7c8e3f@linux-5mqx.site> References: <53FE14BA0200006500009E9D@soto.provo.novell.com> <20140827103649.7a7c8e3f@linux-5mqx.site> Message-ID: <53FE3BEB02000065001BED8E@soto.provo.novell.com> Hi I can reproduce this. And this power8 machine is in Japan office. So if you want to use this, let me know. It happened with qt and vnc. Regards. Ryo iPhone???? 2014/08/27 18:14?"Josef Reidinger" ??????: > On Wed, 27 Aug 2014 02:26:18 -0600 > "Ryo Murakawa" wrote: > >> Hi Expert >> >> Today I try to install SLES12-RC2 on PowerKVM on Power8. >> But the installation terminated. Please check the attached figure. >> >> If there are some workarounds, please let me know. >> >> Regards. >> >> Ryo > > Hi Ryo, > it looks like bug we have reported, but I cannot reproduce it reliably. > Can you reproduce it with each installation? Does it happen with qt > installation or with text mode ( from current reports it looks like > only with qt ). And do you use some kind of remote installation ( vnc > or ssh ) or direct one? > I am still trying to debug what can cause it. > Josef > _______________________________________________ > sles-beta mailing list > sles-beta at lists.suse.com > http://lists.suse.com/mailman/listinfo/sles-beta > From schubi at suse.de Wed Aug 27 04:55:55 2014 From: schubi at suse.de (Stefan Schubert) Date: Wed, 27 Aug 2014 12:55:55 +0200 Subject: [sles-beta] SLES12 x86_64 RC2 autoyast post-script zypper unusable, application locked by y2base In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0F9D2E28@HXMB12.pnet.ch> References: <40637DBB36AF3941B243A286A432CA0B0F9D2E28@HXMB12.pnet.ch> Message-ID: <53FDB93B.5070302@suse.de> Hi, the normal way of installingadditional and customized packages in autoyast is defined here: http://doc.opensuse.org/projects/autoyast/configuration.html#idm139795987981568 It seem that this way does not fit your requirements. OK, here is a really HACK. Libzypp (which is used by zypper) just checks the file /var/run/zypp.pid in order checking the lock. (which is blamed by zypper). So you would only have to move this file to other position, call your zypper calls and please move this file back after you have finished your zypper calls. But as I have already said, this is REALLY a hack and should NOT be the normal way:-) Greetings Stefan Schubert g155:/home/src/ISOs # cat /var/run/zypp.pid 13544 g155:/home/src/ISOs # ps aux|grep 13544 root 13544 14.6 5.9 878604 235540 pts/20 Sl+ 12:40 0:10 /usr/lib/YaST2/bin/y2base sw_single qt root 14047 0.0 0.0 9264 928 pts/21 S+ 12:41 0:00 grep --color=auto 13544 Am 27.08.2014 11:10, schrieb urs.frey at post.ch: > Hi > I am trying to install SLES12 x86_64 RC2 onto my testservers using > autoyast > I have a bunch of package installations and configurations to do, > which are configured by puppet. > During autoyast post-script phase zypper unfortunately is locked by > y2base process > root 603 1 0 10:53 tty7 00:00:00 /bin/sh > /usr/lib/YaST2/startup/YaST2.Second-Stage > root 4040 603 0 10:54 tty7 00:00:00 /bin/sh > /usr/lib/YaST2/startup/YaST2.call installation continue > root 4742 4040 27 10:54 tty7 00:00:11 y2base installation > ("continue") ncurses > root 7597 4742 0 10:54 tty7 00:00:00 [snapper.py] > root 9337 4742 0 10:54 tty7 00:00:00 y2base installation > ("continue") ncurses > root 9338 9337 0 10:54 tty7 00:00:00 y2base installation > ("continue") ncurses > root 9339 9338 0 10:54 tty7 00:00:00 sh -c /bin/sh -x > /var/adm/autoinstall/scripts/post-script.sh &> > /var/adm/autoinstall/logs/post-script.sh.log > root 9340 9339 0 10:54 tty7 00:00:00 /bin/sh -x > /var/adm/autoinstall/scripts/post-script.sh > root 9693 9340 0 10:54 tty7 00:00:00 ps -efww > So when having a look at the processes together with y2base I quickly > get the intention, that the second stage of autoyast itself, showing > the ncurses screen is the y2base process. So killing of y2base would > not be a good idea to gain zypper access. > So for me going back to RPM package installation to omit zypper > conflict within autoyast post-script is not an option. > Moving the entire puppet configuration and OEM package installation to > autoyast init-script seems to be the only way. > But autoyast init-script on the other hand does run in the background > while systemD already opens the console login for root. > Having console logins already enabled, while autoyast init-script is > still running is really not a good way. > regards > Urs Frey > Post CH AG > Informationstechnologie > IT Betrieb > Webergutstrasse 12 > 3030 Bern (Zollikofen) > Telefon : ++41 (0)58 338 58 70 > FAX : ++41 (0)58 667 30 07 > E-Mail: _urs.frey at post.ch_ > > > _______________________________________________ > sles-beta mailing list > sles-beta at lists.suse.com > http://lists.suse.com/mailman/listinfo/sles-beta -- ******************************************************************************* Stefan Schubert e-mail: schubi at suse.de ------------------------------------------------------------------------------- SUSE LINUX Products GmbH GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg) Maxfeldstra?e 5 90409 N?rnberg Germany From urs.frey at post.ch Wed Aug 27 05:54:36 2014 From: urs.frey at post.ch (urs.frey at post.ch) Date: Wed, 27 Aug 2014 11:54:36 +0000 Subject: [sles-beta] SLES12 x86_64 RC2 autoyast post-script zypper unusable, application locked by y2base In-Reply-To: <53FDB93B.5070302@suse.de> References: <40637DBB36AF3941B243A286A432CA0B0F9D2E28@HXMB12.pnet.ch> <53FDB93B.5070302@suse.de> Message-ID: <40637DBB36AF3941B243A286A432CA0B0F9D2EA9@HXMB12.pnet.ch> Hello Stefan The way to add add-on product repositories is well known to me, thank you very much. BUT: As I mentioned I am using puppet and a CMDB. So my puppet modules when running will make sure, the correct software package depending the configuration requirements will be installed. So it is not the same as e.g: Autoyast post-script = >zypper in -y apache2, or zypper in -y mypackage It works this way /usr/bin/puppet agent --server=vpup02.pnet.ch --masterport=8140 --environment=config_development -v --no-daemonize --onetime --http_compression --libdir=/var/lib/puppet/lib/config_development --color=false --show_diff And within the puppet manifest we have: ========================== class admin::mcollective( $p_mco_admins = [] ) { $mcollective_classesfile = '/var/lib/puppet/classes_config.txt' if ( $::operatingsystem == 'SLES' and $::is_in_postinstallscript == 'false' ) { if ( $::operatingsystemrelease >= 11 ) { package {'pst-rubygem-stomp': ensure => latest, notify => Service['mcollective'], } -> package {'pst-rubygem-sshkeyauth': ensure => latest, notify => Service['mcollective'], } -> package {'pst-mcollective-server': ensure => latest, notify => Service['mcollective'], alias => 'mcollective-server', } } else { package {'pst-rubygem-sshkeyauth': ensure => installed, notify => Service['mcollective'], } -> package {'pst-mcollective-server': ensure => installed, notify => Service['mcollective'], alias => 'mcollective-server', } } if ( $::architecture == 'x86_64' ) { if ( $::operatingsystemrelease >= 12 ) { $mcollective_libdir = '/usr/lib64/ruby/site_ruby/2.1.0/x86_64-linux-gnu/mcollective.plugins:/etc/mcollective/plugin.d' } else { $mcollective_libdir = '/usr/lib64/ruby/site_ruby/1.8/x86_64-linux/mcollective.plugins:/etc/mcollective/plugin.d' } } else { $mcollective_libdir = '/usr/lib/ruby/site_ruby/1.8/i586-linux/mcollective.plugins:/etc/mcollective/plugin.d' } Best regards Urs Frey????????????????????????????????????????????? Post CH AG Informationstechnologie IT Betrieb Webergutstrasse 12 3030 Bern (Zollikofen) Telefon : ++41 (0)58 338 58 70 FAX???? : ++41 (0)58 667 30 07 E-Mail:?? urs.frey at post.ch -----Urspr?ngliche Nachricht----- Von: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] Im Auftrag von Stefan Schubert Gesendet: Wednesday, August 27, 2014 12:56 PM An: sles-beta at lists.suse.com Betreff: Re: [sles-beta] SLES12 x86_64 RC2 autoyast post-script zypper unusable, application locked by y2base Hi, the normal way of installingadditional and customized packages in autoyast is defined here: http://doc.opensuse.org/projects/autoyast/configuration.html#idm139795987981568 It seem that this way does not fit your requirements. OK, here is a really HACK. Libzypp (which is used by zypper) just checks the file /var/run/zypp.pid in order checking the lock. (which is blamed by zypper). So you would only have to move this file to other position, call your zypper calls and please move this file back after you have finished your zypper calls. But as I have already said, this is REALLY a hack and should NOT be the normal way:-) Greetings Stefan Schubert g155:/home/src/ISOs # cat /var/run/zypp.pid 13544 g155:/home/src/ISOs # ps aux|grep 13544 root 13544 14.6 5.9 878604 235540 pts/20 Sl+ 12:40 0:10 /usr/lib/YaST2/bin/y2base sw_single qt root 14047 0.0 0.0 9264 928 pts/21 S+ 12:41 0:00 grep --color=auto 13544 Am 27.08.2014 11:10, schrieb urs.frey at post.ch: > Hi > I am trying to install SLES12 x86_64 RC2 onto my testservers using > autoyast > I have a bunch of package installations and configurations to do, > which are configured by puppet. > During autoyast post-script phase zypper unfortunately is locked by > y2base process > root 603 1 0 10:53 tty7 00:00:00 /bin/sh > /usr/lib/YaST2/startup/YaST2.Second-Stage > root 4040 603 0 10:54 tty7 00:00:00 /bin/sh > /usr/lib/YaST2/startup/YaST2.call installation continue > root 4742 4040 27 10:54 tty7 00:00:11 y2base installation > ("continue") ncurses > root 7597 4742 0 10:54 tty7 00:00:00 [snapper.py] > root 9337 4742 0 10:54 tty7 00:00:00 y2base installation > ("continue") ncurses > root 9338 9337 0 10:54 tty7 00:00:00 y2base installation > ("continue") ncurses > root 9339 9338 0 10:54 tty7 00:00:00 sh -c /bin/sh -x > /var/adm/autoinstall/scripts/post-script.sh &> > /var/adm/autoinstall/logs/post-script.sh.log > root 9340 9339 0 10:54 tty7 00:00:00 /bin/sh -x > /var/adm/autoinstall/scripts/post-script.sh > root 9693 9340 0 10:54 tty7 00:00:00 ps -efww > So when having a look at the processes together with y2base I quickly > get the intention, that the second stage of autoyast itself, showing > the ncurses screen is the y2base process. So killing of y2base would > not be a good idea to gain zypper access. > So for me going back to RPM package installation to omit zypper > conflict within autoyast post-script is not an option. > Moving the entire puppet configuration and OEM package installation to > autoyast init-script seems to be the only way. > But autoyast init-script on the other hand does run in the background > while systemD already opens the console login for root. > Having console logins already enabled, while autoyast init-script is > still running is really not a good way. > regards > Urs Frey > Post CH AG > Informationstechnologie > IT Betrieb > Webergutstrasse 12 > 3030 Bern (Zollikofen) > Telefon : ++41 (0)58 338 58 70 > FAX : ++41 (0)58 667 30 07 > E-Mail: _urs.frey at post.ch_ > > > _______________________________________________ > sles-beta mailing list > sles-beta at lists.suse.com > http://lists.suse.com/mailman/listinfo/sles-beta -- ******************************************************************************* Stefan Schubert e-mail: schubi at suse.de ------------------------------------------------------------------------------- SUSE LINUX Products GmbH GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg) Maxfeldstra?e 5 90409 N?rnberg Germany _______________________________________________ sles-beta mailing list sles-beta at lists.suse.com http://lists.suse.com/mailman/listinfo/sles-beta From rbrown at suse.de Wed Aug 27 06:36:27 2014 From: rbrown at suse.de (Richard Brown) Date: Wed, 27 Aug 2014 14:36:27 +0200 Subject: [sles-beta] SLES12 x86_64 RC2 autoyast post-script zypper unusable, application locked by y2base In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0F9D2EA9@HXMB12.pnet.ch> References: <40637DBB36AF3941B243A286A432CA0B0F9D2E28@HXMB12.pnet.ch> <53FDB93B.5070302@suse.de> <40637DBB36AF3941B243A286A432CA0B0F9D2EA9@HXMB12.pnet.ch> Message-ID: <1409142987.18622.21.camel@ibrokeit.suse.de> On Wed, 2014-08-27 at 11:54 +0000, urs.frey at post.ch wrote: > Hello Stefan > > The way to add add-on product repositories is well known to me, thank you very much. > > BUT: > As I mentioned I am using puppet and a CMDB. > So my puppet modules when running will make sure, the correct software package depending the configuration requirements will be installed. > > So it is not the same as e.g: > Autoyast post-script = >zypper in -y apache2, or zypper in -y mypackage > > It works this way > > /usr/bin/puppet agent --server=vpup02.pnet.ch --masterport=8140 --environment=config_development -v --no-daemonize --onetime --http_compression --libdir=/var/lib/puppet/lib/config_development --color=false --show_diff If this is the case, why can you not have puppet control the system in the way you require? One way you could see this issue is that AutoYAST's job is to "get the system installed and usable as fast as possible" This is complimented by systemd's logic which is to "get the installed system booted and usable as fast as possible" The behaviour you describe as 'broken' and 'unusable' seems to me to be desirable in many cases, even with use cases like puppet, where many people rely on the asyncronous nature of puppet to handle and resolve issues in the background while users go about their business. Obviously, you need a solution for this specific case, but I cant help but ask 'why not use puppet'? Puppet can control both systemd services, user accounts, configured authentication methods, etc. If your desire is to make sure that users dont use the system until your initial puppet run is complete, why not use puppet to prevent your overly keen administrators getting on the system until it's ready? Regards, Richard > > > And within the puppet manifest we have: > ========================== > class admin::mcollective( $p_mco_admins = [] ) { > > $mcollective_classesfile = '/var/lib/puppet/classes_config.txt' > if ( $::operatingsystem == 'SLES' and $::is_in_postinstallscript == 'false' ) { > if ( $::operatingsystemrelease >= 11 ) { > package {'pst-rubygem-stomp': > ensure => latest, > notify => Service['mcollective'], > } -> > package {'pst-rubygem-sshkeyauth': > ensure => latest, > notify => Service['mcollective'], > } -> > package {'pst-mcollective-server': > ensure => latest, > notify => Service['mcollective'], > alias => 'mcollective-server', > } > } else { > package {'pst-rubygem-sshkeyauth': > ensure => installed, > notify => Service['mcollective'], > } -> > package {'pst-mcollective-server': > ensure => installed, > notify => Service['mcollective'], > alias => 'mcollective-server', > } > } > if ( $::architecture == 'x86_64' ) { > if ( $::operatingsystemrelease >= 12 ) { > $mcollective_libdir = '/usr/lib64/ruby/site_ruby/2.1.0/x86_64-linux-gnu/mcollective.plugins:/etc/mcollective/plugin.d' > } else { > $mcollective_libdir = '/usr/lib64/ruby/site_ruby/1.8/x86_64-linux/mcollective.plugins:/etc/mcollective/plugin.d' > } > } else { > $mcollective_libdir = '/usr/lib/ruby/site_ruby/1.8/i586-linux/mcollective.plugins:/etc/mcollective/plugin.d' > } > > > Best regards > > > Urs Frey > Post CH AG > Informationstechnologie > IT Betrieb > Webergutstrasse 12 > 3030 Bern (Zollikofen) > Telefon : ++41 (0)58 338 58 70 > FAX : ++41 (0)58 667 30 07 > E-Mail: urs.frey at post.ch > > > -----Urspr?ngliche Nachricht----- > Von: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] Im Auftrag von Stefan Schubert > Gesendet: Wednesday, August 27, 2014 12:56 PM > An: sles-beta at lists.suse.com > Betreff: Re: [sles-beta] SLES12 x86_64 RC2 autoyast post-script zypper unusable, application locked by y2base > > Hi, > the normal way of installingadditional and customized packages in > autoyast is defined > here: > http://doc.opensuse.org/projects/autoyast/configuration.html#idm139795987981568 > > It seem that this way does not fit your requirements. OK, here is a > really HACK. > Libzypp (which is used by zypper) just checks the file /var/run/zypp.pid > in order > checking the lock. (which is blamed by zypper). > So you would only have to move this file to other position, call your > zypper calls > and please move this file back after you have finished your zypper calls. > But as I have already said, this is REALLY a hack and should NOT be the > normal way:-) > > Greetings > Stefan Schubert > > > g155:/home/src/ISOs # cat /var/run/zypp.pid > 13544 > g155:/home/src/ISOs # ps aux|grep 13544 > root 13544 14.6 5.9 878604 235540 pts/20 Sl+ 12:40 0:10 > /usr/lib/YaST2/bin/y2base sw_single qt > root 14047 0.0 0.0 9264 928 pts/21 S+ 12:41 0:00 grep > --color=auto 13544 > > > > Am 27.08.2014 11:10, schrieb urs.frey at post.ch: > > Hi > > I am trying to install SLES12 x86_64 RC2 onto my testservers using > > autoyast > > I have a bunch of package installations and configurations to do, > > which are configured by puppet. > > During autoyast post-script phase zypper unfortunately is locked by > > y2base process > > root 603 1 0 10:53 tty7 00:00:00 /bin/sh > > /usr/lib/YaST2/startup/YaST2.Second-Stage > > root 4040 603 0 10:54 tty7 00:00:00 /bin/sh > > /usr/lib/YaST2/startup/YaST2.call installation continue > > root 4742 4040 27 10:54 tty7 00:00:11 y2base installation > > ("continue") ncurses > > root 7597 4742 0 10:54 tty7 00:00:00 [snapper.py] > > root 9337 4742 0 10:54 tty7 00:00:00 y2base installation > > ("continue") ncurses > > root 9338 9337 0 10:54 tty7 00:00:00 y2base installation > > ("continue") ncurses > > root 9339 9338 0 10:54 tty7 00:00:00 sh -c /bin/sh -x > > /var/adm/autoinstall/scripts/post-script.sh &> > > /var/adm/autoinstall/logs/post-script.sh.log > > root 9340 9339 0 10:54 tty7 00:00:00 /bin/sh -x > > /var/adm/autoinstall/scripts/post-script.sh > > root 9693 9340 0 10:54 tty7 00:00:00 ps -efww > > So when having a look at the processes together with y2base I quickly > > get the intention, that the second stage of autoyast itself, showing > > the ncurses screen is the y2base process. So killing of y2base would > > not be a good idea to gain zypper access. > > So for me going back to RPM package installation to omit zypper > > conflict within autoyast post-script is not an option. > > Moving the entire puppet configuration and OEM package installation to > > autoyast init-script seems to be the only way. > > But autoyast init-script on the other hand does run in the background > > while systemD already opens the console login for root. > > Having console logins already enabled, while autoyast init-script is > > still running is really not a good way. > > regards > > Urs Frey > > Post CH AG > > Informationstechnologie > > IT Betrieb > > Webergutstrasse 12 > > 3030 Bern (Zollikofen) > > Telefon : ++41 (0)58 338 58 70 > > FAX : ++41 (0)58 667 30 07 > > E-Mail: _urs.frey at post.ch_ > > > > > > _______________________________________________ > > sles-beta mailing list > > sles-beta at lists.suse.com > > http://lists.suse.com/mailman/listinfo/sles-beta > > -- Richard Brown QA Engineer openSUSE Chairman Phone +4991174053-361 SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg Geschaeftsfuehrer: Jeff Hawn, Jennifer Guild, Felix Imendoerffer, HRB 16746 (AG Nuernberg) From urs.frey at post.ch Wed Aug 27 06:58:33 2014 From: urs.frey at post.ch (urs.frey at post.ch) Date: Wed, 27 Aug 2014 12:58:33 +0000 Subject: [sles-beta] SLES12 x86_64 RC2 autoyast post-script zypper unusable, application locked by y2base In-Reply-To: <1409142987.18622.21.camel@ibrokeit.suse.de> References: <40637DBB36AF3941B243A286A432CA0B0F9D2E28@HXMB12.pnet.ch> <53FDB93B.5070302@suse.de> <40637DBB36AF3941B243A286A432CA0B0F9D2EA9@HXMB12.pnet.ch> <1409142987.18622.21.camel@ibrokeit.suse.de> Message-ID: <40637DBB36AF3941B243A286A432CA0B0F9D2EDF@HXMB12.pnet.ch> Hi Richard >One way you could see this issue is that AutoYAST's job is to "get the >system installed and usable as fast as possible" Fully agree. But usable does also mean fully configured for use. >This is complimented by systemd's logic which is to "get the installed >system booted and usable as fast as possible" Nothing against this. But again, some synchronization needed to prevent intervention from the "problem between keyboard and backrest". This is real life. >Puppet can control both systemd services, user accounts, configured >authentication methods, etc. Exactly. Best regards Urs Frey????????????????????????????????????????????? Post CH AG Informationstechnologie IT Betrieb Webergutstrasse 12 3030 Bern (Zollikofen) Telefon : ++41 (0)58 338 58 70 FAX???? : ++41 (0)58 667 30 07 E-Mail:?? urs.frey at post.ch -----Urspr?ngliche Nachricht----- Von: Richard Brown [mailto:rbrown at suse.de] Gesendet: Wednesday, August 27, 2014 2:36 PM An: Frey Urs, IT222 Cc: sles-beta at lists.suse.com Betreff: Re: [sles-beta] SLES12 x86_64 RC2 autoyast post-script zypper unusable, application locked by y2base On Wed, 2014-08-27 at 11:54 +0000, urs.frey at post.ch wrote: > Hello Stefan > > The way to add add-on product repositories is well known to me, thank you very much. > > BUT: > As I mentioned I am using puppet and a CMDB. > So my puppet modules when running will make sure, the correct software package depending the configuration requirements will be installed. > > So it is not the same as e.g: > Autoyast post-script = >zypper in -y apache2, or zypper in -y mypackage > > It works this way > > /usr/bin/puppet agent --server=vpup02.pnet.ch --masterport=8140 --environment=config_development -v --no-daemonize --onetime --http_compression --libdir=/var/lib/puppet/lib/config_development --color=false --show_diff If this is the case, why can you not have puppet control the system in the way you require? One way you could see this issue is that AutoYAST's job is to "get the system installed and usable as fast as possible" This is complimented by systemd's logic which is to "get the installed system booted and usable as fast as possible" The behaviour you describe as 'broken' and 'unusable' seems to me to be desirable in many cases, even with use cases like puppet, where many people rely on the asyncronous nature of puppet to handle and resolve issues in the background while users go about their business. Obviously, you need a solution for this specific case, but I cant help but ask 'why not use puppet'? Puppet can control both systemd services, user accounts, configured authentication methods, etc. If your desire is to make sure that users dont use the system until your initial puppet run is complete, why not use puppet to prevent your overly keen administrators getting on the system until it's ready? Regards, Richard > > > And within the puppet manifest we have: > ========================== > class admin::mcollective( $p_mco_admins = [] ) { > > $mcollective_classesfile = '/var/lib/puppet/classes_config.txt' > if ( $::operatingsystem == 'SLES' and $::is_in_postinstallscript == 'false' ) { > if ( $::operatingsystemrelease >= 11 ) { > package {'pst-rubygem-stomp': > ensure => latest, > notify => Service['mcollective'], > } -> > package {'pst-rubygem-sshkeyauth': > ensure => latest, > notify => Service['mcollective'], > } -> > package {'pst-mcollective-server': > ensure => latest, > notify => Service['mcollective'], > alias => 'mcollective-server', > } > } else { > package {'pst-rubygem-sshkeyauth': > ensure => installed, > notify => Service['mcollective'], > } -> > package {'pst-mcollective-server': > ensure => installed, > notify => Service['mcollective'], > alias => 'mcollective-server', > } > } > if ( $::architecture == 'x86_64' ) { > if ( $::operatingsystemrelease >= 12 ) { > $mcollective_libdir = '/usr/lib64/ruby/site_ruby/2.1.0/x86_64-linux-gnu/mcollective.plugins:/etc/mcollective/plugin.d' > } else { > $mcollective_libdir = '/usr/lib64/ruby/site_ruby/1.8/x86_64-linux/mcollective.plugins:/etc/mcollective/plugin.d' > } > } else { > $mcollective_libdir = '/usr/lib/ruby/site_ruby/1.8/i586-linux/mcollective.plugins:/etc/mcollective/plugin.d' > } > > > Best regards > > > Urs Frey > Post CH AG > Informationstechnologie > IT Betrieb > Webergutstrasse 12 > 3030 Bern (Zollikofen) > Telefon : ++41 (0)58 338 58 70 > FAX : ++41 (0)58 667 30 07 > E-Mail: urs.frey at post.ch > > > -----Urspr?ngliche Nachricht----- > Von: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] Im Auftrag von Stefan Schubert > Gesendet: Wednesday, August 27, 2014 12:56 PM > An: sles-beta at lists.suse.com > Betreff: Re: [sles-beta] SLES12 x86_64 RC2 autoyast post-script zypper unusable, application locked by y2base > > Hi, > the normal way of installingadditional and customized packages in > autoyast is defined > here: > http://doc.opensuse.org/projects/autoyast/configuration.html#idm139795987981568 > > It seem that this way does not fit your requirements. OK, here is a > really HACK. > Libzypp (which is used by zypper) just checks the file /var/run/zypp.pid > in order > checking the lock. (which is blamed by zypper). > So you would only have to move this file to other position, call your > zypper calls > and please move this file back after you have finished your zypper calls. > But as I have already said, this is REALLY a hack and should NOT be the > normal way:-) > > Greetings > Stefan Schubert > > > g155:/home/src/ISOs # cat /var/run/zypp.pid > 13544 > g155:/home/src/ISOs # ps aux|grep 13544 > root 13544 14.6 5.9 878604 235540 pts/20 Sl+ 12:40 0:10 > /usr/lib/YaST2/bin/y2base sw_single qt > root 14047 0.0 0.0 9264 928 pts/21 S+ 12:41 0:00 grep > --color=auto 13544 > > > > Am 27.08.2014 11:10, schrieb urs.frey at post.ch: > > Hi > > I am trying to install SLES12 x86_64 RC2 onto my testservers using > > autoyast > > I have a bunch of package installations and configurations to do, > > which are configured by puppet. > > During autoyast post-script phase zypper unfortunately is locked by > > y2base process > > root 603 1 0 10:53 tty7 00:00:00 /bin/sh > > /usr/lib/YaST2/startup/YaST2.Second-Stage > > root 4040 603 0 10:54 tty7 00:00:00 /bin/sh > > /usr/lib/YaST2/startup/YaST2.call installation continue > > root 4742 4040 27 10:54 tty7 00:00:11 y2base installation > > ("continue") ncurses > > root 7597 4742 0 10:54 tty7 00:00:00 [snapper.py] > > root 9337 4742 0 10:54 tty7 00:00:00 y2base installation > > ("continue") ncurses > > root 9338 9337 0 10:54 tty7 00:00:00 y2base installation > > ("continue") ncurses > > root 9339 9338 0 10:54 tty7 00:00:00 sh -c /bin/sh -x > > /var/adm/autoinstall/scripts/post-script.sh &> > > /var/adm/autoinstall/logs/post-script.sh.log > > root 9340 9339 0 10:54 tty7 00:00:00 /bin/sh -x > > /var/adm/autoinstall/scripts/post-script.sh > > root 9693 9340 0 10:54 tty7 00:00:00 ps -efww > > So when having a look at the processes together with y2base I quickly > > get the intention, that the second stage of autoyast itself, showing > > the ncurses screen is the y2base process. So killing of y2base would > > not be a good idea to gain zypper access. > > So for me going back to RPM package installation to omit zypper > > conflict within autoyast post-script is not an option. > > Moving the entire puppet configuration and OEM package installation to > > autoyast init-script seems to be the only way. > > But autoyast init-script on the other hand does run in the background > > while systemD already opens the console login for root. > > Having console logins already enabled, while autoyast init-script is > > still running is really not a good way. > > regards > > Urs Frey > > Post CH AG > > Informationstechnologie > > IT Betrieb > > Webergutstrasse 12 > > 3030 Bern (Zollikofen) > > Telefon : ++41 (0)58 338 58 70 > > FAX : ++41 (0)58 667 30 07 > > E-Mail: _urs.frey at post.ch_ > > > > > > _______________________________________________ > > sles-beta mailing list > > sles-beta at lists.suse.com > > http://lists.suse.com/mailman/listinfo/sles-beta > > -- Richard Brown QA Engineer openSUSE Chairman Phone +4991174053-361 SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg Geschaeftsfuehrer: Jeff Hawn, Jennifer Guild, Felix Imendoerffer, HRB 16746 (AG Nuernberg) From gjn at gjn.priv.at Wed Aug 27 08:20:31 2014 From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer) Date: Wed, 27 Aug 2014 16:20:31 +0200 Subject: [sles-beta] Network Problem on Install RC2 Message-ID: <1427188.nt7z9BJpRe@gjn.priv.at> Hello, I have 4 NIC in my system when I like o change anything in the Network config on the Installing Window, this is never working for registration ? The Problem (only for me ?) the installer have a other structure then I. I like to have eth0 on the first found NIC but now the Installer it different the onboard NiCs are eth3 or eth4 usw. When I like to change this I have afterward a broken Network or a crash with the Installer. The Firewall have also Problem after installing, no Zone is Assigned but the firewall is running, so I have no chance to come back with SSH. -- mit freundlichen Gr??en / best Regards, G?nther J. Niederwimmer From gjn at gjn.priv.at Wed Aug 27 09:20:24 2014 From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer) Date: Wed, 27 Aug 2014 17:20:24 +0200 Subject: [sles-beta] Question mc shell connection Message-ID: <1542164.Xi4z2upgqG@gjn.priv.at> Hello, why is in the SLES 12 mc the shell connection missing ? -- mit freundlichen Gr??en / best Regards, G?nther J. Niederwimmer From RMurakawa at suse.com Wed Aug 27 09:26:39 2014 From: RMurakawa at suse.com (Ryo Murakawa) Date: Wed, 27 Aug 2014 09:26:39 -0600 Subject: [sles-beta] Installation failed on PowerKVM In-Reply-To: <53FE3BEB02000065001BED8E@soto.provo.novell.com> References: <53FE14BA0200006500009E9D@soto.provo.novell.com> <20140827103649.7a7c8e3f@linux-5mqx.site> <53FE3BEB02000065001BED8E@soto.provo.novell.com> Message-ID: <53FE854F02000065001BEE02@soto.provo.novell.com> Hi I check if I have same symptom with SLES12 RC1. I got same error. So please tell me how to install this with text mode. Regards. Ryo >>> "Ryo Murakawa" 8/27/2014 7:13 PM >>> Hi I can reproduce this. And this power8 machine is in Japan office. So if you want to use this, let me know. It happened with qt and vnc. Regards. Ryo iPhone???? 2014/08/27 18:14?"Josef Reidinger" ??????: > On Wed, 27 Aug 2014 02:26:18 -0600 > "Ryo Murakawa" wrote: > >> Hi Expert >> >> Today I try to install SLES12-RC2 on PowerKVM on Power8. >> But the installation terminated. Please check the attached figure. >> >> If there are some workarounds, please let me know. >> >> Regards. >> >> Ryo > > Hi Ryo, > it looks like bug we have reported, but I cannot reproduce it reliably. > Can you reproduce it with each installation? Does it happen with qt > installation or with text mode ( from current reports it looks like > only with qt ). And do you use some kind of remote installation ( vnc > or ssh ) or direct one? > I am still trying to debug what can cause it. > Josef > _______________________________________________ > sles-beta mailing list > sles-beta at lists.suse.com > http://lists.suse.com/mailman/listinfo/sles-beta > _______________________________________________ sles-beta mailing list sles-beta at lists.suse.com http://lists.suse.com/mailman/listinfo/sles-beta -------------- next part -------------- An HTML attachment was scrubbed... URL: From RMurakawa at suse.com Wed Aug 27 09:26:48 2014 From: RMurakawa at suse.com (Ryo Murakawa) Date: Wed, 27 Aug 2014 09:26:48 -0600 Subject: [sles-beta] Installation failed on PowerKVM In-Reply-To: <53FE3BEB02000065001BED8E@soto.provo.novell.com> References: <53FE14BA0200006500009E9D@soto.provo.novell.com> <20140827103649.7a7c8e3f@linux-5mqx.site> <53FE3BEB02000065001BED8E@soto.provo.novell.com> Message-ID: <53FE855802000065001BEE0A@soto.provo.novell.com> Hi I check if I have same symptom with SLES12 RC1. I got same error. So please tell me how to install this with text mode. Regards. Ryo >>> "Ryo Murakawa" 8/27/2014 7:13 PM >>> Hi I can reproduce this. And this power8 machine is in Japan office. So if you want to use this, let me know. It happened with qt and vnc. Regards. Ryo iPhone???? 2014/08/27 18:14?"Josef Reidinger" ??????: > On Wed, 27 Aug 2014 02:26:18 -0600 > "Ryo Murakawa" wrote: > >> Hi Expert >> >> Today I try to install SLES12-RC2 on PowerKVM on Power8. >> But the installation terminated. Please check the attached figure. >> >> If there are some workarounds, please let me know. >> >> Regards. >> >> Ryo > > Hi Ryo, > it looks like bug we have reported, but I cannot reproduce it reliably. > Can you reproduce it with each installation? Does it happen with qt > installation or with text mode ( from current reports it looks like > only with qt ). And do you use some kind of remote installation ( vnc > or ssh ) or direct one? > I am still trying to debug what can cause it. > Josef > _______________________________________________ > sles-beta mailing list > sles-beta at lists.suse.com > http://lists.suse.com/mailman/listinfo/sles-beta > _______________________________________________ sles-beta mailing list sles-beta at lists.suse.com http://lists.suse.com/mailman/listinfo/sles-beta -------------- next part -------------- An HTML attachment was scrubbed... URL: From jreidinger at suse.com Wed Aug 27 09:36:14 2014 From: jreidinger at suse.com (Josef Reidinger) Date: Wed, 27 Aug 2014 17:36:14 +0200 Subject: [sles-beta] Installation failed on PowerKVM In-Reply-To: <53FE854F02000065001BEE02@soto.provo.novell.com> References: <53FE14BA0200006500009E9D@soto.provo.novell.com> <20140827103649.7a7c8e3f@linux-5mqx.site> <53FE3BEB02000065001BED8E@soto.provo.novell.com> <53FE854F02000065001BEE02@soto.provo.novell.com> Message-ID: <20140827173614.3a2772b7@linux-5mqx.site> On Wed, 27 Aug 2014 09:26:39 -0600 "Ryo Murakawa" wrote: > > Hi > > I check if I have same symptom with SLES12 RC1. I got same error. > > So please tell me how to install this with text mode. with text mode simple pass to kernel textmode=1 see https://en.opensuse.org/SDB:Linuxrc#Parameter_Reference > > Regards. > > Ryo > > >>> "Ryo Murakawa" 8/27/2014 7:13 PM >>> > Hi > > I can reproduce this. And this power8 machine is in Japan office. So > if you want to use this, let me know. I found that we can reproduce it in Nuerberg one and debug it. Result is that it segfault somewhere in QT and pass it to our expert in this area. If you are interested you can follow status in https://bugzilla.novell.com/show_bug.cgi?id=890168 Josef > > It happened with qt and vnc. > > Regards. > > Ryo > > iPhone???? > > 2014/08/27 18:14?"Josef Reidinger" ??????: > > > On Wed, 27 Aug 2014 02:26:18 -0600 > > "Ryo Murakawa" wrote: > > > >> Hi Expert > >> > >> Today I try to install SLES12-RC2 on PowerKVM on Power8. > >> But the installation terminated. Please check the attached figure. > >> > >> If there are some workarounds, please let me know. > >> > >> Regards. > >> > >> Ryo > > > > Hi Ryo, > > it looks like bug we have reported, but I cannot reproduce it > > reliably. Can you reproduce it with each installation? Does it > > happen with qt installation or with text mode ( from current > > reports it looks like only with qt ). And do you use some kind of > > remote installation ( vnc or ssh ) or direct one? > > I am still trying to debug what can cause it. > > Josef > > _______________________________________________ > > sles-beta mailing list > > sles-beta at lists.suse.com > > http://lists.suse.com/mailman/listinfo/sles-beta > > > > _______________________________________________ > sles-beta mailing list > sles-beta at lists.suse.com > http://lists.suse.com/mailman/listinfo/sles-beta From marcin.kowalski at assecobs.pl Thu Aug 28 05:07:33 2014 From: marcin.kowalski at assecobs.pl (marcin kowalski) Date: Thu, 28 Aug 2014 13:07:33 +0200 Subject: [sles-beta] Creating mini-boot-cd with SLES12 In-Reply-To: <20140827133851.085F0900A9@lists.suse.com> References: <20140827133851.085F0900A9@lists.suse.com> Message-ID: <53FF0D75.7040502@assecobs.pl> On 27.08.2014 15:39, henrik.skoog at polisen.se wrote: Hi! I?m trying to create at mini-boot-dvd image with the following info: ? Konfiguring Network, hostname etc.. ? Getting autoinst.xml file from a autoyast-server I?ll managed to do fix this in SLES11SP3, but with SLES12 It does?nt work at all. My goal is to create a separate iso for each system, and install from that. I?s there anyone that has any howto?s or some lead? Best Reguards Henrik Skoog What exactly was the problem? Afaik you should be able to use kiwi to generate livecd's and integrate autoyast scripts into them. ________________________________ Asseco Business Solutions S.A. ul. Konrada Wallenroda 4c 20-607 Lublin tel.: +48 81 535 30 00 fax: +48 81 535 30 05 S?d Rejonowy Lublin-Wsch?d w Lublinie z siedzib? w ?widniku VI Wydzia? Gospodarczy Krajowego Rejestru S?dowego KRS 0000028257 NIP 522-26-12-717 kapita? zak?adowy 167 090 965,00 z? (w ca?o?ci op?acony) www.assecobs.pl ________________________________ Powy?sza korespondencja przeznaczona jest wy??cznie dla osoby lub podmiotu, do kt?rego jest adresowana i mo?e zawiera? informacje o charakterze poufnym lub zastrze?onym. Nieuprawnione wykorzystanie informacji zawartych w wiadomo?ci e-mail przez osob? lub podmiot nie b?d?cy jej adresatem jest zabronione odpowiednimi przepisami prawa. Odbiorca korespondencji, kt?ry otrzyma? j? omy?kowo, proszony jest o niezw?oczne zawiadomienie nadawcy drog? elektroniczn? lub telefonicznie i usuni?cie tej tre?ci z poczty elektronicznej. Dzi?kujemy. Asseco Business Solutions S.A. ________________________________ We? pod uwag? ochron? ?rodowiska, zanim wydrukujesz ten e-mail. ________________________________ This information is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Unauthorized use of this information by person or entity other than the intended recipient is prohibited by law. If you received this by mistake, please immediately contact the sender by e-mail or by telephone and delete this information from any computer. Thank you. Asseco Business Solutions S.A. ________________________________ Please consider your environmental responsibility before printing this e-mail. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbohac at suse.cz Thu Aug 28 08:30:12 2014 From: jbohac at suse.cz (Jiri Bohac) Date: Thu, 28 Aug 2014 16:30:12 +0200 Subject: [sles-beta] Network Problem on Install RC2 In-Reply-To: <1427188.nt7z9BJpRe@gjn.priv.at> References: <1427188.nt7z9BJpRe@gjn.priv.at> Message-ID: <20140828143012.GA13825@midget.suse.cz> Hello G?nther, On Wed, Aug 27, 2014 at 04:20:31PM +0200, G?nther J. Niederwimmer wrote: > I like to have eth0 on the first found NIC but now the Installer it different > the onboard NiCs are eth3 or eth4 usw. eth0 _is_ the first found NIC; There is nothing that we can do to guarantee the onboard NICs are found first. > When I like to change this I have afterward a broken Network or a crash with > the Installer. I tried to reproduce this and found it was indeed broken. I tried to rename eth0->eth1 and eth1->eth0 on a two NIC system and couldn't do that properly. But I did not get the installer to crash. I opened bug #894053, but since SLE bugs are not publicly visible, you cannot see it. Let me know if you want to be put on the CC list of that bug and give us more details of your problem. Thanks for testing! -- Jiri Bohac SUSE Labs, SUSE CZ From gjn at gjn.priv.at Thu Aug 28 09:52:40 2014 From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer) Date: Thu, 28 Aug 2014 17:52:40 +0200 Subject: [sles-beta] Network Problem on Install RC2 In-Reply-To: <20140828143012.GA13825@midget.suse.cz> References: <1427188.nt7z9BJpRe@gjn.priv.at> <20140828143012.GA13825@midget.suse.cz> Message-ID: <2021000.jlZO3hiLDN@gjn.priv.at> Hell Jiri, Am Donnerstag, 28. August 2014, 16:30:12 schrieb Jiri Bohac: > Hello G?nther, > > On Wed, Aug 27, 2014 at 04:20:31PM +0200, G?nther J. Niederwimmer wrote: > > I like to have eth0 on the first found NIC but now the Installer it > > different the onboard NiCs are eth3 or eth4 usw. > > eth0 _is_ the first found NIC; There is nothing that we can do to > guarantee the onboard NICs are found first. The found schema is new I mean, with my 4 NICs I have 1 Dual Port NIC this have no 0 and 2 2 OnBoard Nics this have now 1 and 3 or other ;-) on older Installation, the onboard NiC hav 0 and 1 The Dual Port NIC 2 and 3 ? > > When I like to change this I have afterward a broken Network or a crash > > with the Installer. > > I tried to reproduce this and found it was indeed broken. > I tried to rename eth0->eth1 and eth1->eth0 on a two NIC system > and couldn't do that properly. But I did not get the installer to > crash. Please make a cc, than I can sent the YaST Logs. > I opened bug #894053, but since SLE bugs are not publicly visible, you > cannot see it. Let me know if you want to be put on the CC list > of that bug and give us more details of your problem. > > Thanks for testing! -- mit freundlichen Gr??en / best Regards, G?nther J. Niederwimmer From gjn at gjn.priv.at Thu Aug 28 11:02:10 2014 From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer) Date: Thu, 28 Aug 2014 19:02:10 +0200 Subject: [sles-beta] openvswitch LTE Version Message-ID: <1422703.rqXjlgJgD7@gjn.priv.at> Hello, can we have the LTE Version 2.3 from openvswitch in the SLES 12 I miss this in RC2 -- mit freundlichen Gr??en / best Regards, G?nther J. Niederwimmer From gjn at gjn.priv.at Thu Aug 28 11:06:11 2014 From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer) Date: Thu, 28 Aug 2014 19:06:11 +0200 Subject: [sles-beta] openvswitch LTE Version = > LTS Version In-Reply-To: <1422703.rqXjlgJgD7@gjn.priv.at> References: <1422703.rqXjlgJgD7@gjn.priv.at> Message-ID: <3300428.FhMV12z9rb@gjn.priv.at> Am Donnerstag, 28. August 2014, 19:02:10 schrieb G?nther J. Niederwimmer: > Hello, > > can we have the LTE Version 2.3 from openvswitch in the SLES 12 I miss this > in RC2 I mean LTS Version ;-) -- mit freundlichen Gr??en / best Regards, G?nther J. Niederwimmer From kukuk at suse.de Thu Aug 28 12:20:48 2014 From: kukuk at suse.de (Thorsten Kukuk) Date: Thu, 28 Aug 2014 20:20:48 +0200 Subject: [sles-beta] openvswitch LTE Version In-Reply-To: <1422703.rqXjlgJgD7@gjn.priv.at> References: <1422703.rqXjlgJgD7@gjn.priv.at> Message-ID: <20140828182048.GA6564@suse.de> On Thu, Aug 28, G?nther J. Niederwimmer wrote: > Hello, > > can we have the LTE Version 2.3 from openvswitch in the SLES 12 I miss this in > RC2 That was only released two weeks ago and contains some incompatible changes. When should we adjust our code and test that all? And when should our partners adjust their code? Sorry, but at some point of time we have to stop, and this point of time was RC1. Else SLES 12 will never come to market. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg) From radmanic at suse.com Fri Aug 29 02:05:44 2014 From: radmanic at suse.com (Milisav Radmanic) Date: Fri, 29 Aug 2014 10:05:44 +0200 Subject: [sles-beta] openvswitch LTE Version In-Reply-To: <1422703.rqXjlgJgD7@gjn.priv.at> References: <1422703.rqXjlgJgD7@gjn.priv.at> Message-ID: <54003458.8050902@suse.com> On 28.08.2014 19:02, G?nther J. Niederwimmer wrote: > Hello, > > can we have the LTE Version 2.3 from openvswitch in the SLES 12 I miss this in > RC2 as Thorsten already pointed out we have to freeze the version of a software package at some point in time, at least as soon as we have reached "Release Candidate" status we are not able to simply upgrade packages. Sometimes the timing is not ideal, but with all the packages on the SLES media there will always be these kind of situations. But we have made sure by discussing with the openvswitch community, to choose a version which will receive patches for a longer period. So, the openvswitch 2.1-branch we have put on SLE-12 will still receive patches and is not outdated with the release of the 2.3-branch. That is the reason why we've chosen the 2.1-branch instead of the already available 2.2-branch back then. best regards Milisav -- Milisav Radmanic Sr. Engineering Manager SUSE Linux Enterprise Applications SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg) Maxfeldstra?e 5 90409 N?rnberg Germany From gjn at gjn.priv.at Fri Aug 29 09:34:52 2014 From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer) Date: Fri, 29 Aug 2014 17:34:52 +0200 Subject: [sles-beta] Auth Server install broken Message-ID: <21045034.flYS0nU5TD@gjn.priv.at> Hello, I make a test installation from AUTH server but this is no more possible to start the LDAP Server The config files are missing ? The ldap.conf is empty, the ldap-pw file is missing. -- mit freundlichen Gr??en / best Regards, G?nther J. Niederwimmer From gjn at gjn.priv.at Fri Aug 29 10:01:54 2014 From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer) Date: Fri, 29 Aug 2014 18:01:54 +0200 Subject: [sles-beta] Auth Server install broken In-Reply-To: <21045034.flYS0nU5TD@gjn.priv.at> References: <21045034.flYS0nU5TD@gjn.priv.at> Message-ID: <1810219.5EZ6zQhfr7@gjn.priv.at> Hello, Am Freitag, 29. August 2014, 17:34:52 schrieb G?nther J. Niederwimmer: > Hello, > > I make a test installation from AUTH server but this is no more possible to > start the LDAP Server > > The config files are missing ? > > The ldap.conf is empty, the ldap-pw file is missing. Is it possible the YaST2 Module have a Problem with IPv6 Addresses I have my ext domain configured with a IPv6 static address and the hostname is on the ext Domain. Now I change my domain settings to a int. domain with IPv4 address now I have a running slapd ? -- mit freundlichen Gr??en / best Regards, G?nther J. Niederwimmer From gjn at gjn.priv.at Fri Aug 29 13:27:39 2014 From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer) Date: Fri, 29 Aug 2014 21:27:39 +0200 Subject: [sles-beta] openldap Packet broken Message-ID: <2178527.vkkg8vLgvR@gjn.priv.at> Hallo, now I found a big Problem, the OpenLDAP Packet is broken? OpenLDAP Packet don't create the user / group ldap I mean this is also the Problem I can't configure Ldap. I mean my problem is not the auth Server Module but the openldap Packet. -- mit freundlichen Gr??en / best Regards, G?nther J. Niederwimmer From abonilla at suse.com Fri Aug 29 13:39:30 2014 From: abonilla at suse.com (Alejandro Bonilla) Date: Fri, 29 Aug 2014 20:39:30 +0100 Subject: [sles-beta] openldap Packet broken In-Reply-To: <2178527.vkkg8vLgvR@gjn.priv.at> References: <2178527.vkkg8vLgvR@gjn.priv.at> Message-ID: <5400E503020000A2000A6E29@mail.emea.novell.com> ?Hi Gunther, Please open a service request and provide the details of what you are doing. If you see a difference from SLES11, please also note that and our developers will verify if this behavior change is due to a bug or a design need. Thanks Original Message From: G?nther J.Niederwimmer Sent: Friday, August 29, 2014 3:28 PM To: sles-beta at lists.suse.com Subject: [sles-beta] openldap Packet broken Hallo, now I found a big Problem, the OpenLDAP Packet is broken? OpenLDAP Packet don't create the user / group ldap I mean this is also the Problem I can't configure Ldap. I mean my problem is not the auth Server Module but the openldap Packet. -- mit freundlichen Gr??en / best Regards, G?nther J. Niederwimmer _______________________________________________ sles-beta mailing list sles-beta at lists.suse.com http://lists.suse.com/mailman/listinfo/sles-beta From kukuk at suse.de Fri Aug 29 13:41:26 2014 From: kukuk at suse.de (Thorsten Kukuk) Date: Fri, 29 Aug 2014 21:41:26 +0200 Subject: [sles-beta] openldap Packet broken In-Reply-To: <2178527.vkkg8vLgvR@gjn.priv.at> References: <2178527.vkkg8vLgvR@gjn.priv.at> Message-ID: <20140829194126.GA9465@suse.de> On Fri, Aug 29, G?nther J. Niederwimmer wrote: > Hallo, > > now I found a big Problem, the OpenLDAP Packet is broken? No. > OpenLDAP Packet don't create the user / group ldap I mean this is also the > Problem I can't configure Ldap. >From the spec file: %pre /usr/sbin/groupadd -g 70 -o -r ldap 2> /dev/null || : /usr/sbin/useradd -r -o -g ldap -u 76 -s /bin/bash -c "User for OpenLDAP" -d \ /var/lib/ldap ldap 2> /dev/null || : So the user and group ldap should be created. Please look in /var/log/zypp/history, if there is an error message about openldap installation. For me, it works. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer, HRB 16746 (AG N?rnberg) From gjn at gjn.priv.at Sat Aug 30 04:04:18 2014 From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer) Date: Sat, 30 Aug 2014 12:04:18 +0200 Subject: [sles-beta] openldap Packet broken In-Reply-To: <20140829194126.GA9465@suse.de> References: <2178527.vkkg8vLgvR@gjn.priv.at> <20140829194126.GA9465@suse.de> Message-ID: <2269910.96t0uo2KNg@gjn.priv.at> Hello Thorsten, Am Freitag, 29. August 2014, 21:41:26 schrieb Thorsten Kukuk: > On Fri, Aug 29, G?nther J. Niederwimmer wrote: > > Hallo, > > > > now I found a big Problem, the OpenLDAP Packet is broken? > > No. > > > OpenLDAP Packet don't create the user / group ldap I mean this is also the > > Problem I can't configure Ldap. > > From the spec file: > %pre > /usr/sbin/groupadd -g 70 -o -r ldap 2> /dev/null || : > /usr/sbin/useradd -r -o -g ldap -u 76 -s /bin/bash -c "User for OpenLDAP" -d > \ /var/lib/ldap ldap 2> /dev/null || : Yes, I found this in the Packet and create it per hand! but anything is wrong? with beta9 I can change / adapt anything, now it is not possible to adapt hdb (?) > So the user and group ldap should be created. > Please look in /var/log/zypp/history, if there is an error > message about openldap installation. > For me, it works. I tested it today ;) You are right, when I Install openlad as single packet I have the user / group ldap. But when I install over YaST2 auth Server I have no user / group ldap now I start to test to config openldap handy. after install with YaST2 Auth Server I have always the Error "Implementation Error" when I like to change anything, also when I create user / group ldap ? -- mit freundlichen Gr??en / best Regards, G?nther J. Niederwimmer From gjn at gjn.priv.at Sun Aug 31 07:01:23 2014 From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer) Date: Sun, 31 Aug 2014 15:01:23 +0200 Subject: [sles-beta] SLES-12 Beta9 X86_64 Message-ID: <1526371.HXpvGIRJYO@gjn.priv.at> Hello, can I found on any place Beta9 for Download again? Thanks. -- mit freundlichen Gr??en / best Regards, G?nther J. Niederwimmer