>>> On 9/30/2015 at 10:59 PM, Grzegorz Powiedziuk <gpowiedz...@gmail.com> >>> wrote: > I think I might have found a small bug in latest update for SLES12 so this > is just a FYI for everyone who made the same mistake I did. -snip- > Everything was working fine, until I did an update. Something has changed in > the way LVM recognizes physical devices and it totally brakes the whole > system. It breaks all the parts where LVM is being called which includes the > little initrd which is loaded by zipl during the first stage of boot.
I was able to reproduce this situation. I did an install, with /home on a PV using /dev/dasdb (an EDEV) and not /dev/dasdb1. After updating to the current maintenance level, pvscan doesn't show any PVs out there. There were a total of 259 updates that got applied. I did the kernel first, since that's an easy one to isolate. It didn't cause the problem. So, not sure just yet what did. > I did some debugging and I found that with latest update of SLES (I don*t > know why because the LVM seems to be in the same version) lvm doesn*t like > having metadata on *dasda* (fba) anymore. It likes it only if its on dasda1 > When pvscan scans the disk it ends up with: > /dev/dasda: Skipping: Partition table signature found > so it does not find the label and it fails to bring online the pv and volume > group. I haven't see that message at all. I just get nothing back. -snip- > So the lesson is to make sure that SLES is being installed on dasda1 (fba) > not dasda (only if you have edevices - with standard ECKDs it*s probably > ok to do that) Oh no, absolutely not. For anything named /dev/dasd? use the partition(s), rather than try to remember what the exceptions are that might work. > If you already have it on dasda (FBA) - don*t update it without > preparations. > > Perhaps SLES shouldn*t allow to install a system this way at all? You wouldn't believe how complex it is to try and figure out what block devices are what, which to use, what ones have the "fake" partition tables the DASD driver creates, what's virtual (VDISKs look just like 9336 devices also), what not, etc. Totally stinks. Looking back, it would have been much better in the long wrong for those imaginary partition tables to never have been used, but here we are. As Rick suggested, if you don't have a support request open with your support provider, do so as soon as possible. It's clear that something changed between SLES12 GA and now, and we clearly don't have an automated QA test for this situation, or whatever update caused it would never have made it out the door. Even if we wind up sticking with the current behavior, that's something that will have to be managed carefully so that other customers don't encounter problems. Finally, thank you for the work you've done already. Nice job on behalf of the rest of the community, to say the least. Mark Post ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For more information on Linux on System z, visit http://wiki.linuxvm.org/
