After a fresh install, with / on a logical volume the system failes to boot because fsck can't access the device node for /. The device nodes are created correctly when vgscan is run from the initrd (checked with real_root=shell). When the new /dev is made only nodes from the device tarball (and presumably ones registered with udev after that) are created. This means that (in my case) /dev/rootvg/slashlv doesn't exist and checkroot fails. If I manually add the nodes to the device tarball, the system will boot. This isn't a good solution -- the device nodes should be copied into the new /dev before the one from the initrd goes away. Maybe in linuxrc? This used to work. I built the initrd using genkernel-3.1.6.
*** This bug has been marked as a duplicate of 72746 ***
The description of bug 72746 doesn't even remotely match this one (other than some of the same components are involved). Quite frankly, I reviewed 72746 before I submitted 90567 and didn't think they were related. Since dm-mod is loaded from the initrd in my case, clearly it's not a timing problem as speculated in 72746. Since the device nodes are created for the /dev used by the initrd, and since udev is running then, the compiled-in-ness of the device mapper code isn't an issue. It looks like the linuxrc in the initrd needs to copy some nodes right before it pivot-root's (or it needs to tell udevd to re-make all of the nodes it knows about). This bug may be mis-categorized, but it doesn't describe the same problem as the other bug. 72746 doesn't seem to be related to the deviced nodes existing during the ramdisk-phase of boot and then not existing later.
Is this still an issue? if it is could you unmask genkernel-3.2.0 and try that?
User response needed... (Latest genkernel is 3.3.5 now.)
A recent genkernel fixed the problem. Thanks.
