Hey, Maks, I spent several hours now on debugging this issue, and all I found out is that the patch by Pyotr is correct if you don't want to change the way, how initramfs manages /dev/root.
On 16/01/2009 Pyotr Berezhkov wrote: > On 15 Jan 09, maximilian attems wrote: > > how about you debug the real cause of the failure, see > > http://wiki.debian.org/InitramfsDebug for more hints. > > Thank you. I took a look at it. I'm already quite familiar with the > busybox environment in /initrd. It's what allowed me to diagnose and > solve this bug. As to the real cause of the failure, you can see the > explanation in Bug#511447, my original bug report which has now been > merged with this one by Christian Perrier. > > > the bug is already reassigned to cryptsetup. > > anyway the way you tried to solve it is out of question: > > random script deleting the root device node. > > Well, actually, the root device node is at $NEWROOT, i.e. > /dev/mapper/foo-bar_crypt. But if we want to have something at > /dev/root, then we can do this (revised patch is at end of message): > > ln -s $NEWROOT /dev/root after hours of debugging, it seems to me that /dev/root is required for setups with lilo and initramfs. At least in my tests, the system didn't boot when /dev/root was unavailable. Initfamfs waited for /dev/root to appear several minutes and then started the rescue busybox shell. > I wouldn't call /scripts/local-top/cryptroot a "random script". It's > charged with setting up the root device, so I don't see any problem with > allowing it to make /dev/root agree with the root device it just set up. > After all, a /dev/root with incorrect major/minor numbers isn't doing > us much good anyway (that's what led to boot failure in the first > place). And /conf/param.conf was created for just this purpose - to > allow called scripts to change global variables in /init. Maks, you need to decide whether it's ok to setup /dev/root properly in thirdparty initramfs scripts (like cryptroot), or whether that should be done in native initramfs functions. But if you want initramfs-tools to setup /dev/root itself, then at least it should give persistant results. currently /dev/root is setup by parse_numeric() from scripts/functions, which is invoked by init just after scripts/${BOOT}. This seems like the correct place to invoke after all. The real issue is that parse_numeric() doesn't setup /dev/root in a persistent way. Instead it touches /dev/root only when $ROOT contains numbers (major&minor), not when $ROOT contains the devicename, what is the case in most situations. Additionally, parse_numeric() doesn't touch /dev/root at all in case that the file already exists. > diff --git a/scripts/local-top/cryptroot b/scripts/local-top/cryptroot > index 56d1d63..5b5cd8d 100755 > --- a/scripts/local-top/cryptroot > +++ b/scripts/local-top/cryptroot > @@ -264,6 +264,11 @@ setup_mapping() > fi > > message "cryptsetup: $crypttarget setup successfully" > + echo "ROOT=$NEWROOT" >> /conf/param.conf > + if [ -e "/dev/root" ]; then > + rm -f /dev/root > + fi > + ln -s $NEWROOT /dev/root > break > done I didn't do further (non-lilo-setup) tests with this patch applied yet, but at least it workarounds the problem that initramfs doesn't provide a persistant way to setup /dev/root as either block file or symlink that points to the real rootfs device (regardless whether it's a physical partition, lvm volume or dm-crypt mapping). So indeed it is a working fix for the reported bug. Maks, please consider that I've not much experience with initramfs-tools development at all. David Härdeman, the guy who did cryptroot initramfs stuff in the past is very busy with reallife at the moment. so please be patient with me. I'll give my best to learn rapidly ;-) greetings, jonas
signature.asc
Description: Digital signature
