From filipe.lacerda at lusolabs.com  Tue Jun 23 01:29:08 2015
From: filipe.lacerda at lusolabs.com (Filipe Lacerda)
Date: Tue, 23 Jun 2015 08:29:08 +0100
Subject: [sles-beta] [ANNOUNCE] SLES 11 SP4 GMC is available
In-Reply-To: <20150623062312.GF23790@suse.de>
References: <20150623062312.GF23790@suse.de>
Message-ID: <0D797D42-C329-44B0-920C-6C84614F3CCA@lusolabs.com>

Ahhhh

Good!

Thanks Stefan,

Filipe Lacerda

On June 23, 2015 7:23:12 AM WEST, Stefan Behlert <behlert at suse.com> wrote:
>!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>!!  SUSE CONFIDENTIAL  !!  SUSE CONFIDENTIAL  !!  SUSE CONFIDENTIAL  !!
>!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>
>
>Dear Beta participants,
>
>we are proud to announce the release of
>
>	SUSE Linux Enterprise Server 11 SP4 GMC.
>	       (Goldmaster Candidate)
>
>ISO images are now available for download now. Please go to
>http://www.novell.com/beta and select "View my beta page".
>Here you should see all Beta's you are part of.
>
>Note that the directory contains the images for the SDK as well as for
>the SLED
>Extension.
>
>We offer 3 DVD ISOs: DVD1 contains the binaries, the second
>DVD the sources and the third DVD the debuginfo packages. 
>The final product will not contain the debuginfo packages on the media.
>
>For installation purposes you just need Media 1 for your architecture.
>
>Please verify the sha256sum of the ISO using the SHA256SUMS file, which
>can
>be found in the same directory on the download servers.
>
>Thanks for all your testing,
>
>	Your SUSE Linux Enterprise Team
>-- 
>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)
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>sles-beta mailing list
>sles-beta at lists.suse.com
>http://lists.suse.com/mailman/listinfo/sles-beta

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.suse.com/mailman/private/sles-beta/attachments/20150623/655524a5/attachment.htm>

From Dick.Waite at softwareag.com  Tue Jun 23 04:49:41 2015
From: Dick.Waite at softwareag.com (Waite, Dick (External))
Date: Tue, 23 Jun 2015 10:49:41 +0000
Subject: [sles-beta] SLES 11 SP4 GMC - 3.0.101-62
Message-ID: <46AC8C81C10B8C48820201DF2AE1D76DCD4AC7E7@hqmbx6.eur.ad.sag>

Grand Wet Tuesday, June 23, 2015

I used the GMC .iso to update a x86_64 environment and noted I have a 3.0.101-62 level. But I also see there are patches in the wings waiting to be installed, which would give me a 3.0.101-64 level.

Just checking that after applying the GMC level we should then update to 101-64 ?

__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), Eric Duffaut, Dr. Wolfram Jost, Arnd Zinnhardt; - Aufsichtsratsvorsitzender/Chairman of the Supervisory Board: Dr. Andreas Bereczky - http://www.softwareag.com


From Klaus.Gmeinwieser at oce.com  Tue Jun 23 05:08:55 2015
From: Klaus.Gmeinwieser at oce.com (Klaus Gmeinwieser)
Date: Tue, 23 Jun 2015 13:08:55 +0200
Subject: [sles-beta] SLES 11 SP4 GMC - 3.0.101-62
In-Reply-To: <46AC8C81C10B8C48820201DF2AE1D76DCD4AC7E7@hqmbx6.eur.ad.sag>
References: <46AC8C81C10B8C48820201DF2AE1D76DCD4AC7E7@hqmbx6.eur.ad.sag>
Message-ID: <55893E47.6020104@oce.com>

Hello SUSE Team,

thx for releasing GMC :)!

I installed on 2 machines and got the following problem on both systems:

While accessing the filesystem, tons of messages are sent to the
Terminal on console 10 stating the following error

scsi_init_sgtable: sg tablesize mismatch, 128 should be 9

The only difference is, that the numbers differ.

After the system is booted, the logging stops....

I assume this to be important, so I did not analyse but report it
quickly....

Please advise

Thx a lot & Br
Klaus

Am 23.06.2015 um 12:49 schrieb Waite, Dick (External):
> Grand Wet Tuesday, June 23, 2015
>
> I used the GMC .iso to update a x86_64 environment and noted I have a 3.0.101-62 level. But I also see there are patches in the wings waiting to be installed, which would give me a 3.0.101-64 level.
>
> Just checking that after applying the GMC level we should then update to 101-64 ?
>
> __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), Eric Duffaut, Dr. Wolfram Jost, Arnd Zinnhardt; - Aufsichtsratsvorsitzender/Chairman of the Supervisory Board: Dr. Andreas Bereczky - http://www.softwareag.com
>
> _______________________________________________
> sles-beta mailing list
> sles-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sles-beta
>

--
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 behlert at suse.com  Tue Jun 23 06:12:09 2015
From: behlert at suse.com (Stefan Behlert)
Date: Tue, 23 Jun 2015 14:12:09 +0200
Subject: [sles-beta] SLES 11 SP4 GMC - 3.0.101-62
In-Reply-To: <55893E47.6020104@oce.com>
References: <46AC8C81C10B8C48820201DF2AE1D76DCD4AC7E7@hqmbx6.eur.ad.sag>
	<55893E47.6020104@oce.com>
Message-ID: <20150623121209.GQ23790@suse.de>

Moin,

On Jun 23, 15 13:08:55 +0200, Klaus Gmeinwieser wrote:
> Hello SUSE Team,
>
> thx for releasing GMC :)!
>
> I installed on 2 machines and got the following problem on both systems:
>
> While accessing the filesystem, tons of messages are sent to the
> Terminal on console 10 stating the following error
>
> scsi_init_sgtable: sg tablesize mismatch, 128 should be 9

Yes, this is bug 935120.

I suspect that we will have a GMC2, but we are still collecting if more
things are found. We would like to avoid having a fast GMC2 followed by
another GMC3. 
Besides the fact that it fills up your harddrive and has some performace
impact it should not have other negative impacts.
It's just "too much debug output", which is bad enough :(

        Stefan

>
> The only difference is, that the numbers differ.
>
> After the system is booted, the logging stops....
>
> I assume this to be important, so I did not analyse but report it
> quickly....
>
> Please advise
>
> Thx a lot & Br
> Klaus
>
> Am 23.06.2015 um 12:49 schrieb Waite, Dick (External):
>> Grand Wet Tuesday, June 23, 2015
>>
>> I used the GMC .iso to update a x86_64 environment and noted I have a 3.0.101-62 level. But I also see there are patches in the wings waiting to be installed, which would give me a 3.0.101-64 level.
>>
>> Just checking that after applying the GMC level we should then update to 101-64 ?
>>
>> __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), Eric Duffaut, Dr. Wolfram Jost, Arnd Zinnhardt; - Aufsichtsratsvorsitzender/Chairman of the Supervisory Board: Dr. Andreas Bereczky - http://www.softwareag.com
>>
>> _______________________________________________
>> sles-beta mailing list
>> sles-beta at lists.suse.com
>> http://lists.suse.com/mailman/listinfo/sles-beta
>>
>
> --
> 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.
> _______________________________________________
> sles-beta mailing list
> sles-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sles-beta

-- 
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 behlert at suse.com  Tue Jun 23 06:27:32 2015
From: behlert at suse.com (Stefan Behlert)
Date: Tue, 23 Jun 2015 14:27:32 +0200
Subject: [sles-beta] SLES 11 SP4 GMC - 3.0.101-62
In-Reply-To: <46AC8C81C10B8C48820201DF2AE1D76DCD4AC7E7@hqmbx6.eur.ad.sag>
References: <46AC8C81C10B8C48820201DF2AE1D76DCD4AC7E7@hqmbx6.eur.ad.sag>
Message-ID: <20150623122732.GR23790@suse.de>

Moin,


On Jun 23, 15 10:49:41 +0000, Waite, Dick (External) wrote:
> Grand Wet Tuesday, June 23, 2015
> 
> I used the GMC .iso to update a x86_64 environment and noted I have a 3.0.101-62 level. But I also see there are patches in the wings waiting to be installed, which would give me a 3.0.101-64 level.
> 
> Just checking that after applying the GMC level we should then update to 101-64 ?

No. 101-64 is a left over in the update channel from RC2, it's an older
kernel than 101-62. The build number to make sure that the kernel got updated
after RC2 was too high for GMC. Looks like someone expected more internal
kernel uilds than we did.
The update channel will be cleaned today, then it should no longer be visible.

We are sorry for the inconveniences.

        Stefan
> 
> __R
> 
-- 
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 Dick.Waite at softwareag.com  Tue Jun 23 07:14:22 2015
From: Dick.Waite at softwareag.com (Waite, Dick (External))
Date: Tue, 23 Jun 2015 13:14:22 +0000
Subject: [sles-beta] SLES 11 SP4 GMC - 3.0.101-62
In-Reply-To: <20150623122732.GR23790@suse.de>
References: <46AC8C81C10B8C48820201DF2AE1D76DCD4AC7E7@hqmbx6.eur.ad.sag>,
	<20150623122732.GR23790@suse.de>
Message-ID: <46AC8C81C10B8C48820201DF2AE1D76DCD4AC946@hqmbx6.eur.ad.sag>

Many Thanks for the update. I have only done the one machine so I'll hold on the others until the morning (Wednesday). As a FYI to any other Workstation user, tools 9.9.3 is looking good on both SLES 12, SLES 11 and Windows 10 build 10-130... ;o)
__R
________________________________________
From: sles-beta-bounces at lists.suse.com [sles-beta-bounces at lists.suse.com] on behalf of Stefan Behlert [behlert at suse.com]
Sent: 23 June 2015 14:27
To: sles-beta at lists.suse.com
Subject: Re: [sles-beta] SLES 11 SP4 GMC - 3.0.101-62

Moin,


On Jun 23, 15 10:49:41 +0000, Waite, Dick (External) wrote:
> Grand Wet Tuesday, June 23, 2015
>
> I used the GMC .iso to update a x86_64 environment and noted I have a 3.0.101-62 level. But I also see there are patches in the wings waiting to be installed, which would give me a 3.0.101-64 level.
>
> Just checking that after applying the GMC level we should then update to 101-64 ?

No. 101-64 is a left over in the update channel from RC2, it's an older
kernel than 101-62. The build number to make sure that the kernel got updated
after RC2 was too high for GMC. Looks like someone expected more internal
kernel uilds than we did.
The update channel will be cleaned today, then it should no longer be visible.

We are sorry for the inconveniences.

        Stefan
>
> __R
>
--
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)
_______________________________________________
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), Eric Duffaut, Dr. Wolfram Jost, Arnd Zinnhardt; - Aufsichtsratsvorsitzender/Chairman of the Supervisory Board: Dr. Andreas Bereczky - http://www.softwareag.com


From fcrozat at suse.com  Tue Jun 23 09:55:09 2015
From: fcrozat at suse.com (Frederic Crozat)
Date: Tue, 23 Jun 2015 17:55:09 +0200
Subject: [sles-beta] SLES11-Sp4 GMC succesfully installed,
 many smartd messages
In-Reply-To: <40637DBB36AF3941B243A286A432CA0B1AF18D7D@HXMB12.pnet.ch>
References: <40637DBB36AF3941B243A286A432CA0B1AF18D7D@HXMB12.pnet.ch>
Message-ID: <1435074909.32381.38.camel@par-r81vxc7.par.novell.com>

Le mardi 23 juin 2015 ? 15:39 +0000, urs.frey at post.ch a ?crit :
> Hi
> Thank you very much for SLES11-SP4 x86_64 GMC
>  
> Just installed successfully SLES11-SP4 x86_64 on my test server HP
> Proliant BL460c-Gen9 using autoyast, having bonded NICs configured.
> Works without any problem
>  
> Online Update from SLES11-SP3 x86_64, kernel 3.0.101-0.47.52-default
> on my second test server HP Proliant BL465cG7 connected to SAN EMC
> works also without any problem.
>  
> From what I could see is, that obviously smartd is enabled and does
> scan my SAN LUNs which is really not a good idea
>  
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdaz, is SMART
> capable. Adding to "monitor" list.
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdaz, state read
> from /var/lib/smartmontools/smartd.EMC-SYMMETRIX-6025435AF000.scsi.state
> Jun 23 17:30:29 h04wwl smartd[30169]: Monitoring 0 ATA and 52 SCSI
> devices
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sda, failed to read
> Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdb, failed to read
> Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdc, failed to read
> Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdd, failed to read
> Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sde, failed to read
> Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdf, failed to read
> Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdg, failed to read
> Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdh, failed to read
> Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdi, failed to read
> Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdj, failed to read
> Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdk, failed to read
> Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdl, failed to read
> Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdm, failed to read
> Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdn, failed to read
> Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdo, failed to read
> Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdp, failed to read
> Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdq, failed to read
> Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdr, failed to read
> Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sds, failed to read
> Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdt, failed to read
> Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdu, failed to read
> Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdv, failed to read
> Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdw, failed to read
> Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdx, failed to read
> Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdy, failed to read
> Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdz, failed to read
> Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdaa, failed to
> read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdab, failed to
> read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdac, failed to
> read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdad, failed to
> read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdae, failed to
> read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdaf, failed to
> read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdag, failed to
> read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdah, failed to
> read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdai, failed to
> read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdaj, failed to
> read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdak, failed to
> read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdal, failed to
> read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdam, failed to
> read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdan, failed to
> read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdao, failed to
> read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdap, failed to
> read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdaq, failed to
> read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdar, failed to
> read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdas, failed to
> read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdat, failed to
> read Temperature
> Jun 23 17:30:30 h04wwl smartd[30169]: Device: /dev/sdau, failed to
> read Temperature
> Jun 23 17:30:30 h04wwl smartd[30169]: Device: /dev/sdav, failed to
> read Temperature
> Jun 23 17:30:30 h04wwl smartd[30169]: Device: /dev/sdaw, failed to
> read Temperature
> Jun 23 17:30:30 h04wwl smartd[30169]: Device: /dev/sdax, failed to
> read Temperature
> Jun 23 17:30:30 h04wwl smartd[30169]: Device: /dev/sday, failed to
> read Temperature
> Jun 23 17:30:30 h04wwl smartd[30169]: Device: /dev/sdaz, failed to
> read Temperature
>  
> Obviously the service smartd is enabled by default in SLES11-SP4 GMC
> now.
>  
> Under SLES11-SP3 default was disabled
> h05bug:~ # facter operatingsystemrelease
> 11.3
> h05bug:~ # chkconfig -l smartd
> smartd                    0:off  1:off  2:off  3:off  4:off  5:off
> 6:off
> h05bug:~ #
>  
> Now under SLES11-SP4 smartd is enabled and causing many messages to be
> written to /var/log/messages, 1479 messages within 30min!
> h04wwl:/var/log # facter operatingsystemrelease
> 11.4
> h04wwl:/var/log # chkconfig -l smartd
> smartd                    0:off  1:off  2:on   3:on   4:off  5:on
> 6:off
> h04wwl:/var/log #
> h04wwl:/var/log # grep smartd /var/log/messages | wc -l
> 1479
> h04wwl:/var/log #
>  
> Why is smartd enabled by default?

I checked and the default haven't changed :

both SP3 and SP4 smartd initscript contains :
# Default-Start:              2 3 5
# X-UnitedLinux-Default-Enabled: yes

Which means smartd is expected to be enabled to runlevel 2 / 3 and 5 by
default in both SP3 and SP4.

> Why this change in a GMC?

There was no change in smartmontctl for 2 months (and the last relevant
changes was 3 months ago, with the version update of smartmontools from
6.0 to 6.3).

-- 
Frederic Crozat
Enterprise Desktop Release Manager
SUSE



From mge at suse.com  Tue Jun 23 16:28:49 2015
From: mge at suse.com (Matthias G. Eckermann)
Date: Wed, 24 Jun 2015 00:28:49 +0200
Subject: [sles-beta] uefi/autoyast - dell r610/r320 still fails
In-Reply-To: <1E287A5DDB506E478DE9CAE3C8492D0101013393F2@BRDC-MBX-1.network.internal>
References: <1E287A5DDB506E478DE9CAE3C8492D0101013393F2@BRDC-MBX-1.network.internal>
Message-ID: <20150623222849.GD3382@suse.com>

Hello Joel and all,

On 2015-06-23 T 18:58 +0000 Joel Barbieri wrote:

> I also have not tested FIPS related issues [openssh]
> but will look into that when I get an opportunity.
> Currently I have disabled it as part of the build
> testing I am doing.
 
with respect to FIPS 140-2, SLES 12 is definitely the
better choice, as we are undergoing a FIPS 140-2
validation for SLES 12 for 8 modules (counting OpenSSH
twice, client and server).

Nevertheless, FIPS mode should work in SLES 11 SP4 as
well, at least for OpenSSL and OpenSSH. If not, please
contact us.

So long -
	MgE

-- 
Matthias G. Eckermann - Senior Product Manager SUSE? Linux Enterprise
Phone: +49 30 44315731                     Mobile/DE: +49 179 2949448
SUSE Linux GmbH, GF: Felix Imend?rffer, Jane Smithard, Dilip Upmanyu,
Graham Norton, HRB 21284 (AG N?rnberg)


From behlert at suse.com  Wed Jun 24 03:55:24 2015
From: behlert at suse.com (Stefan Behlert)
Date: Wed, 24 Jun 2015 11:55:24 +0200
Subject: [sles-beta] SLES11-Sp4 GMC succesfully installed,
	many smartd	messages
In-Reply-To: <40637DBB36AF3941B243A286A432CA0B1AF18D7D@HXMB12.pnet.ch>
References: <40637DBB36AF3941B243A286A432CA0B1AF18D7D@HXMB12.pnet.ch>
Message-ID: <20150624095524.GY23790@suse.de>

Hi,

On Jun 23, 15 15:39:14 +0000, urs.frey at post.ch wrote:
> Hi
> Thank you very much for SLES11-SP4 x86_64 GMC
> 
> Just installed successfully SLES11-SP4 x86_64 on my test server HP Proliant BL460c-Gen9 using autoyast, having bonded NICs configured.
> Works without any problem
> 
> Online Update from SLES11-SP3 x86_64, kernel 3.0.101-0.47.52-default  on my second test server HP Proliant BL465cG7 connected to SAN EMC works also without any problem.
> 
> From what I could see is, that obviously smartd is enabled and does scan my SAN LUNs which is really not a good idea
> 
[...]
> Obviously the service smartd is enabled by default in SLES11-SP4 GMC now.
> 
> Under SLES11-SP3 default was disabled

I checked, as I was not sure if this had been changed by some maintenance
updates or other means, but SLES 11 SP3 GA had this enabled, too.

[...]
> 
> Why is smartd enabled by default?
> Why this change in a GMC?

A change like this would not be done for a GMC except if it is requested by
Security for security concerns. I suspect you had it disabled manually in
the past, could you verify?


        thanks,
          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 fcrozat at suse.com  Wed Jun 24 03:55:44 2015
From: fcrozat at suse.com (Frederic Crozat)
Date: Wed, 24 Jun 2015 11:55:44 +0200
Subject: [sles-beta] SLES11-Sp4 GMC succesfully installed,
 many smartd messages
In-Reply-To: <20150624095524.GY23790@suse.de>
References: <40637DBB36AF3941B243A286A432CA0B1AF18D7D@HXMB12.pnet.ch>
	<20150624095524.GY23790@suse.de>
Message-ID: <1435139744.32381.44.camel@par-r81vxc7.par.novell.com>

Le mercredi 24 juin 2015 ? 11:55 +0200, Stefan Behlert a ?crit :
> Hi,
> 
> On Jun 23, 15 15:39:14 +0000, urs.frey at post.ch wrote:
> > Hi
> > Thank you very much for SLES11-SP4 x86_64 GMC
> > 
> > Just installed successfully SLES11-SP4 x86_64 on my test server HP Proliant BL460c-Gen9 using autoyast, having bonded NICs configured.
> > Works without any problem
> > 
> > Online Update from SLES11-SP3 x86_64, kernel 3.0.101-0.47.52-default  on my second test server HP Proliant BL465cG7 connected to SAN EMC works also without any problem.
> > 
> > From what I could see is, that obviously smartd is enabled and does scan my SAN LUNs which is really not a good idea
> > 
> [...]
> > Obviously the service smartd is enabled by default in SLES11-SP4 GMC now.
> > 
> > Under SLES11-SP3 default was disabled
> 
> I checked, as I was not sure if this had been changed by some maintenance
> updates or other means, but SLES 11 SP3 GA had this enabled, too.
> 
> [...]
> > 
> > Why is smartd enabled by default?
> > Why this change in a GMC?
> 
> A change like this would not be done for a GMC except if it is requested by
> Security for security concerns. I suspect you had it disabled manually in
> the past, could you verify?

Just to update everybody, Urs already checked and he was indeed manually
disabling smartd in his SP3 install (he mailed me but forgot to include
the mailing list).

In short, no behavior change between SP3 and SP4.


-- 
Frederic Crozat
Enterprise Desktop Release Manager
SUSE



From urs.frey at post.ch  Wed Jun 24 04:00:15 2015
From: urs.frey at post.ch (urs.frey at post.ch)
Date: Wed, 24 Jun 2015 10:00:15 +0000
Subject: [sles-beta] SLES11-Sp4 GMC succesfully installed,
	many smartd	messages
In-Reply-To: <20150624095524.GY23790@suse.de>
References: <40637DBB36AF3941B243A286A432CA0B1AF18D7D@HXMB12.pnet.ch>
	<20150624095524.GY23790@suse.de>
Message-ID: <40637DBB36AF3941B243A286A432CA0B1AF18E89@HXMB12.pnet.ch>

Hi Stefan
Only hot air, sorry for that.

I disabled service smartd during autoyast installation locally here.
Smartd is not applicable for me, because on HP Servers local drives are monitored by HP-tools.
On VMware smartmontools are not applicable too, because we are on virtual drives.

The only thing I forgot about, is to disable after online update from SLES11SP3 to SLES11SP4, because with a package update, the daemon gets enabled again.
But that's a local story, so not to worry about.

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 Behlert
Gesendet: Wednesday, June 24, 2015 11:55 AM
An: sles-beta at lists.suse.com
Betreff: Re: [sles-beta] SLES11-Sp4 GMC succesfully installed, many smartd messages

Hi,

On Jun 23, 15 15:39:14 +0000, urs.frey at post.ch wrote:
> Hi
> Thank you very much for SLES11-SP4 x86_64 GMC
> 
> Just installed successfully SLES11-SP4 x86_64 on my test server HP Proliant BL460c-Gen9 using autoyast, having bonded NICs configured.
> Works without any problem
> 
> Online Update from SLES11-SP3 x86_64, kernel 3.0.101-0.47.52-default  on my second test server HP Proliant BL465cG7 connected to SAN EMC works also without any problem.
> 
> From what I could see is, that obviously smartd is enabled and does scan my SAN LUNs which is really not a good idea
> 
[...]
> Obviously the service smartd is enabled by default in SLES11-SP4 GMC now.
> 
> Under SLES11-SP3 default was disabled

I checked, as I was not sure if this had been changed by some maintenance
updates or other means, but SLES 11 SP3 GA had this enabled, too.

[...]
> 
> Why is smartd enabled by default?
> Why this change in a GMC?

A change like this would not be done for a GMC except if it is requested by
Security for security concerns. I suspect you had it disabled manually in
the past, could you verify?


        thanks,
          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)
_______________________________________________
sles-beta mailing list
sles-beta at lists.suse.com
http://lists.suse.com/mailman/listinfo/sles-beta

From behlert at suse.com  Wed Jun 24 06:02:26 2015
From: behlert at suse.com (Stefan Behlert)
Date: Wed, 24 Jun 2015 14:02:26 +0200
Subject: [sles-beta] SLES11-Sp4 GMC succesfully installed,
	many smartd	messages
In-Reply-To: <40637DBB36AF3941B243A286A432CA0B1AF18E89@HXMB12.pnet.ch>
References: <40637DBB36AF3941B243A286A432CA0B1AF18D7D@HXMB12.pnet.ch>
	<20150624095524.GY23790@suse.de>
	<40637DBB36AF3941B243A286A432CA0B1AF18E89@HXMB12.pnet.ch>
Message-ID: <20150624120226.GD23790@suse.de>

Hi Urs,

On Jun 24, 15 10:00:15 +0000, urs.frey at post.ch wrote:
> Hi Stefan
> Only hot air, sorry for that.

No problem. I rather have a false alarm now than a correct one after GM
release ;)

Thanks for checking and testing!

        Stefan
> 
> I disabled service smartd during autoyast installation locally here.
> Smartd is not applicable for me, because on HP Servers local drives are monitored by HP-tools.
> On VMware smartmontools are not applicable too, because we are on virtual drives.
> 
> The only thing I forgot about, is to disable after online update from SLES11SP3 to SLES11SP4, because with a package update, the daemon gets enabled again.
> But that's a local story, so not to worry about.
> 
> 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
> 

-- 
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 behlert at suse.com  Wed Jun 24 06:08:58 2015
From: behlert at suse.com (Stefan Behlert)
Date: Wed, 24 Jun 2015 14:08:58 +0200
Subject: [sles-beta] uefi/autoyast - dell r610/r320 still fails
In-Reply-To: <1E287A5DDB506E478DE9CAE3C8492D0101013393F2@BRDC-MBX-1.network.internal>
References: <1E287A5DDB506E478DE9CAE3C8492D0101013393F2@BRDC-MBX-1.network.internal>
Message-ID: <20150624120858.GE23790@suse.de>

Hi Joel,

On Jun 23, 15 18:58:46 +0000, Joel Barbieri wrote:
> I am still having issues installing UEFI with the base autoyast [-efi] profile I have used for SLES11SP2/SP3 on a Dell r610 server.  I will try again on a different desktop machine [my NUC had to be returned] to see if the problem still mostly follows Dell servers.  [e.g. r610, r320 both never succeeded in UEFI install with autoyast profile]
> 
> I have only done a cursory look at the y2log to this point...it appears as though the yast modules understand my request for a gpt disk label, and then might be deciding to try msdos later.  This will definitely not work because of the dos requirement for an extended partition [#4 in the dos/bios profile] which you do not require with gpt.  Hence, why I have 2 profiles...one efi/gpt, one bios/msdos.  I have used the same profile for msdos since sles11[sp0] and for gpt/efi since sles11sp2.  I also have worked through EFI on opensuse 12.3, 13.1, and 13.2...so I'm wondering what broke here.
> 
> The above "fail" was on a disk that I wiped clean with 0's in its entirety with dd before retrying.
> 
> The only other thing I noted from perusing the logs is that mountby "device" may have changed [could have been a while ago, but still functions].  I will look at the autoyast dtd/schema to see if I can find the new syntax.
> 
> I opened an SR for this in the past.  Should I open a new one for the GMC version?

No need for that. Looking at bug 933673 the root cause seems to be not
found yet :(

I have asked the developers what additional information they need to help
them solve this.

        Stefan

> 
> I plan to debug more in the future, but at the moment want to get closer to finalizing automated oracle-12c installation for our product.
> 
> I also have not tested FIPS related issues [openssh] but will look into that when I get an opportunity.  Currently I have disabled it as part of the build testing I am doing.
> 
> -Joel
> 
> Joel Barbieri
> Merge Healthcare
> 900 Walnut Ridge Dr.
> Hartland, WI
> 
> From: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] On Behalf Of Weigert, Daniel (CORP)
> Sent: Tuesday, June 23, 2015 10:42 AM
> To: urs.frey at post.ch; sles-beta at lists.suse.com
> Subject: Re: [sles-beta] SLES11-Sp4 GMC succesfully installed, many smartd messages
> 
> This should probably be configurable as to which devices are included, or excluded.
> 
> Dan
> 
> From: sles-beta-bounces at lists.suse.com<mailto:sles-beta-bounces at lists.suse.com> [mailto:sles-beta-bounces at lists.suse.com] On Behalf Of urs.frey at post.ch<mailto:urs.frey at post.ch>
> Sent: Tuesday, June 23, 2015 11:39 AM
> To: sles-beta at lists.suse.com<mailto:sles-beta at lists.suse.com>
> Subject: [sles-beta] SLES11-Sp4 GMC succesfully installed, many smartd messages
> 
> Hi
> Thank you very much for SLES11-SP4 x86_64 GMC
> 
> Just installed successfully SLES11-SP4 x86_64 on my test server HP Proliant BL460c-Gen9 using autoyast, having bonded NICs configured.
> Works without any problem
> 
> Online Update from SLES11-SP3 x86_64, kernel 3.0.101-0.47.52-default on my second test server HP Proliant BL465cG7 connected to SAN EMC works also without any problem.
> 
> From what I could see is, that obviously smartd is enabled and does scan my SAN LUNs which is really not a good idea
> 
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdaz, is SMART capable. Adding to "monitor" list.
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdaz, state read from /var/lib/smartmontools/smartd.EMC-SYMMETRIX-6025435AF000.scsi.state
> Jun 23 17:30:29 h04wwl smartd[30169]: Monitoring 0 ATA and 52 SCSI devices
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sda, failed to read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdb, failed to read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdc, failed to read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdd, failed to read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sde, failed to read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdf, failed to read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdg, failed to read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdh, failed to read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdi, failed to read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdj, failed to read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdk, failed to read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdl, failed to read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdm, failed to read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdn, failed to read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdo, failed to read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdp, failed to read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdq, failed to read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdr, failed to read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sds, failed to read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdt, failed to read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdu, failed to read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdv, failed to read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdw, failed to read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdx, failed to read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdy, failed to read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdz, failed to read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdaa, failed to read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdab, failed to read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdac, failed to read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdad, failed to read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdae, failed to read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdaf, failed to read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdag, failed to read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdah, failed to read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdai, failed to read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdaj, failed to read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdak, failed to read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdal, failed to read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdam, failed to read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdan, failed to read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdao, failed to read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdap, failed to read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdaq, failed to read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdar, failed to read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdas, failed to read Temperature
> Jun 23 17:30:29 h04wwl smartd[30169]: Device: /dev/sdat, failed to read Temperature
> Jun 23 17:30:30 h04wwl smartd[30169]: Device: /dev/sdau, failed to read Temperature
> Jun 23 17:30:30 h04wwl smartd[30169]: Device: /dev/sdav, failed to read Temperature
> Jun 23 17:30:30 h04wwl smartd[30169]: Device: /dev/sdaw, failed to read Temperature
> Jun 23 17:30:30 h04wwl smartd[30169]: Device: /dev/sdax, failed to read Temperature
> Jun 23 17:30:30 h04wwl smartd[30169]: Device: /dev/sday, failed to read Temperature
> Jun 23 17:30:30 h04wwl smartd[30169]: Device: /dev/sdaz, failed to read Temperature
> 
> Obviously the service smartd is enabled by default in SLES11-SP4 GMC now.
> 
> Under SLES11-SP3 default was disabled
> h05bug:~ # facter operatingsystemrelease
> 11.3
> h05bug:~ # chkconfig -l smartd
> smartd                    0:off  1:off  2:off  3:off  4:off  5:off  6:off
> h05bug:~ #
> 
> Now under SLES11-SP4 smartd is enabled and causing many messages to be written to /var/log/messages, 1479 messages within 30min!
> h04wwl:/var/log # facter operatingsystemrelease
> 11.4
> h04wwl:/var/log # chkconfig -l smartd
> smartd                    0:off  1:off  2:on   3:on   4:off  5:on   6:off
> h04wwl:/var/log #
> h04wwl:/var/log # grep smartd /var/log/messages | wc -l
> 1479
> h04wwl:/var/log #
> 
> Why is smartd enabled by default?
> Why this change in a GMC?
> 
> Thanks for fixing it.
> 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<mailto:urs.frey at post.ch>
> 
> 
> 
> ________________________________
> This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately by return email and delete the message and any attachments from your system.

> _______________________________________________
> sles-beta mailing list
> sles-beta at lists.suse.com
> http://lists.suse.com/mailman/listinfo/sles-beta


-- 
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 behlert at suse.com  Wed Jun 24 16:45:35 2015
From: behlert at suse.com (Stefan Behlert)
Date: Thu, 25 Jun 2015 00:45:35 +0200
Subject: [sles-beta] New kernel available: 3.0.101-63.1
Message-ID: <20150624224535.GA18748@suse.de>

Hi all,

as you have seen in other mails the kernel on the GMC media had too much
debug output written to the log files.
We therefore put a new kernel (3.0.101-63.1) into the SLE 11 SP4 Pool
channels. 
You get that channel if you have registered your system.

Installing the kernel from there will give you the same kernel
functionalities you have withthe GMC kernel, just without the unneeded log
output.

Note that we have cleaned the update-channels, as we do not want to have
any outdated update there.
This includes the previously available kernel 3.0.101-64.1 in that channel
which which should not be used.
We do not plan to release any updates from now on until we have the
GoldMaster and start releasing our regular maintenance updates.

For those who need/want the fixed kernel on an iso: We plan to release a
GMC2 with that kernel, but until this happens please register and use the
one in the pool channels. It's binary identical to what you will receive
with GMC2 later.

        thanks,
          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)