> On Oct 2, 2015, at 8:15 PM, Mark Post <mp...@suse.com> wrote: > >>>> 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.
Mark, that message shows up only if you use pvscan or pvck with verbose. Which of course does not happen if you are just booting. To dig out that message I’ve linked that disk to another working updated version of SLES (installed on dasda1) and run the pvscan -vvv over there. But if you wait long enough during the boot, it should bring up dracut rescue console eventually (few minutes). And I believe that over there, you can run “lvm pvscan /dev/dasda -vvv” over there and you should get that message as well. And that’s why it fails to boot. Dracut (with lvm pvscan command) scans all devices so it cat put together volume group and it just skips this disk so it ends up with nothing. No root volume. > > 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. > I will see if I can do it. I don’t have the SLES12 license - I’ve just downloaded the 60 days trial. So I am not sure If I even have option to open support requests. > Finally, thank you for the work you've done already. Nice job on behalf of > the rest of the community, to say the least. > Ahh no problem. I enjoy doing that kind of stuff. That’s not work for me ;) Gregory Powiedziuk ---------------------------------------------------------------------- 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/
