Bug#397887: Re: Bug#397887: [Pkg-cryptsetup-devel] Bug#397887: resume
support renders system unbootable
david at hardeman.nu
Sun Nov 12 23:08:53 CET 2006
On Sun, Nov 12, 2006 at 09:48:16PM +0100, martin f krafft wrote:
>also sprach David Härdeman <david at hardeman.nu> [2006.11.12.1645 +0100]:
>> Then, provided that the swap entry is configured in /etc/crypttab, run
>> "/etc/init.d/cryptdisks start" and it'll do the setup for you.
>lapse:~# grep hda2 /etc/crypttab
>cr_hda2 /dev/hda2 cr_hda5 keyscript=/root/decrypt_derived,hash=sha256,size=256,cipher=aes-cbc-essiv:sha256
>lapse:~# /etc/init.d/cryptdisks start
>Starting remaining crypto disks... cr_hda5(running) cr_hda6(running) cr_hda7(running) cr_hda8(running) cr_hda9(running) cr_hda2(starting)-e
> - The device /dev/hda2 contains a valid filesystem type swap.
>the precheck for '/dev/hda2' failed, skipping
>It doesn't... I had to dd /dev/zero for a bit, then it worked. Just FYI.
Probably some old signature left on the disk. I'm not sure but it's
completely possible that e.g. luks leaves the first block or two
>> After this is done you should have an encrypted swap up an running again
>> (but based on the derived key), so regenerate the initramfs image and
>> see whether it is now able to setup the swap device during the initramfs
>> stage of the boot.
>Nope, I am only getting
> cryptsetup: unknown fstype, bad password or options?
>The problem seems to be the lack of /usr/bin/wc in the initrd, which
>the keyscript needs -- the init.d script later complains about
>a missing wc.
>So I hacked the attached version, which does without wc and cut, but
>the initramfs still does not boot. In retrospect, busybox should be
>providing all these...
Ah, that's right. I've used the suggestions you've made to change my
local version of the script.
>I think the reason is that even though my cryptswap gets
>created/setup correctly, /bin/fstype returns unknown for FSTYPE, and
>thus the cryptroot script thinks that something went wrong and loops
>endlessly. For some reason, mkswap didn't work. It did, however,
>when I tried again.
I think the reason is that you changed the script slightly when you
rewrote it, in the attached script, the last line says "echo ..." while
it used to say "echo -n ..." so now the passphrase which the swap
partition was setup with included a newline so the first time you used
your changed script you also got a different key for the swap partition.
>Anyway, the problem continues to exist once I tried suspend2disk,
>since now surely fstype doesn't recognise the partition type
>anymore. I am not sure what the point is of verifying a valid
>filesystem type -- fstype is never going to know about all of them.
So you did manage to boot using the script after rewriting it and
rerunning mkswap? And then it failed after you'd done a suspend2disk for
the first time, correct?
>So why not just skip the $FSTYPE = unknown check and continue if the
>mapping was set up properly?
fstype is the only way that the initramfs script can know if a dm-crypt
device has been setup with the right passphrase or not since the only
thing that differences the wrong key from the right one is that the
dm-crypt device that is setup contains gibberish.
More information about the Pkg-cryptsetup-devel