folks on lkml and linux-lvm, hi: firstly - apologies for using LKML for an issue that's come up on the debian gnu/linux distribution, but bear with me there's a reason why, which will become clear with a little bit of explanation. secondly - i've got a working system [so this is not a "request by uh usah askin fuh help on da LKML" :) ] it's about resolving what the heck's going on, so that gnu/linux distros don't end up putting out combinations of packages that will cause systems to keel over sideways. the issue: on a system which has its root filesystem on an LVM2 partition, i've just upgraded [nothing but] linux kernel 2.6.32 (amd64) to 2.6.39. debian's initramfs-tools happily rebuilt the initrd, which involves stuffing libdevmapper and a boat-load of other stuff into it, in order to detect and understand LVM2 partitions. on a reboot, after showing only about 5-8 lines of kernel messages, the system said it failed to find a root filesystem. kernel panic, me panic, lovely shiny expensive mac which, using EFI, is a bugger to rescue, i reboot and select the older 2.6.32 kernel, and it's absolutely fine. whew. can begin investigating. so at this point i'm puzzled, because it's userspace-kernelspace interaction and yet there's no recognition of this inter-dependency in the debian package specs. 2.6.32 works yet 2.6.39 doesn't, with versions of dmsetup and libdevmapper from debian-sid - numbers shown here: # squeeze (stable) (libs): The Linux Kernel Device Mapper userspace library 2:1.02.48-5: amd64 armel i386 ia64 mips mipsel powerpc s390 sparc now, just on a long shot, i upgraded grub (and i think lvm2 as well, or it was a part-dependency). this resulted in dmsetup as well as libdevmapper1.02 also being upgraded, to the following version: # wheezy (testing) (libs): The Linux Kernel Device Mapper userspace library 2:1.02.63-3: amd64 armel i386 ia64 mips mipsel powerpc s390 sparc [for people not familiar with debian numbering, 1.02.63 and 1.02.48 are the "original" i.e. upstream package version numbers - the bit after the dash is a debian numbering that covers the debian packaging (i.e. they've had to do 5 versions of 1.02.48 packaging, with little tweaks and/or patches to suit debian) and for the most part can be ignored]. at this point - 2.6.39 kernel and with dmsetup and libdevmapper 1.02.63 - the resultant initrd *successfully* recognised the LVM2 root filesystem at boot time, and the debian gnu/linux distro happily booted. just for kicks i tested 2.6.32 as well with the new version of libdevmapper, and that was happy too. so, we have an unusual situation in which the linux kernel appears to require a dependency on a specific version of a userspace library for booting a system (which the debian linux kernel maintainer quite rightly objected to "fixing" by adding random dependencies for random userspace libraries. as they said in Galaxy Quest, "ohhh. that's not riiiight"...) so, with that as background, one debian user raised an interesting question: has any _other_ gnu/linux distro encountered this issue, and if so, how was it resolved? on the basis that there are dozens of gnu/linux distros out there, it being somewhat impractical to go round asking them all "hey, there's this weird issue, like...", and on the technically-justifiable excuse that it's a kernelspace-userspace interaction, i thought it ok to raise this to a wide audience i.e. LKML to see if anyone's come across this as well (redhat, suse, fedora, arch etc.) aside from that, does anyone else know what the heck's actually going on, here? :) other bits of info which might or might not be relevant: yes it's a mac with EFI boot, but yes grub2-efi does actually work. yes the root partition is on LVM2 but the /boot i put onto its own (ext2) partition. not sure if that makes any difference: i _think_ i'm glad i did that. the only other thing is that the upgrade recommended that partitions be renamed to use UUIDs, to which i went "yep, sure, why not". the only visible change i yet determined occurred through that decision was that /etc/fstab was modified (the /boot partition /dev/sda3) to a UUID but of course the LVM2 partitions in /etc/fstab were left alone. can't see how that might be relevant, but someone else might, hence why i'm mentioning it. l. _______________________________________________ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
