I hope my response helps. There's a deepening tech debt w/r/t partitions.
On 09/30/2015 10:59 PM, Grzegorz Powiedziuk 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. > > If you use edevices, you know that the FBA driver in linux automagically > (like Mark explained it to me few years ago ;) ) creates a device “1” > (dasda1 for example) on edevice. > You end up with for example dasda + dasda1 and you use dasda1 for OS > (including LVM) . No fdisks, no fdasds. For FBA (including EDEV and SAN), use 'fdisk'. (And forgive me for repeating some details that you already know.) In my experience, the partition logic sees a default partition even when one was not explicitly created. I found that I could get rid of this ghost partition by explicitly running 'fdisk' and writing an empty partition table. Then "dasda1" goes away. > I haven’t used edevices in a while so I forgot about that and my > recent SLES12 install I did on “dasda” (fba) , instead of “dasda1”. > I don’t know how I did that but I did it and SLES install wizard > didn’t complain. System installed fine and it is was working ok. Wow! Great! I don't recall ever having persuaded the installer to go use the whole disk. For FBA, it should work straight away because the partition table is just blocks of data. (For ECKD, it would not work unless you formatted with 'dasdfmt -d ldl' to force consistent sized blocks across the whole disk.) > pvscan on a build like this returned: > Volume Groups with the clustered attribute will be inaccessible. > PV /dev/dasda VG root lvm2 [19.53 GiB / 0 free] > > while in proper installation it looks like this: > > PV /dev/dasda1 VG lnx15 lvm2 [19.53 GiB / 0 free] > Total: 1 [19.53 GiB] / in use: 1 [19.53 GiB] / in no VG: 0 [0 ] Somehow (either manually or via the installer) you did a 'pvcreate' on the partition in the latter. Both scans are legit. LVM2 is (was??) pretty good about recognizing the PV signature and doing the right thing, partitioned or not. > 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 expect Mark will chime in with the official SUSE response, but sounds like you should open a trouble ticket. There is added pressure for the "all disks are partitioned" assumption with the advent of UEFI. There may also be a channel for PC-oriented assumptions via zLinux use of GRUB. (Which is a good idea in general. Just that the GRUB developers may need to be reminded that not all the world is a PC. And SUSE is very good about getting those patches fed back up the chain.) But I'm only speculating. > 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 That would be really really bad news. But it may be just a symptom of a much smaller bug. > 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. So ... the ghost partition raises its head. I DON'T KNOW if you can 'fdisk' and write an empty partition table on a disk which is already stamped as a PV. Most filesystems are offset far enough from block zero that they have no problem with that. (I have stamped empty partition table on many EXT2/3 volumes. No damage.) Would have to dig a little to learn where 'pvcreate' stamps the PV signature. I take back my compliment to LVM2 for "doing the right thing"! [sigh] > This edevice, if linked to an original SLES12 or any RHEL is working fine. > LVM finds a label on /dev/dasdb (fba) and I can mount it without a problem. If you can get a clean level-zero backup of that disk, then I suggest you try the 'fdisk' trick on it from an alternate system. > I didn’t find anything different in lvm.conf which could cause this. > > To fix this (well it’s rather a dirty hack), I’ve downloaded a > sourcecode of LVM, found the instruction where it exits on message > "Skipping: Partition table signature found” , commented out > that section, compiled, installed this lvm, rebuilt initrds > (both of them) and it worked. I got my system running again. Nice work! > 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) NO Don't settle for partitioned disks simply because "we've always done it that way". If you're using LVM on SAN (especially multi-path), you really *don't* want the added complexity of partitioning. (Here I mean SAN where EDEV is not available, directly to Linux.) Also keep in mind that ECKD formatted with "-d cdl" is not cleanly blocked. (Beyond scope of this conversation, but will bite you if you try to use the "whole disk" for data.) > 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? SUSE's installer (and others) has a lot of work to do in a very tricky context. I have a hard time faulting it when it misses a step like "clear the partition table" (when not used). But it does sound like a fair enhancement request. Just never needed it before because I *always* prep DASD (all forms) before turning the installer loose on them. (ie: from a previously installed Linux or with a CMS tool like SWAPGEN.) -- R; <>< ---------------------------------------------------------------------- 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/
