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
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.
-PGB
--------------------------------- SNIP ------------------------------------
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
--------------------------------- SNIP ------------------------------------
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
