Trog Dog wrote:Ok, after an unsuccessful attempt last night (box booted but I don't believe /usr did) - tonight I tried, but only applied the 3 patches, did not modify /etc/fstab (lvm partitions are still referenced as /dev/vg...) didn't modify any runlevels - and this box boots fine and as far as I can tell everything works. I'm going to try this process on another box.
EDIT: Confirmed on second box - set CONFIG_DEVTMPFS in kernel and recompiled, reboot, ok, applied 3 patches - reboot all ok but for gnome-terminal - ssh'd into box set CONFIG_DEVTMPFS_MOUNT in kernel and recompiled, reboot, ok.
did not modify fstab or runlevels
AFAICT both boxes are working correctly
w00t! that's great Trog Dog :-)
Can I check, when you say you "didn't modify any runlevels" do you mean that udev is still in sysinit? If so, it'll be starting before localmount (which is in boot;
rc-update show), which means you're not actually using the new setup: to be sure all devices started by udev are ok, now and into the future, udev scripts must be able to access /usr (for pci-ids and hwdb, iirc) and afaict, technically there's no knowing what other partitions they might access (or at least, that's the new position.) It's a safe bet they're not going to need /home, /tmp or anything like /usr/{src,portage} but they might for example, install into /opt, or need access to /var.
I have to admit I don't understand how pushing the resolution of the chicken-and-egg nature of, say, needing a udev-configured device to access /usr, while also needing that same partition to run the udev initscripts, is any easier to handle without root (assuming ofc that the root device doesn't need initialising in userspace- which would be the traditional reason to need an initrd.) I guess the reasoning is that they have to support the initrd, and they don't want to support the traditional method, which I can understand. It's just a shame imo; if they'd had a similar process in terms of making such massive changes to user-space/ system-administration that Gentoo has for GLEPs, I really don't believe they'd have got through it, and scripts that were playing silly buggers would have been sorted out (perhaps by conceding pci-ids and hwdb should be installed to root if the distro/ user so configured it, and either redoing the 2-phase sequence they tried to implement before, or just insisting that device-initialisation be installed to root. After all, if it's going to be run by udev during sysinit, it'll be run as root.)
wrt lvm, what version are you on? I was running lvm2-2.02.73 for over a year, and everything was fine with udev; it was when I upgraded to 2.02.88 that things went awry; so if it messes up you know what to do: change fstab to use /dev/mapper/vg-lv as opposed to /dev/vg/lv. If you check
/etc/init.d/udev in the populate_dev() function, you'll see the following comment:
Code: Select all
# we can speed up booting under these conditions:
# * using devtmpfs so kernel creates device nodes for us
# * only using kernel created device nodes at boot
# (in /etc/fstab and elsewhere)
/dev/mapper is a kernel-created node, and prior to the upgrade to 2.02.88, lvm was creating the /dev/vg/lv nodes in its startup. The lvm initscript still passes the parameter in
/lib/rcscripts/addons/lvm-start.sh -- it runs
/sbin/vgscan --mknodes but on my machine at least, that doesn't set up the nodes (or maybe they get overwritten when udev starts, I'm not sure.) I was having to reboot and run the scan manually, which gave me a warning for each logical volume, about how udev was supposed to have made the nodes.
]
