On 03/29/2013 01:23 AM, Joakim Ziegler wrote:
Immediately after getting dropped to rdshell, I looked around in /dev, which brought me a few surprises...
/dev/mapper contains only "control", that is, "vg_resolve02-lv_root" is missing.
Did you get to look at or for /dev/vg_resolve02 as well?
/dev/root is a symlink to /dev/dm-0
Does /dev/dm-0 exist?
Does the system boot if you just "exit" from the rdshell? What about if you "vgchange -a y" without changing the symlink?
That means /dev/root already is correct, so the only thing I'm actually changing to make the system boot is to scan for volume groups and activate them.
The big question then becomes: Why do I have to do this manually? How do I make Dracut (I assume this is Dracut's job) make this automatically?
udev should be doing this. And... I was just looking at this again, because the last time I came up with nothing useful. Look at /usr/share/dracut/modules.d/90lvm/64-lvm.rules. If I'm reading this correctly, udev will look for dm-0 in /sys and will not run lvm_scan if it's found. I wonder if it's possible that the /sys nodes are getting set up, but device-mapper isn't setting up the nodes in /dev?
I'm really at a loss... it seems like a much simpler explanation is simply that the devices take so long to detect that init gives up. When you run vgchange, they've had the time they need. That idea is inconsistent with the fact that your dmesg output shows what I assume is the correct devices and partition tables.
You could try adding "rdinitdebug rdudevdebug" to your kernel command line, but you're going to see a LOT of output, and it's only really going to be meaningful if you've read the /init script that Dracut creates, and understand more or less what it's doing, particularly in the "main_loop" section.