From Joel.Barbieri at merge.com  Tue Jul 14 14:02:44 2015
From: Joel.Barbieri at merge.com (Joel Barbieri)
Date: Tue, 14 Jul 2015 20:02:44 +0000
Subject: [sles-beta] uefi/autoyast - dell r610/r320 still fails
In-Reply-To: <20150624120858.GE23790@suse.de>
References: <1E287A5DDB506E478DE9CAE3C8492D0101013393F2@BRDC-MBX-1.network.internal>
	<20150624120858.GE23790@suse.de>
Message-ID: <1E287A5DDB506E478DE9CAE3C8492D010101343890@BRDC-MBX-1.network.internal>


Uncertain if this list is still active  [sles11sp4].  Spent time troubleshooting EFI boot on Dell r610 server today.

Determined that must specify a device on this hardware in the partitioning section [but not necessarily other hardware...unknown reason yet...change from all other autoyast profiles for sles11sp2, sles11sp3, os13.1, os13.2].

e.g.

<partitioning config:type="list">
 <drive>
 <device>/dev/sda</device>
....

The device line is necessary on this system.  The idea behind autoyast is that it is supposed to fill in the blanks as much as possible to have a hardware independent profile...so this required change is new.  I would still call it an autoyast bug...I remember the old /dev/cciss drivers from HP, which this would conflict with.  I know the driver has been updated, and may replace even the cciss driver, but I have not validated yet that the old HP RAID cards would not show up as sda as opposed to cciss.

Hopefully this information helps to troubleshoot the problem.

-Joel

-----Original Message-----
From: sles-beta-bounces at lists.suse.com [mailto:sles-beta-bounces at lists.suse.com] On Behalf Of Stefan Behlert
Sent: Wednesday, June 24, 2015 7:09 AM
To: sles-beta at lists.suse.com
Subject: Re: [sles-beta] uefi/autoyast - dell r610/r320 still fails

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