[pkg-cryptsetup-devel] Bug#511840: Initrd fails to find root device after boot into system following install

[Jonas Meurer]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/attachments/20090219/9944fbfe/attachment.pgp