From behlert at suse.com Tue Jun 2 05:36:57 2015 From: behlert at suse.com (Stefan Behlert) Date: Tue, 2 Jun 2015 13:36:57 +0200 Subject: [sles-beta] General information regarding the SP4 update channels Message-ID: <20150602113657.GS6710@suse.de> Hi all, as we are getting closer to the next milestone, I'd like to give you a short update on where we are currently. Since RC2 release, we have fixed several nasty bugs, and released some of the fixes in the SP4 update channels. Everything you find in these update channels will be on the next media, but for testing purposes we have releaqsed it until then in the channels. If you encounter a bug with one of these pacakges that was not present before let us know. We don't expect one, but... ;) When we release GMC we will empty the update channels, and start filling it again after GM with the "real" updates for the final media. But, as mentioned, until ten we will use it to release some updates early. Not all, but those packages which we regard as either helpful to be released early, or critical enough to get them to you faster than a media. There are more bugs fixed (and going to be fixed) of course than we release updates, but we cannot release them all. Thanks for all your testing! ciao, Stefan -- Stefan Behlert, SUSE LINUX Release Manager Enterprise Server Maxfeldstr. 5, D-90409 Nuernberg, Germany Phone +49-911-74053-173 SUSE LINUX GmbH, Nuernberg; GF: Felix Imendoerffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nuernberg) From Joel.Barbieri at merge.com Wed Jun 3 14:06:38 2015 From: Joel.Barbieri at merge.com (Joel Barbieri) Date: Wed, 3 Jun 2015 20:06:38 +0000 Subject: [sles-beta] SLES11SP4RC2 x86_64 autoyast installation - problem with reinstall Message-ID: <1E287A5DDB506E478DE9CAE3C8492D01F94F22A5@BRDC-MBX-1.network.internal> Finally got a chance to work with SLES11SP4. Cut our shrunken distro. Mostly I see problems with re-installations. The autoyast profile is set to "blow-up" the server each time, but stops with some sort of problem dealing with the partitions on a "second" install. Hardware is Intel NUC Core i3 in UEFI mode with installation over the wire. Problem is consistent. Will try on a Dell r610 in UEFI tomorrow to see if the problem follows the hardware or software. I have had similar grief in SLES11SP3 when switching a system from UEFI to BIOS mode where I have to nuke the drive manually to execute a re-install from scratch, but never when re-installing without switching BIOS modes. To nuke a drive, I just escape to an available shell [alt-f2, or whichever is available], dd if=/dev/zero of=/dev/sda bs=1M count=1;reboot -f. Don't forget the "-f" on the reboot. This is the only way I have succeeded on Dell r610 at switching from UEFI back to BIOS mode. Without it, I estimate the kernel or RAID card or some other driver re-writes the UEFI/GPT partition table back to disk, thus not effectively "cleaning" it. I wouldn't call this a show stopper, but it is a major nuisance for product testing for me. It wouldn't be so bad except for Server Manufacturers have made the BIOS/UEFI initialization so long that it physically hurts. UEFI was supposed to be faster, but apparently not on servers. Does great on laptops and many modern desktops. I gathered the /var/log/YaST directory in case SuSE would like to look at why it bombed. I may deconstruct also if I have time. Let me know if this is SR worthy by description. I don't remember of SLES12 was more amenable to always succeeding in second installs. I may have just kept them all in UEFI. I know on the r610s it re-installed repeatedly just fine. -Joel Joel Barbieri Merge Healthcare ________________________________________ From: sles-beta-bounces at lists.suse.com [sles-beta-bounces at lists.suse.com] on behalf of urs.frey at post.ch [urs.frey at post.ch] Sent: Tuesday, May 26, 2015 7:17 AM To: sles-beta at lists.suse.com Subject: [sles-beta] SLES11SP4RC2 x86_64 autoyast installation & online upgrade OK Hi Just installed a HP Proliant BL460cGen8 and a HP Proliant BL460cG7 with SLES11-SP4 x86_64 using autoyast Installation works OK. Profiles working under SLES11-SP3 are working the same under SLES11-SP4 Upgrades using zypper dist upgrade from SLES11-SP3 kernel version 3.0.101-0.47.52-default do work OK. Thank you very much SUSE for this stable work 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 From fcrozat at suse.com Thu Jun 4 01:38:44 2015 From: fcrozat at suse.com (Frederic Crozat) Date: Thu, 04 Jun 2015 09:38:44 +0200 Subject: [sles-beta] SLES11SP4RC2 x86_64 autoyast installation - problem with reinstall In-Reply-To: <1E287A5DDB506E478DE9CAE3C8492D01F94F22A5@BRDC-MBX-1.network.internal> References: <1E287A5DDB506E478DE9CAE3C8492D01F94F22A5@BRDC-MBX-1.network.internal> Message-ID: <1433403524.3924.78.camel@par-r81vxc7.par.novell.com> Le mercredi 03 juin 2015 ? 20:06 +0000, Joel Barbieri a ?crit : > Finally got a chance to work with SLES11SP4. Cut our shrunken distro. > > Mostly I see problems with re-installations. The autoyast profile is set to "blow-up" the server each time, but stops with some sort of problem dealing with the partitions on a "second" install. > > Hardware is Intel NUC Core i3 in UEFI mode with installation over the wire. Problem is consistent. Will try on a Dell r610 in UEFI tomorrow to see if the problem follows the hardware or software. I have had similar grief in SLES11SP3 when switching a system from UEFI to BIOS mode where I have to nuke the drive manually to execute a re-install from scratch, but never when re-installing without switching BIOS modes. > > To nuke a drive, I just escape to an available shell [alt-f2, or whichever is available], dd if=/dev/zero of=/dev/sda bs=1M count=1;reboot -f. Don't forget the "-f" on the reboot. This is the only way I have succeeded on Dell r610 at switching from UEFI back to BIOS mode. Without it, I estimate the kernel or RAID card or some other driver re-writes the UEFI/GPT partition table back to disk, thus not effectively "cleaning" it. > > I wouldn't call this a show stopper, but it is a major nuisance for product testing for me. It wouldn't be so bad except for Server Manufacturers have made the BIOS/UEFI initialization so long that it physically hurts. UEFI was supposed to be faster, but apparently not on servers. Does great on laptops and many modern desktops. > > I gathered the /var/log/YaST directory in case SuSE would like to look at why it bombed. I may deconstruct also if I have time. > > Let me know if this is SR worthy by description. Please open a SR, so that installer people can have a look. -- Frederic Crozat Enterprise Desktop Release Manager SUSE