On Sat, Jun 4, 2011 at 12:27 AM, Jari Ruusu <jariruusu@xxxxxxxxxxxxxxxxxxxxx> wrote: > Frederick Gazerblezeebe wrote: >> Starting /home aborted because a dependency failed. >> systemd: job dev-loop3.device/start failed with result 'timeout' > [snip] >> Changing the fstab entry per your suggestion fails to add any swap: >> >> XXX[101]% swapon -s >> Filename Type Size Used Priority >> XXX[102]% swapoff -a >> XXX[103]% swapon -a >> swapon: /dev/loop5: read swap header failed: Invalid argument > > If you use non-changing encryption keys for swap, you have to "format" the > device as swap (this needs to be done only once): > > swapoff -a > mkswap /dev/loop5 > swapon -a > > If /dev/loop5 encryption keys are ever changed, then mkswap has to be run > again. (When swapon program sets up random swap encryption keys, it runs > mkswap automatically) > Doh, I knew this; must have been tired when I tried it.. So, initializing the swap correctly, the behavior remains the same: The boot process stalls (but does not abort, resuming after a minute or so delay) with the same error as before (Unit systemd-tmpfiles-setup.service entered failed state; Job dev-loop5.swap/start failed with result 'dependency'; Job dev-loop5.device/start failed with result 'timeout'.) >> Jun 3 13:17:49 mars systemd[1]: Unit systemd-tmpfiles-setup.service >> . >> Jun 3 13:19:02 mars systemd[1]: Job dev-loop5.device/start timed out. >> Jun 3 13:19:02 mars systemd[1]: Job dev-loop5.swap/start failed with >> result 'dependency'. >> Jun 3 13:19:02 mars systemd[1]: Job dev-loop5.device/start failed >> with result 'timeout'. > > That sounds like systemd is waiting for devices to be created. Does it help > if you configure udev to copy loop device nodes to /dev directory on boot? > > mknod -m 660 /lib/udev/devices/loop0 b 7 0 > mknod -m 660 /lib/udev/devices/loop1 b 7 1 > mknod -m 660 /lib/udev/devices/loop2 b 7 2 > mknod -m 660 /lib/udev/devices/loop3 b 7 3 > mknod -m 660 /lib/udev/devices/loop4 b 7 4 > mknod -m 660 /lib/udev/devices/loop5 b 7 5 > mknod -m 660 /lib/udev/devices/loop6 b 7 6 > mknod -m 660 /lib/udev/devices/loop7 b 7 7 > The loop nodes are already present /lib/udev, so that is not the source of the (mis)behavior. I had to create static links in /dev for loop2 and sda2, loop3 and sda3, and loop5 and sda5 (root, home and swap, respectively), in order to get them initialized and show up (via losetup -a) after booting. At the present time, root is the only partition whose loop device is successfully mounted during boot. The others (swap, home) have to be mounted to after booting has completed. Next I will post a summary of what I have done and where I am, including the behaviors we are discussing here, in reply to the original topic. ...and again, thanks for all the help! FG -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
