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 -- To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
