[linux-lvm] linux kernel 2.6.39 LVM2 rootfs initrd kernel panic "no rootfs found" with userspace dmsetup+libdevmapper <= 1.02.48

Matthew Gillen me at mattgillen.net
Mon Aug 8 13:39:17 UTC 2011


On 08/06/2011 06:09 PM, Luke Kenneth Casson Leighton wrote:
> 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...
> 
> 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?

I don't think it is resolved anywhere (Redhat/Fedora kernel packages
also have a very minimal set of user-space deps that do not include any
of the LVM auxiliary programs.  It's a nasty problem that would only
really be solved by packaging kernel-modules (or least the ones with
additional user-space dependencies) separately from the kernel core.
But package maintainers are resistant to that because it makes for more
management headaches...

The RPMFusion/kmod packages for Fedora take this approach for various
third-party modules (e.g. the linkage between the nvidia kernel module
and the nvidia libGL userspace library; separate packages because the
kernel module is tied to both a kernel version and a driver-release
version, while the userspace library is tied only to a driver-release
version).  I'm sure if you trolled the fedora-devel list from a few
years ago you'd find a big debate about this (there was at one time a
question as to whether the kmod packaging system would be used for
officially supported modules; they decided to not support kmod officially).

Matt




More information about the linux-lvm mailing list