Bug#397887: Re: Re: Bug#397887: Re: Bug#397887: [Pkg-cryptsetup-devel] Bug#397887: resume support renders system unbootable
also sprach David Härdeman [EMAIL PROTECTED] [2006.11.13.0014 +0100]: So that means that suspend2disk actually removes the swap signature from disk when you suspend. I seemed to recall that the suspend solutions didn't do that but reading the source it seems I'm wrong. Aparently. Also note that there are two different implementations of suspend2disk... I wrote a quick patch to add detection of swsusp, suspend2 and uswsusp to fstype and sent it to the to the klibc ML and as a BR against klibc-utils a couple of minutes ago. You rock. Thanks! -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems signature.asc Description: Digital signature (GPG/PGP)
Bug#397887: Re: Re: Bug#397887: Re: Bug#397887: [Pkg-cryptsetup-devel] Bug#397887: resume support renders system unbootable
On Mon, November 13, 2006 10:39, martin f krafft said: also sprach David Härdeman [EMAIL PROTECTED] [2006.11.13.0014 +0100]: So that means that suspend2disk actually removes the swap signature from disk when you suspend. I seemed to recall that the suspend solutions didn't do that but reading the source it seems I'm wrong. Aparently. Also note that there are two different implementations of suspend2disk... I take it that you're referring to the in-kernel swsusp and out-of-kernel suspend2 projects? If yes, they are both supported by the patch I wrote (and also the new and shiny in-kernel uswsusp). If no, please tell me which suspend implementation I've missed. And on a related note, this bug now seems to be as fixed as can be in the sense of cryptsetup. The bug report to watch is now #398302 (add suspend detection to fstype). -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397887: Re: Bug#397887: [Pkg-cryptsetup-devel] Bug#397887: resume support renders system unbootable
also sprach David Härdeman [EMAIL PROTECTED] [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.
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?
[...]
ad inifitum...
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...
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.
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 why not just skip the $FSTYPE = unknown check and continue if the
mapping was set up properly?
--
.''`. martin f. krafft [EMAIL PROTECTED]
: :' : proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck - http://debiansystem.info
`- Debian - when you have better things to do than fixing systems
#!/bin/sh
NODE=$1
ME=${0##*/}
if [ -z $NODE ]; then
echo $ME: must be executed with a crypto device as argument 2
exit 1
fi
if ! device=$(dmsetup table 2/dev/null | grep $NODE); then
echo $ME: failed to read device-mapper table 2
exit 1
fi
if [ -z $device ]; then
echo $ME: device $NODE doesn't exist 2
exit 1
fi
seen=0
IFS_old=$IFS; IFS='
';
for i in $device; do seen=$(($seen + 1)); done
IFS=$IFS_OLD
if [ $seen -ne 1 ]; then
echo $0: more than one device match $1 2
exit 1
fi
eval set -- $device
if [ $4 != crypt ]; then
echo $ME: device $NODE is not a crypto device 2
exit 1
fi
echo $6
exit 0
signature.asc
Description: Digital signature (GPG/PGP)
Bug#397887: Re: Bug#397887: [Pkg-cryptsetup-devel] Bug#397887: resume support renders system unbootable
also sprach David Härdeman [EMAIL PROTECTED] [2006.11.12.1715 +0100]: I'm not able to reproduce this (by using a valid keyscript which is present and executable) Of course I forgot to make it +x. More in the other reply. -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems signature.asc Description: Digital signature (GPG/PGP)
Bug#397887: Re: Bug#397887: [Pkg-cryptsetup-devel] Bug#397887: resume support renders system unbootable
On Sun, Nov 12, 2006 at 09:48:16PM +0100, martin f krafft wrote: also sprach David Härdeman [EMAIL PROTECTED] [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 untouched. 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? [...] ad inifitum... 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. -- David Härdeman
Bug#397887: Re: Bug#397887: Re: Bug#397887: [Pkg-cryptsetup-devel] Bug#397887: resume support renders system unbootable
also sprach David Härdeman [EMAIL PROTECTED] [2006.11.12.2308 +0100]: 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. Good spot. This sound plausible, we'll just assume this is what happened. :) 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? Yes. 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. Ouch. I guess this is fixed with luks, huh? Anyway, so we need to add detection for uswsusp and suspend2 swap partitions to fstype I guess... -- .''`. martin f. krafft [EMAIL PROTECTED] : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems signature.asc Description: Digital signature (GPG/PGP)
Bug#397887: Re: Bug#397887: Re: Bug#397887: [Pkg-cryptsetup-devel] Bug#397887: resume support renders system unbootable
On Sun, Nov 12, 2006 at 11:24:53PM +0100, martin f krafft wrote: also sprach David Härdeman [EMAIL PROTECTED] [2006.11.12.2308 +0100]: 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. Good spot. This sound plausible, we'll just assume this is what happened. :) 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? Yes. So that means that suspend2disk actually removes the swap signature from disk when you suspend. I seemed to recall that the suspend solutions didn't do that but reading the source it seems I'm wrong. 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. Ouch. I guess this is fixed with luks, huh? Yup (although the initramfs scripts still run a fstype check, and I think it'll stay that way for now, it's better to fix fstype) Anyway, so we need to add detection for uswsusp and suspend2 swap partitions to fstype I guess... I wrote a quick patch to add detection of swsusp, suspend2 and uswsusp to fstype and sent it to the to the klibc ML and as a BR against klibc-utils a couple of minutes ago. -- David Härdeman
