Cryptsetup with sata drive and cryptoroot

[Reinhard Tartler]

Scott, Ian,

After reading and chatting with Scott in IRC, it seems that the below
patch should not be necessary anymore. Could you please comment on the
patch below? How does this integrate into
https://wiki.ubuntu.com/UdevDeviceMapper?

What changes should be done on the cryptsetup side so that booting
From a crypted rootfs becomes possible? 

What happens if that rootfs is on an lvm on raid?

Ilkka Tuohela <hile at iki.fi> writes:

> ti, 2007-02-06 kello 20:55 +0100, Reinhard Tartler kirjoitti:
>> Ilkka Tuohela <hile at iki.fi> writes:
>> 
>> > I already have posted a bug with patch for this, but since it has not 
>> > appeared in the package for 3 months I think it's lost so I'll contact
>> > you directly.
>> 
>> Thank you very much for your patch, I think you did the right thing to
>> contact us both. Could you please tell us the bugno of the bug you refer
>> in this context?
>
> This fix should close ubuntu bugs 21878 and 82071 for feisty.
>
> https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/21878
> https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/82071
>
>> Your patch seems to solve
>> https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/75681 for root on
>> cryptsetup. Since it seems to be the same problem, would it be possible
>> to solve it in the same place? Does the same problems exist in debian as
>> well?
>
> I don't think so, because the mdadm script is not expecting the device
> we are looking for. It's the lvm script which should do this, and does,
> it just does not understand LUKS nodes.
>
> As I said, my loops are directly copied from LVM scripts, and when we
> execute the lvm scripts, the commands will go though without problems. 
> The reason we can't expect lvm script to handle this, is that LVM will 
> hang the boot process for the length of the testing loop. 
>
> Current way it 'works'
> - lvm script executes and expects to find LVM from the root= parameter,
>   the device is encrypted so it isn't valid and loop continues until
>   the it expires in 3 minutes
> - after this cryptsetup script will find the root device just fine, if 
>   it is executed after lvm script, since lvm script took care of getting
>   the device online
>
> So, kind of chicken and egg stuff - if lvm script does the device
> detection, it takes long time, and if cryptsetup script is before 
> lvm script, it has to wait for device.
>
> Anyway, my loop is usually safe because it does return quickly if 
> the device node appears normally (within couple of seconds). If you
> configure nonexisting root device, it hangs for 3 minutes, but I don't
> see this as a big problem...


Patch following here:

--- /usr/share/initramfs-tools/scripts/local-top/cryptroot	2007-01-27 14:36:12.000000000 +0300
+++ usr/share/initramfs-tools/scripts/local-top/cryptroot	2006-12-15 10:18:09.000000000 +0300
@@ -8,7 +8,7 @@
 	# Make sure that cryptroot is run last in local-top
 	for req in /scripts/local-top/*; do
 		script=$(basename $req)
-		if [ $script != cryptroot ]; then
+		if [ $script != cryptroot -a $script != lvm ]; then
 			echo $script
 		fi
 	done
@@ -110,7 +110,14 @@
 	# Reduce padded --'s to -'s
 	vg=$(echo ${vg} | sed -e 's#--#-#g')
 
-	vgchange -ay ${vg}
+	slumber=360
+	while [ ${slumber} -gt 0 -a ! -d "/dev/${vg}" ]; do
+  		lvm pvscan > /dev/null 2>&1
+  		lvm vgchange -ay ${vg} > /dev/null 2>&1
+  		/bin/sleep 0.5
+  		slumber=$(( ${slumber} - 1 ))
+	done
+
 	return $?
 }
 
@@ -156,6 +163,12 @@
 		activate_vg $cryptsource
 	fi
 
+	slumber=360
+	while [ ${slumber} -gt 0 -a ! -r "$cryptsource" ]; do
+  		slumber=$(( ${slumber} - 1 ))
+		/bin/sleep 0.5
+	done
+
 	if [ ! -e $cryptsource ]; then
 		echo "cryptsetup: Source device $cryptsource not found"
 		return 1


-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 213 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20070207/d90f851d/attachment.pgp