Unable to boot with encrypted swap

Unable to boot with encrypted swap

[Michael Chapman]

Hello,

I am using Fedora 19's dracut-027-45.git20130430.

I have what is possibly an unusual configuration: my swap and /home are 
encrypted, however my root filesystem is not. In /etc/crypttab I have 
configured LUKS to take the swap volume's password from /dev/urandom; it 
also has the "swap" flag so that it is mkswap'ed during boot.

The problem I am experiencing is that my initramfs hangs waiting for the 
swap device to appear.

As of commit dd5875499ece9dbc90e10eafd0073ee15d0c86a4, it looks like 
Dracut adds discovered swap partitions to the list of devices to wait for. 
However since my root filesystem itself is not encrypted, no crypto 
components are actually installed into the initramfs. The end result is 
that this volume never appears, and so the initramfs never continues on.

I am not sure of the background behind this commit. Is there a real need 
to wait for swap during initramfs? Won't this just be picked up later by 
systemd?

Should Dracut just skip swap partitions that are encrypted? Or should it 
detect the existence of an encrypted swap partition and treat it as it 
would an encrypted root?

For now, I've had to revert that commit on my system for it to be able to 
boot.

Regards,
Michael

Re: Unable to boot with encrypted swap

[Joseph D. Wagner]

On 05/13/2013 07:43 PM, Michael Chapman wrote:
> Hello,
>
> I am using Fedora 19's dracut-027-45.git20130430.
>
> I have what is possibly an unusual configuration: my swap and /home 
> are encrypted, however my root filesystem is not. In /etc/crypttab I 
> have configured LUKS to take the swap volume's password from 
> /dev/urandom; it also has the "swap" flag so that it is mkswap'ed 
> during boot.
>
> The problem I am experiencing is that my initramfs hangs waiting for 
> the swap device to appear.
>
> As of commit dd5875499ece9dbc90e10eafd0073ee15d0c86a4, it looks like 
> Dracut adds discovered swap partitions to the list of devices to wait 
> for. However since my root filesystem itself is not encrypted, no 
> crypto components are actually installed into the initramfs. The end 
> result is that this volume never appears, and so the initramfs never 
> continues on.
>
> I am not sure of the background behind this commit. Is there a real 
> need to wait for swap during initramfs? Won't this just be picked up 
> later by systemd?
>
> Should Dracut just skip swap partitions that are encrypted? Or should 
> it detect the existence of an encrypted swap partition and treat it as 
> it would an encrypted root?
>
> For now, I've had to revert that commit on my system for it to be able 
> to boot.
>
> Regards,
> Michael
>

I'm pretty sure this is needed for resume-from-suspend.  My money is on 
a configuration problem.  I'd be happy to take a look.

Please post:
/etc/crypttab
/etc/fstab
/proc/partitions
/proc/cmdline
output from `blkid'

Re: Unable to boot with encrypted swap

[Michael Chapman]

On Mon, 13 May 2013, Joseph D. Wagner wrote:
> I'm pretty sure this is needed for resume-from-suspend.  My money is on a 
> configuration problem.  I'd be happy to take a look.

Wonderful! First, I should point out I've also got LVM:

   LV   VG      Attr      LSize   Pool Origin Data%  Move Log Copy%  Convert
   home ogopogo -wi-ao--- 31.46g
   root ogopogo -wi-ao--- 31.46g
   swap ogopogo -wi-ao---  8.39g

So /etc/crypttab references these LVs:

   luks-home /dev/ogopogo/home none
   luks-swap /dev/ogopogo/swap /dev/urandom swap

And /etc/fstab references the swap volume by device mapper name (can't use 
UUID, of course, since that changes on each mkswap):

   UUID=c73aa277-ff32-42d0-a6f1-681694ba7b36 /         ext4 defaults                            1 1
   UUID=009ef157-66a8-42cb-869e-436244f39ca2 /boot     ext4 defaults                            1 2
   UUID=1400-EDC0                            /boot/efi vfat defaults,umask=0077,shortname=winnt 0 0
   UUID=50c2abf5-84b0-4752-b527-e94b82b208f8 /home     ext4 defaults                            1 2
   /dev/mapper/luks-swap                     swap      swap defaults                            0 0

/proc/partitions:

   major minor  #blocks  name

      8        0  175825944 sda
      8        1     204800 sda1
      8        2     512000 sda2
      8        3   74768384 sda3
     11        0    1048575 sr0
    253        0   32985088 dm-0
    253        1   32985088 dm-1
    253        2    8794112 dm-2
    253        3    8794112 dm-3
    253        4   32983040 dm-4

/proc/cmdline:

   BOOT_IMAGE=/vmlinuz-3.9.1-301.fc19.x86_64 root=/dev/mapper/ogopogo-root ro rhgb quiet

Re: Unable to boot with encrypted swap

[Michael Chapman]

On Mon, 13 May 2013, Joseph D. Wagner wrote:
> output from `blkid'

Sorry, I missed this in my previous email.

Output from blkid:

/dev/sda1: SEC_TYPE="msdos" UUID="1400-EDC0" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="f600b7a0-dc4c-4c62-8c32-29b753877072"
/dev/sda2: UUID="009ef157-66a8-42cb-869e-436244f39ca2" TYPE="ext4" PARTUUID="1da28ac9-df4f-42c2-8988-df0d5add947d"
/dev/sda3: UUID="vpNiek-T840-JH8E-phcM-BUgl-zNeX-70HDuW" TYPE="LVM2_member" PARTUUID="d1bd9da9-ee3c-45be-8960-921f1cb4dfec"
/dev/mapper/ogopogo-root: LABEL="root" UUID="c73aa277-ff32-42d0-a6f1-681694ba7b36" TYPE="ext4"
/dev/mapper/ogopogo-home: UUID="92b64e79-7b00-401a-ba83-e2fe5fa828f4" TYPE="crypto_LUKS"
/dev/mapper/luks-swap: UUID="e553888c-42f0-42ff-ac78-ab90b5562f41" TYPE="swap"
/dev/mapper/luks-home: LABEL="home" UUID="50c2abf5-84b0-4752-b527-e94b82b208f8" TYPE="ext4"

Thanks,
Michael

Re: Unable to boot with encrypted swap

[Joseph D. Wagner]

On 05/13/2013 08:22 PM, Michael Chapman wrote:
> On Mon, 13 May 2013, Joseph D. Wagner wrote:
>> I'm pretty sure this is needed for resume-from-suspend.  My money is 
>> on a configuration problem. I'd be happy to take a look.
>
> Wonderful! First, I should point out I've also got LVM:
>
>   LV   VG      Attr      LSize   Pool Origin Data%  Move Log Copy%  
> Convert
>   home ogopogo -wi-ao--- 31.46g
>   root ogopogo -wi-ao--- 31.46g
>   swap ogopogo -wi-ao---  8.39g
>
> So /etc/crypttab references these LVs:
>
>   luks-home /dev/ogopogo/home none
>   luks-swap /dev/ogopogo/swap /dev/urandom swap
>
> And /etc/fstab references the swap volume by device mapper name (can't 
> use UUID, of course, since that changes on each mkswap):
>
>   UUID=c73aa277-ff32-42d0-a6f1-681694ba7b36 /         ext4 
> defaults                            1 1
>   UUID=009ef157-66a8-42cb-869e-436244f39ca2 /boot     ext4 
> defaults                            1 2
>   UUID=1400-EDC0                            /boot/efi vfat 
> defaults,umask=0077,shortname=winnt 0 0
>   UUID=50c2abf5-84b0-4752-b527-e94b82b208f8 /home     ext4 
> defaults                            1 2
>   /dev/mapper/luks-swap                     swap      swap 
> defaults                            0 0
>
> /proc/partitions:
>
>   major minor  #blocks  name
>
>      8        0  175825944 sda
>      8        1     204800 sda1
>      8        2     512000 sda2
>      8        3   74768384 sda3
>     11        0    1048575 sr0
>    253        0   32985088 dm-0
>    253        1   32985088 dm-1
>    253        2    8794112 dm-2
>    253        3    8794112 dm-3
>    253        4   32983040 dm-4
>
> /proc/cmdline:
>
>   BOOT_IMAGE=/vmlinuz-3.9.1-301.fc19.x86_64 
> root=/dev/mapper/ogopogo-root ro rhgb quiet

/dev/ogopogo might not be available at that point in the boot process.  
I must admit that I don't fully understand the rules that go into udev.

I would try changing the second entry in your crypttab file to the UUID 
of the underlying device.  For example, my crypttab looks like this:

swap UUID=bfd3a748-bfcd-49dd-992e-d061847ef33d none
userdata1 UUID=c2119916-20e6-45f2-87d7-26012cefba59 none
userdata2 UUID=2e8d7701-7b52-4ebc-b62f-8bd2774457bf none

In my case, the UUID is the luks UUID, but I *believe* it can be the 
UUID of the underlying device.  See here for examples:
http://ubuntuforums.org/showthread.php?t=1080760

Be sure to regenerate your initramfs after changing your crypttab file.

If this doesn't fix it for you, then I'm out of ideas.  Sorry, but I'm 
not the most knowledgeable person on this list.

Joseph D. Wagner

Re: Unable to boot with encrypted swap

[Michael Chapman]

On Mon, 13 May 2013, Joseph D. Wagner wrote:
> /dev/ogopogo might not be available at that point in the boot process.  I 
> must admit that I don't fully understand the rules that go into udev.

Well, if /dev/ogopogo isn't available then neither is my root filesystem 
in the same volume group... and I've got bigger problems if that's the 
case. :-)

I'll fiddle around with this a bit more, but I'm pretty sure it's not just 
a simple configuration issue. Dracut simply doesn't think I need LUKS in 
the initramfs, since none of the devices it examines resolves to an fs 
type of "crypto_LUKS".

And now that I look at that blkid output again, I can see that 
/dev/ogopogo/swap (which should have that type) is completely missing. Why 
would that be the case?

To be honest, I don't particularly care if my swap is prepared in the 
initramfs or later on during boot, so I don't actually *need* LUKS in the 
initramfs. But if LUKS isn't there, I certainly don't want it the 
initramfs to wait around for a LUKS device that's never going to appear.

- Michael

Re: Unable to boot with encrypted swap

[Michael Chapman]

On Tue, 14 May 2013, Michael Chapman wrote:
> And now that I look at that blkid output again, I can see that 
> /dev/ogopogo/swap (which should have that type) is completely missing. Why 
> would that be the case?

OK, at least that wasn't difficult to find out. /dev/ogopogo/swap is a 
"plain" crypto device, not a LUKS device. That makes sense, because the 
whole point of encrypted swap is that it's ephemeral. It doesn't need the 
LUKS on-disk format.

So really, I think the right approach here would be for Dracut to detect 
that a swap device like this is ephemeral and that it doesn't need 
activation during initramfs... or if this isn't possible, perhaps an fstab 
option so that Dracut can skip it (I don't want to use "noauto", of 
course, since I still want the swap to be activated on boot).

- Michael

Re: Unable to boot with encrypted swap

[Colin Guthrie]

'Twas brillig, and Joseph D. Wagner at 14/05/13 04:06 did gyre and gimble:
> 
> On 05/13/2013 07:43 PM, Michael Chapman wrote:
>> Hello,
>>
>> I am using Fedora 19's dracut-027-45.git20130430.
>>
>> I have what is possibly an unusual configuration: my swap and /home
>> are encrypted, however my root filesystem is not. In /etc/crypttab I
>> have configured LUKS to take the swap volume's password from
>> /dev/urandom; it also has the "swap" flag so that it is mkswap'ed
>> during boot.
>>
>> The problem I am experiencing is that my initramfs hangs waiting for
>> the swap device to appear.
>>
>> As of commit dd5875499ece9dbc90e10eafd0073ee15d0c86a4, it looks like
>> Dracut adds discovered swap partitions to the list of devices to wait
>> for. However since my root filesystem itself is not encrypted, no
>> crypto components are actually installed into the initramfs. The end
>> result is that this volume never appears, and so the initramfs never
>> continues on.
>>
>> I am not sure of the background behind this commit. Is there a real
>> need to wait for swap during initramfs? Won't this just be picked up
>> later by systemd?
>>
>> Should Dracut just skip swap partitions that are encrypted? Or should
>> it detect the existence of an encrypted swap partition and treat it as
>> it would an encrypted root?
>>
>> For now, I've had to revert that commit on my system for it to be able
>> to boot.
>>
>> Regards,
>> Michael
>>
> 
> I'm pretty sure this is needed for resume-from-suspend.  My money is on
> a configuration problem.  I'd be happy to take a look.

Yeah it's almost certainly only for resume from suspend. Sadly this is
controlled by the resume= kernel command line and when the initrd is
generated it doesn't really know if it'll be needed or not.

I think you're right when you say that it should also include the
necessary bits to init swap and it should simply not do that at run time
if no resume= is detected. Sadly such a complex swap setup is likely not
on the radar as of now (will need a few patches).

What I can't understand is why it actually waits. It should timeout can
carry on (I remember writing patches to remove the wait_for_device job
but my memory is fuzzy) if the swap doesn't appear.

It would be interesting to get the /etc/fstab and /etc/cmdline.d/* files
from the initrd itself. Possibly the hooks folder too. That way we can
see exactly what it's waiting for. Assuming there is nothing sensitive
on it, perhaps you can just upload the initrd somewhere?

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

Re: Unable to boot with encrypted swap

[Michael Chapman]

On Thu, 16 May 2013, Colin Guthrie wrote:
> Yeah it's almost certainly only for resume from suspend. Sadly this is
> controlled by the resume= kernel command line and when the initrd is
> generated it doesn't really know if it'll be needed or not.

I think Dracut could use the the "swap" flag in crypttab to determine that 
a volume is definitely not needed on boot, since this tells 
systemd-cryptsetup that the swap needs to be recreated on boot. And since 
this is a "plain" dm-crypt encrypted device, the (randomly generated) 
encryption key isn't dropped from the kernel on hibernation -- so, I don't 
think the initrd needs to touch it upon resuming from hibernation either.

(Ensuring the hibernation image itself isn't on the encrypted swap is a 
different problem altogether, of course. I haven't looked into how this 
might be done yet.)

> It would be interesting to get the /etc/fstab and /etc/cmdline.d/* files
> from the initrd itself. Possibly the hooks folder too. That way we can
> see exactly what it's waiting for. Assuming there is nothing sensitive
> on it, perhaps you can just upload the initrd somewhere?

No problem. Here are the "bad" and "good" initramfs's respectively:

http://michael.beta.anchortrove.com/bad-initramfs-3.9.1-301.fc19.x86_64.img
http://michael.beta.anchortrove.com/good-initramfs-3.9.1-301.fc19.x86_64.img

Regards,
Michael

Re: Unable to boot with encrypted swap

[Harald Hoyer]

On 05/17/2013 03:38 AM, Michael Chapman wrote:
> On Thu, 16 May 2013, Colin Guthrie wrote:
>> Yeah it's almost certainly only for resume from suspend. Sadly this is
>> controlled by the resume= kernel command line and when the initrd is
>> generated it doesn't really know if it'll be needed or not.
> 
> I think Dracut could use the the "swap" flag in crypttab to determine that a
> volume is definitely not needed on boot, since this tells systemd-cryptsetup
> that the swap needs to be recreated on boot. And since this is a "plain"
> dm-crypt encrypted device, the (randomly generated) encryption key isn't dropped
> from the kernel on hibernation -- so, I don't think the initrd needs to touch it
> upon resuming from hibernation either.

fixed with commit bcfbddefe13d179d553da77cf66ada5e6fd804c8

Thanks for reporting!