From kukuk at suse.de Mon Jun 9 13:25:42 2014 From: kukuk at suse.de (Thorsten Kukuk) Date: Mon, 9 Jun 2014 21:25:42 +0200 Subject: [sles-beta] lynx & perl-DBD-ODBC In-Reply-To: References: Message-ID: <20140609192542.GA7659@suse.de> On Mon, Jun 09, Wendy Palm wrote: > My apologies if this was included in documentation somewhere, but I've been unable to find it. > > Lynx - > We have a requirement for a non-GUI web browser on our systems - we'd used lynx before, but that appears to have disappeared from SLE 12. Is there a non-GUI web browser available, or will we need to download and support our own? lynx was never part of SLES, it was always w3m. 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 wendy at cray.com Mon Jun 9 13:27:36 2014 From: wendy at cray.com (Wendy Palm) Date: Mon, 9 Jun 2014 19:27:36 +0000 Subject: [sles-beta] lynx & perl-DBD-ODBC In-Reply-To: <20140609192542.GA7659@suse.de> References: <20140609192542.GA7659@suse.de> Message-ID: W3m? I'm afraid I don't understand that acronym. Lynx is in SLE 11 SP3 SDK. > -----Original Message----- > From: sles-beta-bounces at lists.suse.com [mailto:sles-beta- > bounces at lists.suse.com] On Behalf Of Thorsten Kukuk > Sent: Monday, June 09, 2014 2:26 PM > To: sles-beta at lists.suse.com > Subject: Re: [sles-beta] lynx & perl-DBD-ODBC > > On Mon, Jun 09, Wendy Palm wrote: > > > My apologies if this was included in documentation somewhere, but I've > been unable to find it. > > > > Lynx - > > We have a requirement for a non-GUI web browser on our systems - we'd > used lynx before, but that appears to have disappeared from SLE 12. Is there > a non-GUI web browser available, or will we need to download and support > our own? > > lynx was never part of SLES, it was always w3m. > > 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 wendy at cray.com Mon Jun 9 13:32:33 2014 From: wendy at cray.com (Wendy Palm) Date: Mon, 9 Jun 2014 19:32:33 +0000 Subject: [sles-beta] lynx & perl-DBD-ODBC References: <20140609192542.GA7659@suse.de> Message-ID: Ah, I looked up a bit, and w3m is another text-based browser. I'm checking with the site to see if it's a suitable replacement for lynx. However, lynx has indeed been in SLE 11 sp3 SDK. > -----Original Message----- > From: Wendy Palm > Sent: Monday, June 09, 2014 2:28 PM > To: 'Thorsten Kukuk'; sles-beta at lists.suse.com > Subject: RE: [sles-beta] lynx & perl-DBD-ODBC > > W3m? I'm afraid I don't understand that acronym. > > Lynx is in SLE 11 SP3 SDK. > > > > -----Original Message----- > > From: sles-beta-bounces at lists.suse.com [mailto:sles-beta- > > bounces at lists.suse.com] On Behalf Of Thorsten Kukuk > > Sent: Monday, June 09, 2014 2:26 PM > > To: sles-beta at lists.suse.com > > Subject: Re: [sles-beta] lynx & perl-DBD-ODBC > > > > On Mon, Jun 09, Wendy Palm wrote: > > > > > My apologies if this was included in documentation somewhere, but I've > > been unable to find it. > > > > > > Lynx - > > > We have a requirement for a non-GUI web browser on our systems - > we'd > > used lynx before, but that appears to have disappeared from SLE 12. Is > there > > a non-GUI web browser available, or will we need to download and > support > > our own? > > > > lynx was never part of SLES, it was always w3m. > > > > 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 mpost at suse.com Mon Jun 9 14:23:33 2014 From: mpost at suse.com (Mark Post) Date: Mon, 09 Jun 2014 14:23:33 -0600 Subject: [sles-beta] lynx & perl-DBD-ODBC In-Reply-To: References: <20140609192542.GA7659@suse.de> Message-ID: <5395DF850200006D001645A9@prv-mh.provo.novell.com> >>> On 6/9/2014 at 03:32 PM, Wendy Palm wrote: > Ah, I looked up a bit, and w3m is another text-based browser. > > I'm checking with the site to see if it's a suitable replacement for lynx. > > However, lynx has indeed been in SLE 11 sp3 SDK. Just to clarify some terminology, when you say "in SLES" that doesn't include the SDK. The SDK is an unsupported set of packages, separate from SLES (or SLED). So you are correct in that lynx was in the SLE11 SDK, but not in the SLE12 SDK. Thorsten is also correct that lynx was "never part of SLES." The different mind set about what gets called what can be confusing if you're not familiar with it. Why it's not part of the SLE12 SDK, I have no idea. That is likely worth opening an SR to find out. It could very well have been a mistake. Mark Post From wendy at cray.com Mon Jun 9 15:30:45 2014 From: wendy at cray.com (Wendy Palm) Date: Mon, 9 Jun 2014 21:30:45 +0000 Subject: [sles-beta] lynx & perl-DBD-ODBC In-Reply-To: <5395DF850200006D001645A9@prv-mh.provo.novell.com> References: <20140609192542.GA7659@suse.de> <5395DF850200006D001645A9@prv-mh.provo.novell.com> Message-ID: My original email stated SLE 12, and I'd neglected to include SDK - my apologies for that confusion. Given that the SDK isos are showing up within the SLES download areas, I wasn't being careful about clarity. SR 10896179801 (lynx) and SR 10896179816 (perl-DBD-ODBC) submitted. > -----Original Message----- > From: sles-beta-bounces at lists.suse.com [mailto:sles-beta- > bounces at lists.suse.com] On Behalf Of Mark Post > Sent: Monday, June 09, 2014 3:24 PM > To: sles-beta at lists.suse.com > Subject: Re: [sles-beta] lynx & perl-DBD-ODBC > > >>> On 6/9/2014 at 03:32 PM, Wendy Palm wrote: > > Ah, I looked up a bit, and w3m is another text-based browser. > > > > I'm checking with the site to see if it's a suitable replacement for lynx. > > > > However, lynx has indeed been in SLE 11 sp3 SDK. > > Just to clarify some terminology, when you say "in SLES" that doesn't include > the SDK. The SDK is an unsupported set of packages, separate from SLES (or > SLED). So you are correct in that lynx was in the SLE11 SDK, but not in the > SLE12 SDK. Thorsten is also correct that lynx was "never part of SLES." The > different mind set about what gets called what can be confusing if you're not > familiar with it. > > Why it's not part of the SLE12 SDK, I have no idea. That is likely worth > opening an SR to find out. It could very well have been a mistake. > > > Mark Post > > _______________________________________________ > sles-beta mailing list > sles-beta at lists.suse.com > http://lists.suse.com/mailman/listinfo/sles-beta From kukuk at suse.de Tue Jun 10 01:13:55 2014 From: kukuk at suse.de (Thorsten Kukuk) Date: Tue, 10 Jun 2014 09:13:55 +0200 Subject: [sles-beta] lynx & perl-DBD-ODBC In-Reply-To: <5395DF850200006D001645A9@prv-mh.provo.novell.com> References: <20140609192542.GA7659@suse.de> <5395DF850200006D001645A9@prv-mh.provo.novell.com> Message-ID: <20140610071355.GA1654@suse.de> On Mon, Jun 09, Mark Post wrote: > >>> On 6/9/2014 at 03:32 PM, Wendy Palm wrote: > > Ah, I looked up a bit, and w3m is another text-based browser. > > > > I'm checking with the site to see if it's a suitable replacement for lynx. > > > > However, lynx has indeed been in SLE 11 sp3 SDK. > > Just to clarify some terminology, when you say "in SLES" that doesn't include the SDK. The SDK is an unsupported set of packages, separate from SLES (or SLED). So you are correct in that lynx was in the SLE11 SDK, but not in the SLE12 SDK. Thorsten is also correct that lynx was "never part of SLES." The different mind set about what gets called what can be confusing if you're not familiar with it. > > Why it's not part of the SLE12 SDK, I have no idea. That is likely worth opening an SR to find out. It could very well have been a mistake. lynx is not a development package and was only on the SLE11 SDK because of dependencies. -- 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 Dick.Waite at softwareag.com Tue Jun 10 01:27:06 2014 From: Dick.Waite at softwareag.com (Waite, Dick) Date: Tue, 10 Jun 2014 07:27:06 +0000 Subject: [sles-beta] Beta8 - Registration - Upadte - SR - Issues Message-ID: <46AC8C81C10B8C48820201DF2AE1D76D5384781F@hqmbx6.eur.ad.sag> Grand Morning, Zip file attached. I did try for some time to create a SR but it seems to be having a bad hair day. I'll try again later. When running an Update from a very basic SLE11-SP3 machine, VMware Workstation enviroment x86_64 and no network, I got some nags about the Registration which I have not seen before and when we got to the Update Software I was asked to check manually. I did start but did not like some of the options one was asked to do, so I exited stage left. I'll try a new install to see if I get the Registration nags. Have a grand day. ___________________________________________ Dick Waite Senior R&D Consultant Phone: +49 6151 92-1505 Mobile: +49 171 8393 769 Software AG Uhlandstr. 12 | 64297 Darmstadt | Germany www.softwareag.com ___________________________________________ 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 -------------- A non-text attachment was scrubbed... Name: SLE-12-Beta8_00.zip Type: application/x-zip-compressed Size: 1463994 bytes Desc: SLE-12-Beta8_00.zip URL: From Klaus.Gmeinwieser at oce.com Tue Jun 10 02:43:11 2014 From: Klaus.Gmeinwieser at oce.com (Klaus Gmeinwieser) Date: Tue, 10 Jun 2014 10:43:11 +0200 Subject: [sles-beta] SLE 12 Beta8 is available In-Reply-To: <1402084535.15734.2.camel@par-r81vxc7.par.novell.com> References: <1402084535.15734.2.camel@par-r81vxc7.par.novell.com> Message-ID: <5396C51F.4050907@oce.com> Hi all, I downloaded Beta 8 today and started testing on my Fujitsu Servers with autoyast and my previous version of autoinst.xml - Root filesystem on XFS leads to an unbootable system (worked till B7) error: attempt tp read or write outside of partition error: file /boot/grub2/i386-pc-normal.mod not found which leads to ANY of my installations to fail :( -> Please advise on how I can resolve this!!! - KDUMP is still enabled regardless of the settings in xml file - autoyast=usb still does not work (need to manually mount the Stick and type file:/// in the dialog box) I am wondering about the new window, which is available since Beta8 to enable additional "Modules". Is it already possible to select a module offline for an "ISO only" install or is this to be done in a later Beta. I would highly appreciate a little HowTo for an offline Install with autoyast including modules. Regards Klaus -- Klaus Gmeinwieser T +49 (0)8121 72 4358 F +49 (0)8121 72 3173 E klaus.gmeinwieser at oce.com W www.oce.com Oc? Printing Systems GmbH & Co. KG ? A Canon Group Company P.O. Box 1260 ? 85581 Poing Siemensallee 2 ? 85586 Poing ? Germany Oc? enables its customers to manage their documents efficiently and effectively by offering innovative print and document management products and services for professional environments. Oc? Printing Systems GmbH & Co. KG The company is a limited partnership with its registered office in Poing ? Trade Register HRA 100955 (Amtsgericht M?nchen) ? WEEE-Reg.-No. DE 888 05 443 General Partner: Oc? Printing Systems Gesch?ftsf?hrungsgesellschaft mbH Registered Office: Poing ? Trade Register HRB 206480 (Amtsgericht M?nchen) Executive Officer: Andr? Mittelsteiner This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message. Thank you for your co-operation. From fcrozat at suse.com Tue Jun 10 03:12:20 2014 From: fcrozat at suse.com (Frederic Crozat) Date: Tue, 10 Jun 2014 11:12:20 +0200 Subject: [sles-beta] SLE 12 Beta8 is available In-Reply-To: <5396C51F.4050907@oce.com> References: <1402084535.15734.2.camel@par-r81vxc7.par.novell.com> <5396C51F.4050907@oce.com> Message-ID: <1402391540.2933.20.camel@par-r81vxc7.par.novell.com> Le mardi 10 juin 2014 ? 10:43 +0200, Klaus Gmeinwieser a ?crit : > Hi all, > > I downloaded Beta 8 today and started testing on my Fujitsu Servers with > autoyast and my previous version of autoinst.xml > > - Root filesystem on XFS leads to an unbootable system (worked till B7) > > error: attempt tp read or write outside of partition > error: file /boot/grub2/i386-pc-normal.mod not found > > which leads to ANY of my installations to fail :( > -> Please advise on how I can resolve this!!! You need to wait for Beta9 for it to be fixed (it was mentioned in the known issues of Beta8). -- Frederic Crozat Project Manager Enterprise Desktop SUSE From Dick.Waite at softwareag.com Tue Jun 10 05:11:41 2014 From: Dick.Waite at softwareag.com (Waite, Dick) Date: Tue, 10 Jun 2014 11:11:41 +0000 Subject: [sles-beta] Beta8 - Update - VMware - Startup Message-ID: <46AC8C81C10B8C48820201DF2AE1D76D53847994@hqmbx6.eur.ad.sag> Grand Hot Afternoon, I feel in the attached zips we have some answers as to why a VMware machine does not update clean. I will create a SR when the good Novell system lets me. Have to good and fix a customers database now, but should be back on-line in home_office in the morning. Hope to see the answers to the questions ;o) __R ___________________________________________ Dick Waite Senior R&D Consultant Phone: +49 6151 92-1505 Mobile: +49 171 8393 769 Software AG Uhlandstr. 12 | 64297 Darmstadt | Germany www.softwareag.com ___________________________________________ 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 -------------- A non-text attachment was scrubbed... Name: SLE-12-Beta8_03.zip Type: application/x-zip-compressed Size: 952794 bytes Desc: SLE-12-Beta8_03.zip URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SLE-12-Beta8_01.zip Type: application/x-zip-compressed Size: 1404597 bytes Desc: SLE-12-Beta8_01.zip URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SLE-12-Beta8_02.zip Type: application/x-zip-compressed Size: 539653 bytes Desc: SLE-12-Beta8_02.zip URL: From kukuk at suse.de Tue Jun 10 05:38:27 2014 From: kukuk at suse.de (Thorsten Kukuk) Date: Tue, 10 Jun 2014 13:38:27 +0200 Subject: [sles-beta] Beta8 - Update - VMware - Startup In-Reply-To: <46AC8C81C10B8C48820201DF2AE1D76D53847994@hqmbx6.eur.ad.sag> References: <46AC8C81C10B8C48820201DF2AE1D76D53847994@hqmbx6.eur.ad.sag> Message-ID: <20140610113827.GA25610@suse.de> Hi, On Tue, Jun 10, Waite, Dick wrote: > Grand Hot Afternoon, > > I feel in the attached zips we have some answers as to why a VMware machine does not update clean. I will create a SR when the good Novell system lets me. Hm, according to the pictures, the update was successfull and does boot? The grub2 branding problem should be fixed with the next Beta. The kde -> gnome migration: I'm afraid this got somehow broken in your case during your manual resolving of the kdelibs4-branding conflict. Since the screenshot shows the conflict only to 50%, it's impossible to say what the problem is. 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 kukuk at suse.de Tue Jun 10 07:48:26 2014 From: kukuk at suse.de (Thorsten Kukuk) Date: Tue, 10 Jun 2014 15:48:26 +0200 Subject: [sles-beta] SLES12 beta8 x86_64 net.ifnames=0 inconstisten result on BL460c-Gen8 In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0F9A180E@HXMB12.pnet.ch> References: <40637DBB36AF3941B243A286A432CA0B0F9A180E@HXMB12.pnet.ch> Message-ID: <20140610134826.GA5551@suse.de> On Tue, Jun 10, urs.frey at post.ch wrote: > Hi > > When installing SLES12 x86_64 Beta8 on BL460c-Gen8 using net.ifnames=0 I get the interfaces mixed up > > Before until Beta7 I could use the first NIC as eth0 and in my LinuxRc info file I could define eth0 with its MAC > This has now been somehow mixed up > When using udev.rule: "mac=b4:b5:2f:57:a5:90,name=eth0" in my linuxrc info file I get now eth2 having MAC b4:b5:2f:57:a5:90. > So of course the installation does fail > > If I do not use net.ifnames=0 on my kernel boot prompt I get eth0 > > I am confused, what to use now on HP Blades? If it works fine without net.ifnames=0, don't use it. Quite simple :) predictable names are disabled for now. 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 urs.frey at post.ch Tue Jun 10 08:03:19 2014 From: urs.frey at post.ch (urs.frey at post.ch) Date: Tue, 10 Jun 2014 14:03:19 +0000 Subject: [sles-beta] SLES12 beta8 x86_64 net.ifnames=0 inconstisten result on BL460c-Gen8 In-Reply-To: <20140610134826.GA5551@suse.de> References: <40637DBB36AF3941B243A286A432CA0B0F9A180E@HXMB12.pnet.ch> <20140610134826.GA5551@suse.de> Message-ID: <40637DBB36AF3941B243A286A432CA0B0F9A186E@HXMB12.pnet.ch> Hi Thorsten >predictable names are disabled for now. Thank you 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, June 10, 2014 3:48 PM An: sles-beta at lists.suse.com Betreff: Re: [sles-beta] SLES12 beta8 x86_64 net.ifnames=0 inconstisten result on BL460c-Gen8 On Tue, Jun 10, urs.frey at post.ch wrote: > Hi > > When installing SLES12 x86_64 Beta8 on BL460c-Gen8 using net.ifnames=0 I get the interfaces mixed up > > Before until Beta7 I could use the first NIC as eth0 and in my LinuxRc info file I could define eth0 with its MAC > This has now been somehow mixed up > When using udev.rule: "mac=b4:b5:2f:57:a5:90,name=eth0" in my linuxrc info file I get now eth2 having MAC b4:b5:2f:57:a5:90. > So of course the installation does fail > > If I do not use net.ifnames=0 on my kernel boot prompt I get eth0 > > I am confused, what to use now on HP Blades? If it works fine without net.ifnames=0, don't use it. Quite simple :) predictable names are disabled for now. 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 jbohac at suse.cz Tue Jun 10 10:17:26 2014 From: jbohac at suse.cz (Jiri Bohac) Date: Tue, 10 Jun 2014 18:17:26 +0200 Subject: [sles-beta] SLES12 beta8 x86_64 net.ifnames=0 inconstisten result on BL460c-Gen8 In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0F9A1840@HXMB12.pnet.ch> References: <40637DBB36AF3941B243A286A432CA0B0F9A1840@HXMB12.pnet.ch> Message-ID: <20140610161726.GA4350@midget.suse.cz> Hi, On Tue, Jun 10, 2014 at 01:59:01PM +0000, urs.frey at post.ch wrote: > When using > : net.ifnames=0, I get eth1 and eth2 > : net.ifnames=1, I get eno1 and eno2 > : no-parameter, I get eth1 and eth2 net.ifnames=0 is now the default. In addition, SLE 12 now uses the same mechanisms to provide persistent interface names as SLE 11. That's why net.ifnames=0 behaves the same as no command-line parameter at all. net.ifnames=1 can be used to turn on the "predictable" interface names. > Before until Beta7 I could use the first NIC as eth0 and in my LinuxRc info file I could define eth0 with its MAC > This has now been somehow mixed up > When using udev.rule: "mac=b4:b5:2f:57:a5:90,name=eth0" in my linuxrc info file I get now eth2 having MAC b4:b5:2f:57:a5:90. > So of course the installation does fail It seems the linuxrc parameter mac=b4:b5:2f:57:a5:90,name=eth0 does not work. Probably, the udev rule that it creates in /etc/udev/rules.d/70-persistent-net.rules does not match your NIC, but the udev persistent name generator sees eth0 as being assigned so it invents another name: eth2. Could you please report this in Bugzilla? It would be helpful if you could configure linuxrc to drop you in a shell and then post the contents of /etc/udev/rules.d/70-persistent-net.rules My guess is that the linuxrc generated rule did not work in previous Betas either, but there was not peristent name generator that would see eth0 as occupied and invent another name. Thanks, -- Jiri Bohac SUSE Labs, SUSE CZ From darrent at akurit.com.au Tue Jun 10 14:43:29 2014 From: darrent at akurit.com.au (Darren Thompson) Date: Wed, 11 Jun 2014 06:43:29 +1000 Subject: [sles-beta] SLES12 beta8 x86_64 net.ifnames=0 inconstisten result on BL460c-Gen8 In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0F9A180E@HXMB12.pnet.ch> References: <40637DBB36AF3941B243A286A432CA0B0F9A180E@HXMB12.pnet.ch> Message-ID: Team In my test builds I have gotten the older "ethX" type names again, it looks like they have reverted the behaviour as if net.ifnames=0 is the default. This would match what the change you listed is indicating. Darren On 10 June 2014 23:34, wrote: > Hi > > When installing SLES12 x86_64 Beta8 on BL460c-Gen8 using net.ifnames=0 I > get the interfaces mixed up > > Before until Beta7 I could use the first NIC as eth0 and in my LinuxRc > info file I could define eth0 with its MAC > This has now been somehow mixed up > When using udev.rule: "mac=b4:b5:2f:57:a5:90,name=eth0" in my linuxrc info > file I get now eth2 having MAC b4:b5:2f:57:a5:90. > So of course the installation does fail > > If I do not use net.ifnames=0 on my kernel boot prompt I get eth0 > > I am confused, what to use now on HP Blades? > > In the changelog I can see this entry > When looking here, > *http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/* > > , net.ifnames=0 is defined for failback to eth0, disable ?predictable NIC > names. > What does the changelog mean exactly? What do I have to use to disable? > ------------------------------------------- > o Updated systemd (security/bugfix/feature) > > - Fix enabling predictable rules when using net.ifnames=1. > update: 1021-udev-re-add-persistent-net-rules.patch > - Re-add persistent rules as a default and make predictable rules as > fallback (bnc#880732). > add: 1021-udev-re-add-persistent-net-rules.patch > --------------------------------------------- > > Thank you very much for a feedback > > 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* > > > > > _______________________________________________ > sles-beta mailing list > sles-beta at lists.suse.com > http://lists.suse.com/mailman/listinfo/sles-beta > > -- Darren Thompson Professional Services Engineer / Consultant *[image: cid:image001.jpg at 01CB7C0C.6C6A2AE0]* Level 3, 60 City Road Southgate, VIC 3006 Mb: 0400 640 414 Mail: darrent at akurit.com.au Web: www.akurit.com.au -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 3692 bytes Desc: not available URL: From darrent at akurit.com.au Tue Jun 10 14:48:38 2014 From: darrent at akurit.com.au (Darren Thompson) Date: Wed, 11 Jun 2014 06:48:38 +1000 Subject: [sles-beta] SLES12 x86_64 Beta8 KVM Client installation using virt-manager console dies immediately In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0F9A18EC@HXMB12.pnet.ch> References: <40637DBB36AF3941B243A286A432CA0B0F9A18EC@HXMB12.pnet.ch> Message-ID: Team I have found that I have to create the virbr0 device (within Virt0manager's "networks" configuraation, prior to creating a VM). When I create a VM, I then have to "specify" to use the virbr0 device using the "input bridge name" option. Only then does it allow me to install a VM. That is with XEN, I supect similar behaviour/work arounds are required for KVM too. Darren On 11 June 2014 01:17, wrote: > Hi > > > > When trying to install a SLES12 Beta8 KVM Client on a SLES12 x86_64 Beta8 > KVM Host using virt-manager the remote console dies immediately also > killing virt-manager > > > > When clicking on the sles12 client here to open the console, virt-manager > dies immediately, making an installation of a KVM client impossible > > > > > > Ideas how I can work around this, to install a SLES12 KVM client on a KVM > SLES12 host? > > > > > > 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 > > -- Darren Thompson Professional Services Engineer / Consultant *[image: cid:image001.jpg at 01CB7C0C.6C6A2AE0]* Level 3, 60 City Road Southgate, VIC 3006 Mb: 0400 640 414 Mail: darrent at akurit.com.au Web: www.akurit.com.au -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 33646 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 3692 bytes Desc: not available URL: From darrent at akurit.com.au Tue Jun 10 22:27:43 2014 From: darrent at akurit.com.au (Darren Thompson) Date: Wed, 11 Jun 2014 14:27:43 +1000 Subject: [sles-beta] YaST2 from SSH failing again with SLES12B8 Message-ID: Team I cannot get YaST2 to run any of it's modules when run through SSH (with X-forwarding enabled)... Again... YaST2 itself starts without error, but when a module is selected I get a "bouncing thing" which stops after a few minutes and no further activity. The "ssh shell" gets this echoed when this issue is occurring: "linux-7z01:~ # ** (y2controlcenter-gnome:5138): WARNING **: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-21DTG0iwLz: Connection refused /usr/bin/xdg-su: line 503: 5163 Segmentation fault xterm -geom 60x5 -T "xdg-su: $cmd" -e su -c "$cmd" " This is the second time I have seen this behaviour (it also happened in B6, seemed to be resolved in B7 and is now back in B8) -- Darren Thompson Professional Services Engineer / Consultant *[image: cid:image001.jpg at 01CB7C0C.6C6A2AE0]* Level 3, 60 City Road Southgate, VIC 3006 Mb: 0400 640 414 Mail: darrent at akurit.com.au Web: www.akurit.com.au -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 3692 bytes Desc: not available URL: From Dick.Waite at softwareag.com Wed Jun 11 00:44:50 2014 From: Dick.Waite at softwareag.com (Waite, Dick) Date: Wed, 11 Jun 2014 06:44:50 +0000 Subject: [sles-beta] Beta8 - Update - VMware - Startup In-Reply-To: <46AC8C81C10B8C48820201DF2AE1D76D53847D6E@hqmbx6.eur.ad.sag> References: <46AC8C81C10B8C48820201DF2AE1D76D53847994@hqmbx6.eur.ad.sag>, <20140610113827.GA25610@suse.de>, <46AC8C81C10B8C48820201DF2AE1D76D53847D6E@hqmbx6.eur.ad.sag> Message-ID: <46AC8C81C10B8C48820201DF2AE1D76D53847DD3@hqmbx6.eur.ad.sag> Many Thanks for the good words Thorsten. I'd like SUSE to understand why for me (SAG) and I think others an Update / Upgrade is my bread and butter and a new Install is only done a couple of times a year. I have "lots" of virtual machines loaded with various configuration of SAG's application. When a new Beta starts I do run a New Install with Beta 1 and 2 on x86_64 and if they work I run on zLinux. When the New Installs are looking good, I then run "Update / Upgrade" on a clone of an Application machine. I need to know our application are compatible with your new release. If the "simple" application machine passes its QE checks, then we clone more complex application machine and we run QE against these. The QE can last a day or a week or .... The same when we get new hardware, a known working environment is cloned onto the hardware, QE run and run and maybe after a few months that hardware gets a stamp. I am not going to use a New Install and then load and configure the applications, which often take weeks, 'cos this is not what our customers do or what we encourage. Evolution is our and I think many others way. We know the application works, its got a stamp, we know the hardware works, its got a stamp, so we create the "clone" attach the two new iso's, we do need the SDK, and run an Update/Upgrade and when this is finished, then the simple and complex QE cycles are started. My 1st "M/F" was a grand old Marconi in 1972. There was no way you could run a New Install, you had to "Update" the next machine from what you had on the 1st one. The same in the '80 with ICL and IBM, updates were the way... "Do not change two items at the same time", very often in SPOD and Sys_prog offices. In the '90 you could New Install, not sure how many did. I did run a new install Jan 3rd 2000. I had been in POK on Dec 18th when IBM told a select few about Linux for zSeries. For that one it was a new build, but since 2002 I have tried very hard to run Updates/Upgrade and these all came from good city of Neuerburg. I'm not trying to say the good people on x86_64 don't care or worry as much, we have some very large x86_64 environments and we work these the same as zSeries. I don't need a New Install and I'm sure many shops on this list don't use New Installs, Update / Upgrade what is working on the hardware under it and the applications running on it. Keep it simple stupid (KISS), the grand motto of IT. So I'll be there on the 18th looking for Beta9, I hope I don't have to do any manual intervention and the issues seen on the attached zip are also fixed. I did attached two zips, but it seems only one get to the the list, sorry, I hope this zip gives you the other 50% of the picture. To finish the picture, when your new release has been running for "some time", we then use the new compilers and goodies and see how our application can "exploit" these new features. Yes it takes time but customers like their database's running 24*7*365, no database, no profits or customers. Why not try on the next release to get your Update/Upgrade working first, when I think you will find the New Install falls out from this, least it did in the '80s ;o) Wishing you all a very good day, and a very successful SLES 12 __R ________________________________________ From: sles-beta-bounces at lists.suse.com [sles-beta-bounces at lists.suse.com] on behalf of Thorsten Kukuk [kukuk at suse.de] Sent: 10 June 2014 13:38 Cc: 'sles-beta at lists.suse.com' Subject: Re: [sles-beta] Beta8 - Update - VMware - Startup Hi, On Tue, Jun 10, Waite, Dick wrote: > Grand Hot Afternoon, > > I feel in the attached zips we have some answers as to why a VMware machine does not update clean. I will create a SR when the good Novell system lets me. Hm, according to the pictures, the update was successfull and does boot? The grub2 branding problem should be fixed with the next Beta. The kde -> gnome migration: I'm afraid this got somehow broken in your case during your manual resolving of the kdelibs4-branding conflict. Since the screenshot shows the conflict only to 50%, it's impossible to say what the problem is. 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 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 -------------- A non-text attachment was scrubbed... Name: SLE-12-Beta8_01.zip Type: application/x-zip-compressed Size: 1404597 bytes Desc: SLE-12-Beta8_01.zip URL: From urs.frey at post.ch Wed Jun 11 00:55:41 2014 From: urs.frey at post.ch (urs.frey at post.ch) Date: Wed, 11 Jun 2014 06:55:41 +0000 Subject: [sles-beta] SLES12 beta8 x86_64 net.ifnames=0 inconstisten result on BL460c-Gen8 In-Reply-To: <20140610161726.GA4350@midget.suse.cz> References: <40637DBB36AF3941B243A286A432CA0B0F9A1840@HXMB12.pnet.ch> <20140610161726.GA4350@midget.suse.cz> Message-ID: <40637DBB36AF3941B243A286A432CA0B0F9A197F@HXMB12.pnet.ch> Hello Jiri In fact I mismatched the NIC MAC of my server. My fault, sorry. >It seems the linuxrc parameter mac=b4:b5:2f:57:a5:90,name=eth0 >does not work. Probably, the udev rule that it creates in >/etc/udev/rules.d/70-persistent-net.rules >does not match your NIC, but the udev persistent name generator >sees eth0 as being assigned so it invents another name: eth2. Absolutely correct what you supposed above. So when using the correct MAC of my first NIC on the Motherboard, then I get the correct udev rule entry and everything works This is my LinuxRC info file I use, please observe the changed MAC v04yf4:/appl/custom_iso # cat info_sles12_h05cni insmod : hpsa insmod : be2net net.ifnames : 0 netwait : 40 splash : verbose install: http://172.27.40.68/sles12_64 netdevice: eth0 hostname: h05cni hostip: 10.226.169.29 netmask: 255.255.255.0 gateway: 10.226.169.254 nameserver: 10.1.121.11 autoyast: http://172.27.40.68/pstkits/profiles/sles12_autoinst_h05cni.xml netsetup:-dhcp,+hostip,+gateway,+netmask,+nameserver udev.rule: "mac=3c:d9:2b:f6:a3:e0,name=eth0" v04yf4:/appl/custom_iso # These are the udev rules I get on the installed server freyu at h05cni:~> cat /etc/udev/rules.d/70-persistent-net.rules # PCI device 0x19a2:0x0710 (be2net) # PCI device 0x19a2:0x0710 (be2net) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="3c:d9:2b:f6:a3:e0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0" SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="3c:d9:2b:f6:a3:e4", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1" freyu at h05cni:~> NO BUG Thank you very much 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: Jiri Bohac [mailto:jbohac at suse.cz] Gesendet: Tuesday, June 10, 2014 6:17 PM An: Frey Urs, IT222 Cc: sles-beta at lists.suse.com Betreff: Re: [sles-beta] SLES12 beta8 x86_64 net.ifnames=0 inconstisten result on BL460c-Gen8 Hi, On Tue, Jun 10, 2014 at 01:59:01PM +0000, urs.frey at post.ch wrote: > When using > : net.ifnames=0, I get eth1 and eth2 > : net.ifnames=1, I get eno1 and eno2 > : no-parameter, I get eth1 and eth2 net.ifnames=0 is now the default. In addition, SLE 12 now uses the same mechanisms to provide persistent interface names as SLE 11. That's why net.ifnames=0 behaves the same as no command-line parameter at all. net.ifnames=1 can be used to turn on the "predictable" interface names. > Before until Beta7 I could use the first NIC as eth0 and in my LinuxRc info file I could define eth0 with its MAC > This has now been somehow mixed up > When using udev.rule: "mac=b4:b5:2f:57:a5:90,name=eth0" in my linuxrc info file I get now eth2 having MAC b4:b5:2f:57:a5:90. > So of course the installation does fail It seems the linuxrc parameter mac=b4:b5:2f:57:a5:90,name=eth0 does not work. Probably, the udev rule that it creates in /etc/udev/rules.d/70-persistent-net.rules does not match your NIC, but the udev persistent name generator sees eth0 as being assigned so it invents another name: eth2. Could you please report this in Bugzilla? It would be helpful if you could configure linuxrc to drop you in a shell and then post the contents of /etc/udev/rules.d/70-persistent-net.rules My guess is that the linuxrc generated rule did not work in previous Betas either, but there was not peristent name generator that would see eth0 as occupied and invent another name. Thanks, -- Jiri Bohac SUSE Labs, SUSE CZ From jreidinger at suse.com Wed Jun 11 02:56:58 2014 From: jreidinger at suse.com (Josef Reidinger) Date: Wed, 11 Jun 2014 10:56:58 +0200 Subject: [sles-beta] SLES12 beta8 x86_64 Waiting time at "Register Extensions and Modules" In-Reply-To: <40637DBB36AF3941B243A286A432CA0B0F9A1A34@HXMB12.pnet.ch> References: <40637DBB36AF3941B243A286A432CA0B0F9A1A34@HXMB12.pnet.ch> Message-ID: <20140611105658.3226041d@dhcp150.suse.cz> On Wed, 11 Jun 2014 08:51:55 +0000 wrote: > Hi > > When installing SLES12 x86_64 Beta8 as it already was with Beta7, > there is the new screen to select Modules > > But when I do NOT select a module to install "no tick" in "I would > like to.." [cid:image001.png at 01CF8563.28DDBA30] > Then on the following screen I have to wait for minutes until the > installation continues. I have no internet access here. I am in a > server environment behind firewalls > > [cid:image002.png at 01CF8563.28DDBA30] > > This is a real NO GO > I really do not like waiting for timeouts Hi Urs, This is fixed for Beta9. I think it is independent on what you select on previous checkbox as it is part of accepting online licenses, which is fixed to be skipped if you skip registration to SCC ( or others like SMT ). Thanks for testing Josef From urs.frey at post.ch Wed Jun 11 02:59:48 2014 From: urs.frey at post.ch (urs.frey at post.ch) Date: Wed, 11 Jun 2014 08:59:48 +0000 Subject: [sles-beta] SLES12 beta8 x86_64 Waiting time at "Register Extensions and Modules" In-Reply-To: <20140611105658.3226041d@dhcp150.suse.cz> References: <40637DBB36AF3941B243A286A432CA0B0F9A1A34@HXMB12.pnet.ch> <20140611105658.3226041d@dhcp150.suse.cz> Message-ID: <40637DBB36AF3941B243A286A432CA0B0F9A1A4A@HXMB12.pnet.ch> Hello Josef This is really good news! Thank you very much, indeed. 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 Josef Reidinger Gesendet: Wednesday, June 11, 2014 10:57 AM An: sles-beta at lists.suse.com Betreff: Re: [sles-beta] SLES12 beta8 x86_64 Waiting time at "Register Extensions and Modules" On Wed, 11 Jun 2014 08:51:55 +0000 wrote: > Hi > > When installing SLES12 x86_64 Beta8 as it already was with Beta7, > there is the new screen to select Modules > > But when I do NOT select a module to install "no tick" in "I would > like to.." [cid:image001.png at 01CF8563.28DDBA30] > Then on the following screen I have to wait for minutes until the > installation continues. I have no internet access here. I am in a > server environment behind firewalls > > [cid:image002.png at 01CF8563.28DDBA30] > > This is a real NO GO > I really do not like waiting for timeouts Hi Urs, This is fixed for Beta9. I think it is independent on what you select on previous checkbox as it is part of accepting online licenses, which is fixed to be skipped if you skip registration to SCC ( or others like SMT ). Thanks for testing Josef _______________________________________________ sles-beta mailing list sles-beta at lists.suse.com http://lists.suse.com/mailman/listinfo/sles-beta From Dick.Waite at softwareag.com Wed Jun 11 23:49:20 2014 From: Dick.Waite at softwareag.com (Waite, Dick) Date: Thu, 12 Jun 2014 05:49:20 +0000 Subject: [sles-beta] SLES 12 Beta8 - Issues with Update/upgrade - SR created Message-ID: <46AC8C81C10B8C48820201DF2AE1D76D53848362@hqmbx6.eur.ad.sag> Grand Day, Service Request: 10896530451 Has been created and 4 zips attached. __R ___________________________________________ Dick Waite Senior R&D Consultant Phone: +49 6151 92-1505 Mobile: +49 171 8393 769 Software AG Uhlandstr. 12 | 64297 Darmstadt | Germany www.softwareag.com ___________________________________________ 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 darrent at akurit.com.au Thu Jun 12 15:17:38 2014 From: darrent at akurit.com.au (Darren Thompson) Date: Fri, 13 Jun 2014 07:17:38 +1000 Subject: [sles-beta] Lots of basic service failing to start with SLES12B8 In-Reply-To: References: Message-ID: oops Actually left out the most important bit of log, where udev failes... node1:~ # journalctl | grep failed Jun 13 07:08:54 localhost kernel: tsc: Fast TSC calibration failed Jun 13 07:08:54 localhost kernel: tsc: Marking TSC unstable due to check_tsc_sync_source failed Jun 13 07:08:54 localhost kernel: acpi PNP0A03:00: ACPI _OSC support notification failed, disabling PCIe ASPM Jun 13 07:08:54 localhost systemd[1]: Unit plymouth-start.service entered failed state. Jun 13 07:09:02 node1 systemd[1]: Unit plymouth-start.service entered failed state. Jun 13 07:09:02 node1 systemd[1]: Unit systemd-udev-settle.service entered failed state. Darren On 13 June 2014 07:15, Darren Thompson wrote: > Team > > I am seeing lots of basic services failing to start under SLES12B8 > > The udev in particular seems to have nasty flow-on effects (seems to stop > multipath working, which stops clustering)... > > here is an extract from the startup/journalctl > > node1:~ # journalctl | grep failed > Jun 13 07:08:54 localhost kernel: tsc: Fast TSC calibration failed > Jun 13 07:08:54 localhost kernel: tsc: Marking TSC unstable due to > check_tsc_sync_source failed > Jun 13 07:08:54 localhost kernel: acpi PNP0A03:00: ACPI _OSC support > notification failed, disabling PCIe ASPM > Jun 13 07:08:54 localhost systemd[1]: Unit plymouth-start.service entered > failed state. > Jun 13 07:09:02 node1 systemd[1]: Unit plymouth-start.service entered > failed state. > > These were "in-place upgraded" from SLES12B7 so tis could be a unique > error due to not being clean installed (hence no automatic SR). > > I'm planning on rebuilding my cluster clean on SLES12B8 over weekend > (nothing better to do with my free time;-) > > Is anyone else seeing these errors (if yes then I'll raise the SR's now) > if not then let me know... > > Darren > > -- > > Darren Thompson > > Professional Services Engineer / Consultant > > *[image: cid:image001.jpg at 01CB7C0C.6C6A2AE0]* > > Level 3, 60 City Road > > Southgate, VIC 3006 > > Mb: 0400 640 414 > > Mail: darrent at akurit.com.au > Web: www.akurit.com.au > -- Darren Thompson Professional Services Engineer / Consultant *[image: cid:image001.jpg at 01CB7C0C.6C6A2AE0]* Level 3, 60 City Road Southgate, VIC 3006 Mb: 0400 640 414 Mail: darrent at akurit.com.au Web: www.akurit.com.au -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 3692 bytes Desc: not available URL: From johnawon at cisco.com Thu Jun 12 16:35:55 2014 From: johnawon at cisco.com (Johnathan Wong (johnawon)) Date: Thu, 12 Jun 2014 22:35:55 +0000 Subject: [sles-beta] Lots of basic service failing to start with SLES12B8 In-Reply-To: References: Message-ID: Yes. I am seeing similar errors and udev intermittently hangs my KVM(keyboard, video and mouse) console. -john From: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] On Behalf Of Darren Thompson Sent: Thursday, June 12, 2014 2:18 PM To: SUSE Linux Enterprise High Availability Authorized Beta Program; sles-beta at lists.suse.com Subject: Re: [sles-beta] Lots of basic service failing to start with SLES12B8 oops Actually left out the most important bit of log, where udev failes... node1:~ # journalctl | grep failed Jun 13 07:08:54 localhost kernel: tsc: Fast TSC calibration failed Jun 13 07:08:54 localhost kernel: tsc: Marking TSC unstable due to check_tsc_sync_source failed Jun 13 07:08:54 localhost kernel: acpi PNP0A03:00: ACPI _OSC support notification failed, disabling PCIe ASPM Jun 13 07:08:54 localhost systemd[1]: Unit plymouth-start.service entered failed state. Jun 13 07:09:02 node1 systemd[1]: Unit plymouth-start.service entered failed state. Jun 13 07:09:02 node1 systemd[1]: Unit systemd-udev-settle.service entered failed state. Darren On 13 June 2014 07:15, Darren Thompson > wrote: Team I am seeing lots of basic services failing to start under SLES12B8 The udev in particular seems to have nasty flow-on effects (seems to stop multipath working, which stops clustering)... here is an extract from the startup/journalctl node1:~ # journalctl | grep failed Jun 13 07:08:54 localhost kernel: tsc: Fast TSC calibration failed Jun 13 07:08:54 localhost kernel: tsc: Marking TSC unstable due to check_tsc_sync_source failed Jun 13 07:08:54 localhost kernel: acpi PNP0A03:00: ACPI _OSC support notification failed, disabling PCIe ASPM Jun 13 07:08:54 localhost systemd[1]: Unit plymouth-start.service entered failed state. Jun 13 07:09:02 node1 systemd[1]: Unit plymouth-start.service entered failed state. These were "in-place upgraded" from SLES12B7 so tis could be a unique error due to not being clean installed (hence no automatic SR). I'm planning on rebuilding my cluster clean on SLES12B8 over weekend (nothing better to do with my free time;-) Is anyone else seeing these errors (if yes then I'll raise the SR's now) if not then let me know... Darren -- Darren Thompson Professional Services Engineer / Consultant [cid:image001.jpg at 01CB7C0C.6C6A2AE0] Level 3, 60 City Road Southgate, VIC 3006 Mb: 0400 640 414 Mail: darrent at akurit.com.au Web: www.akurit.com.au -- Darren Thompson Professional Services Engineer / Consultant [cid:image001.jpg at 01CB7C0C.6C6A2AE0] Level 3, 60 City Road Southgate, VIC 3006 Mb: 0400 640 414 Mail: darrent at akurit.com.au Web: www.akurit.com.au -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3692 bytes Desc: image001.jpg URL: From urs.frey at post.ch Fri Jun 13 01:03:10 2014 From: urs.frey at post.ch (urs.frey at post.ch) Date: Fri, 13 Jun 2014 07:03:10 +0000 Subject: [sles-beta] Lots of basic service failing to start with SLES12B8 In-Reply-To: References: Message-ID: <40637DBB36AF3941B243A286A432CA0B0F9A1EDF@HXMB12.pnet.ch> Hi Darren Yes the same here h063ur:~ # journalctl | grep failed Jun 10 11:18:56 localhost kernel: acpi PNP0A08:00: ACPI _OSC support notification failed, disabling PCIe ASPM Jun 10 11:19:08 h063ur systemd[1]: Unit plymouth-start.service entered failed state. Jun 10 11:19:10 h063ur systemd[1]: Unit plymouth-start.service entered failed state. Jun 10 11:19:19 h063ur systemd[1]: Unit kdump.service entered failed state. Jun 10 11:19:19 h063ur boot.kdump[1775]: ..failed 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 Von: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] Im Auftrag von Darren Thompson Gesendet: Thursday, June 12, 2014 11:18 PM An: SUSE Linux Enterprise High Availability Authorized Beta Program; sles-beta at lists.suse.com Betreff: Re: [sles-beta] Lots of basic service failing to start with SLES12B8 oops Actually left out the most important bit of log, where udev failes... node1:~ # journalctl | grep failed Jun 13 07:08:54 localhost kernel: tsc: Fast TSC calibration failed Jun 13 07:08:54 localhost kernel: tsc: Marking TSC unstable due to check_tsc_sync_source failed Jun 13 07:08:54 localhost kernel: acpi PNP0A03:00: ACPI _OSC support notification failed, disabling PCIe ASPM Jun 13 07:08:54 localhost systemd[1]: Unit plymouth-start.service entered failed state. Jun 13 07:09:02 node1 systemd[1]: Unit plymouth-start.service entered failed state. Jun 13 07:09:02 node1 systemd[1]: Unit systemd-udev-settle.service entered failed state. Darren On 13 June 2014 07:15, Darren Thompson > wrote: Team I am seeing lots of basic services failing to start under SLES12B8 The udev in particular seems to have nasty flow-on effects (seems to stop multipath working, which stops clustering)... here is an extract from the startup/journalctl node1:~ # journalctl | grep failed Jun 13 07:08:54 localhost kernel: tsc: Fast TSC calibration failed Jun 13 07:08:54 localhost kernel: tsc: Marking TSC unstable due to check_tsc_sync_source failed Jun 13 07:08:54 localhost kernel: acpi PNP0A03:00: ACPI _OSC support notification failed, disabling PCIe ASPM Jun 13 07:08:54 localhost systemd[1]: Unit plymouth-start.service entered failed state. Jun 13 07:09:02 node1 systemd[1]: Unit plymouth-start.service entered failed state. These were "in-place upgraded" from SLES12B7 so tis could be a unique error due to not being clean installed (hence no automatic SR). I'm planning on rebuilding my cluster clean on SLES12B8 over weekend (nothing better to do with my free time;-) Is anyone else seeing these errors (if yes then I'll raise the SR's now) if not then let me know... Darren -- Darren Thompson Professional Services Engineer / Consultant [cid:image001.jpg at 01CB7C0C.6C6A2AE0] Level 3, 60 City Road Southgate, VIC 3006 Mb: 0400 640 414 Mail: darrent at akurit.com.au Web: www.akurit.com.au -- Darren Thompson Professional Services Engineer / Consultant [cid:image001.jpg at 01CB7C0C.6C6A2AE0] Level 3, 60 City Road Southgate, VIC 3006 Mb: 0400 640 414 Mail: darrent at akurit.com.au Web: www.akurit.com.au -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 3692 bytes Desc: image001.jpg URL: From fcrozat at suse.com Fri Jun 13 01:36:34 2014 From: fcrozat at suse.com (Frederic Crozat) Date: Fri, 13 Jun 2014 09:36:34 +0200 Subject: [sles-beta] Lots of basic service failing to start with SLES12B8 In-Reply-To: References: Message-ID: <1402644994.4212.35.camel@par-r81vxc7.par.novell.com> Le vendredi 13 juin 2014 ? 07:17 +1000, Darren Thompson a ?crit : > oops > > > Actually left out the most important bit of log, where udev failes... > > > node1:~ # journalctl | grep failed > Jun 13 07:08:54 localhost systemd[1]: Unit plymouth-start.service > entered failed state. > Jun 13 07:09:02 node1 systemd[1]: Unit plymouth-start.service entered > failed state. This is is partially fixed and we are working on a full fix. -- Frederic Crozat Project Manager Enterprise Desktop SUSE From jsrain at suse.cz Fri Jun 13 05:15:03 2014 From: jsrain at suse.cz (Jiri Srain) Date: Fri, 13 Jun 2014 13:15:03 +0200 Subject: [sles-beta] ANNOUNCE: SMT for SLE12 is available for testing Message-ID: <539ADD37.3090300@suse.cz> Dear SLE12 beta testers, the on-line update for SMT11-SP3, which brings in support for SUSE Customer Center and SUSE Linux Enterprise 12 products, is now available for testing. The updated version can be installed on top of SLES11-SP3 to fit into your existing environments as smoothly as possible. The updated packages as well as a README-SCC file, which provides instructions to operate SMT against SCC, can be downloaded from http://beta.suse.com/private/SMT-Beta/ WARNING: Don't try this on your production SMT! If you want to ensure that you can roll back to your previous supported SMT setup, make a full back-up before you apply the beta code. In order to share your feedback or discuss the update of SMT, please, visit http://lists.suse.com/mailman/listinfo/smt-beta in order to subscribe to the mailing list smt-beta at lists.suse.com Happy testing and thanks for your feedback! The SUSE SMT team. -- Regards, Jiri Srain Project Manager --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain at suse.com Lihovarska 1060/12 tel: +420 284 084 659 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.com From darrent at akurit.com.au Fri Jun 13 18:24:05 2014 From: darrent at akurit.com.au (Darren Thompson) Date: Sat, 14 Jun 2014 10:24:05 +1000 Subject: [sles-beta] YaST2 from SSH failing again with SLES12B8 In-Reply-To: References: Message-ID: Greg Normally I use:" ssh -X root@{hostname or ip address} Once I'm logged in I "normally" can run any x-enabled application and the screen is forwarded to the x-server running on my desktop (linux) I can achieve the same on Windows with PuTTY by checking the x-forwarding option and running a "x-server" (I use x-ming). I did some more testing and when I'm getting this error (oddly not every time I connect) I cannot run xterm either so i suspect the issue is in the underlying xterm that YaST2 is trying to invoke. Darren On 14 June 2014 09:24, Gregory D. Rosenberg wrote: > Darren, > > Do you have to enable any type of forwarding to make this work? > > On Jun 10, 2014, at 23:27 CDT, Darren Thompson > wrote: > > Team > > I cannot get YaST2 to run any of it's modules when run through SSH (with > X-forwarding enabled)... Again... > > YaST2 itself starts without error, but when a module is selected I get a > "bouncing thing" which stops after a few minutes and no further activity. > > The "ssh shell" gets this echoed when this issue is occurring: > "linux-7z01:~ # > ** (y2controlcenter-gnome:5138): WARNING **: Couldn't connect to > accessibility bus: Failed to connect to socket /tmp/dbus-21DTG0iwLz: > Connection refused > /usr/bin/xdg-su: line 503: 5163 Segmentation fault xterm -geom 60x5 > -T "xdg-su: $cmd" -e su -c "$cmd" > " > > This is the second time I have seen this behaviour (it also happened in > B6, seemed to be resolved in B7 and is now back in B8) > > -- > > Darren Thompson > > Professional Services Engineer / Consultant > > ** > > Level 3, 60 City Road > > Southgate, VIC 3006 > > Mb: 0400 640 414 > > Mail: darrent at akurit.com.au > Web: www.akurit.com.au > > _______________________________________________ > sles-beta mailing list > sles-beta at lists.suse.com > > http://cp.mcafee.com/d/FZsS92gQ91NJ5yWr3BTxPxKVJ6Wrz2bPMVUSztdNx4QsEIcCQrI6zBcQsL6zBwQsCQrFKfCzBdxBYShzV4y2EOJaDbCUOJaDbCO5Jg76zBB_HYYehopWZOWrbwXAm7XK9YJteOaaJT6ul3PWApmU6CQjq9J7HFkr8kJ6h3Pq9I06vaAWthKDYLwCHIcfBisEeROx_QbAfDFKx_QbAfDFsxlK5LE2zVkDjGdQ_BPqatSm3pFrEvZ2V3VWqnjh01Z60iCq87oRld40Mc1sQgeX8-k29EwQzIE6y0NapcQg30l6xx5cpudLI6VUQ5Gf3FWizw > > > > > 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) > > > > -- Darren Thompson Professional Services Engineer / Consultant *[image: cid:image001.jpg at 01CB7C0C.6C6A2AE0]* Level 3, 60 City Road Southgate, VIC 3006 Mb: 0400 640 414 Mail: darrent at akurit.com.au Web: www.akurit.com.au -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 3692 bytes Desc: not available URL: From darrent at akurit.com.au Fri Jun 13 18:29:40 2014 From: darrent at akurit.com.au (Darren Thompson) Date: Sat, 14 Jun 2014 10:29:40 +1000 Subject: [sles-beta] SLES12B8 - Boot process is "fragile" Message-ID: Team I'm getting a lot of "failures to boot" with SLES12B8. It's worse if I try to boot as a XEN hypervisor. It's not every time and there is a simple "work around" to get the boot to complete (refer attached screenshot). I suspect that there is some delay/time-out issue involved (there is a device-mapper error abu the time everything seems to fail). This is a regression that seems to have only happen in B8 -- Darren Thompson Professional Services Engineer / Consultant *[image: cid:image001.jpg at 01CB7C0C.6C6A2AE0]* Level 3, 60 City Road Southgate, VIC 3006 Mb: 0400 640 414 Mail: darrent at akurit.com.au Web: www.akurit.com.au -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 3692 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: fragile_boot.png Type: image/png Size: 18409 bytes Desc: not available URL: From ohering at suse.de Fri Jun 13 23:49:59 2014 From: ohering at suse.de (Olaf Hering) Date: Sat, 14 Jun 2014 07:49:59 +0200 Subject: [sles-beta] SLES12B8 - Boot process is "fragile" In-Reply-To: References: Message-ID: <539BE287.6000300@suse.de> Am 14.06.2014 02:29, schrieb Darren Thompson: > This is a regression that seems to have only happen in B8 The following bug tracks this issue, happens also with kernel-default: https://bugzilla.novell.com/show_bug.cgi?id=881125 Olaf From darrent at akurit.com.au Sun Jun 15 01:46:49 2014 From: darrent at akurit.com.au (Darren Thompson) Date: Sun, 15 Jun 2014 17:46:49 +1000 Subject: [sles-beta] Install modules as an "add-on" media disk Message-ID: Team I added the "modules" disks to my install_source server. Once that was done I could add them as a "add-on" via YAST which set them up as a repo for installation Worked PERFECTLY in that it made the modules content available for installation if required (e.g. sendmail, IBM-Java, PHP5 etc) without installing anything unnecessarily It means I can install everything I need without being forced to use the internet etc and I can defer registration/updates until I am happy with the build. If the registration process results in these being kept up to date then this is Win/Win. If they were to be shipped like this *I* would be happy. Regards Darren -- Darren Thompson Professional Services Engineer / Consultant *[image: cid:image001.jpg at 01CB7C0C.6C6A2AE0]* Level 3, 60 City Road Southgate, VIC 3006 Mb: 0400 640 414 Mail: darrent at akurit.com.au Web: www.akurit.com.au -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 3692 bytes Desc: not available URL: From darrent at akurit.com.au Sun Jun 15 21:08:34 2014 From: darrent at akurit.com.au (Darren Thompson) Date: Mon, 16 Jun 2014 13:08:34 +1000 Subject: [sles-beta] Help, getting an autoyast build for "multi-user" target Message-ID: Team Does anyone have an example autoyast file they can share which reliably builds a server to the "multi-user" target (e.g. no X/display server running). Simmilarly, what are the steps for go from a server built to the "graphical" target and getting it to reliably boot to the "multi-user" target. The "service-manager" Yast module seems to be able to adjust the "target" level but I cannot seem to workout how to get it to accept "multi-user" - Am I missing something or is that yast module "broken"? Any/all help appreciated. background: I have traditionally built my SLES servers with the full graphical install. I would then go into 'yast2 run-level' module and in 'expert mode' change the default to "run level 3". This would allow me to run the servers themselves without any graphical display, but I could still SSH into them and run all the graphical tools (via x-forwarding). I'm hoping to be able to achve the same result with SLES12 Regards Darren -- Darren Thompson Professional Services Engineer / Consultant *[image: cid:image001.jpg at 01CB7C0C.6C6A2AE0]* Level 3, 60 City Road Southgate, VIC 3006 Mb: 0400 640 414 Mail: darrent at akurit.com.au Web: www.akurit.com.au -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 3692 bytes Desc: not available URL: