On Sat, May 4, 2013 at 3:05 PM, Fabio Erculiani <lx...@gentoo.org> wrote: > > Scenario: > - you have an initramfs with mdev, your pivot_chroot system runs udev. > - you have a LVM volume group, containing the lvm volume for / and > /home, and perhaps you also have swap on another volume. > - you boot using the current genkernel initramfs, which uses mdev and > comes with lvm support > > The initramfs code activates your lvm volumes, lvm itself may or not > may be compiled with udev support. In the former case, nothing gets > written onto /run/udev (and devtmpfs), in the latter case, lvm writes > metadata that are useful to lvm itself to udev. > mdev is not udev, doesn't deal with udev rules so the metadata is > either pristine or completely unavailable. > busybox switches root and the boot starts: you obviously have lvm > compiled with udev there, since you're using udev (or systemd-udevd, > or gudev). The lvm there is either unable to find valid metadata so it > doesn't automatically activate the volumes (note: /home does not get > activated by the initramfs code) or, until some time ago but now > defaulted to off, lvm itself creates the device nodes (which should > have been created by udev + udev rules if lvm is compiled with udev > support). > If it's not enough, our current genkernel initramfs code (I fixed this > as well, it's in the systemd-love overlay) doesn't mount --move /run > to /newroot before switching root, so /run/udev is not ported over, > which means that even if mdev would have been able to do do all the > udev magic, things wouldn't work anyway. > > Long story short, we should: > 1) give up with cross compiler support in genkernel, which has been > anyway in a broken state for ages. Nobody is using it anyway. > 2) make possible to optionally use udev in the initramfs (compiling > just for it is a pita and the trend here [dracut and others do this] > is to copy udevd from the system) > 3) default to udev? >
I just forgot the tricky part. If future lvm versions are going to use udev more extensively (for eg: storing more critical metadata in it), the net result will be that mdev won't work anymore. This is why I wrote that lvm is working "by miracle for now". mdev is not future proof wrt lvm support. > > -- > Fabio Erculiani -- Fabio Erculiani
