'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/ -- 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
