Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Setting up crypted swap partition sometimes fails (racey) #10179
systemd version the issue has been seen with
Note: While we are aware that this version is over 2 versions old, we have noticed that no relevant changes have been made to the cryptsetup generator, a key part of this bug report, since this release (except for keydev support).
Expected behaviour you didn't see
Unexpected behaviour you saw
In case the swap partition is marked as that it should not fail, it blocks the boot process.
Steps to reproduce the problem
For us, the issue seems to cause problems where the system is either relatively slow CPU-wise or IO-wise.
The cyptsetup-generate of systemd generates the following service file
# Automatically generated by systemd-cryptsetup-generator [Unit] Description=Cryptography Setup for %I Documentation=man:crypttab(5) man:systemd-cryptsetup-generator(8) man:systemd-cryptsetup@.service(8) SourcePath=/etc/crypttab DefaultDependencies=no Conflicts=umount.target IgnoreOnIsolate=true After=cryptsetup-pre.target Before=cryptsetup.target After=systemd-random-seed.service BindsTo=dev-disk-by\x2dpartlabel-SwapPartition.device After=dev-disk-by\x2dpartlabel-SwapPartition.device Before=umount.target Before=dev-mapper-%i.swap [Service] Type=oneshot RemainAfterExit=yes TimeoutSec=0 KeyringMode=shared ExecStart=/lib/systemd/systemd-cryptsetup attach 'crypt_swap' '/dev/disk/by-partlabel/SwapPartition' '/dev/urandom' 'swap,cipher=aes-xts-plain64' ExecStop=/lib/systemd/systemd-cryptsetup detach 'crypt_swap' ExecStartPost=/sbin/mkswap '/dev/mapper/crypt_swap'
What we think that the following is going on:
Below are the log files of the interaction of
While systemd often relies on proper notifications for other subsystems, such as LVM etc., in this case the setup is relatively bare and systemd itself calls the bare tool
Wow! This is entirely bogus. There is no reason to prohibit use of device without recognizable format.
Actually #10154 is related. If systemd had ability to run commands to bring up device, this workaround would not be needed. It would just wait for
Indeed, I had already added the following override file
# Run udevadm trigger after the mkswap call in the original generated # service [Service] ExecStartPost=/sbin/udevadm trigger /dev/mapper/%i
You seem to imply that the udev rules should not set
Removing it now will break swap and tmp processing by starting followup units too early. This requires some non-trivial redesign of the whole mess.
That seems to do the job. This is an issue experienced heavily on Pop!_OS, because we encrypt swap partitions by default. Most hardware is unaffected, but there are a few models that hit this error regularly. After applying this, the issue stopped entirely on the Galago Pro 2.
Now I need to find a way to apply this automatically for all installations.
On some systems, encrypted swap partitions occasionally fail to mount at boot, because systemd does not receive the triggers that it is waiting to hear. By running `udevadm trigger /dev/mapper/$cryptswap` immediately after creation, this issue is resolved. Frequency of occurrence varies from system to system, so some systems will never experience the issue, others will occasionally experience it, and then there's the worst case scenario that experiences it almost every boot. - Pop!_OS issue report: pop-os/pop#316 - Solution based on systemd#10179 (comment) - Closes systemd#10179
I'm experiencing this issue too. Fresh Archlinux installs, boot hangs while waiting for crypt-swap device. I experience this issue 100% boots on 1CPU/1Gb RAM Linode.
On fresh install with
Starting auto-generated swap unit manually works 100% of times.
Hope this helps!
Applying the workaround with