systemd-cryptsetup-generator: Not creating device 'swap' because it was not specified on the kernel command line.

[darkbasic]

Submission type

• Bug report
• Request for enhancement (RFE)

NOTE: Do not submit anything other than bug reports or RFEs via the issue tracker!

systemd version the issue has been seen with

232

NOTE: Do not submit bug reports about anything but the two most recently released systemd versions upstream!

Used distribution

Archlinux

In case of bug report: Expected behaviour you didn't see

I expected systemd-cryptsetup-generator to create device mapper for the following /etc/crypttab entry:
swap /dev/disk/by-id/ata-Samsung_SSD_850_EVO_M.2_1TB_S33ENX0HA02864K-part6 /dev/urandom swap,plain,cipher=aes-xts-plain64:sha256,size=256

In case of bug report: Unexpected behaviour you saw

[ 0.887494] systemd-cryptsetup-generator[68]: Not creating device 'cryptswap' because it was not specified on the kernel command line.

In case of bug report: Steps to reproduce the problem

Use Archlinux's sd-encrypt hook and put something in crypttab.

[falconindy]

But what is your kernel command line?

[poettering]

This happens if you specify a luks device explicitly on the kernel command line. Which looks like you are doing. Quoting the systemd-cryptsetup-generator(8) man page:

If /etc/crypttab exists, only those UUIDs specified on the kernel command line will be activated in the initrd or the real root.

Closing, since this appears to be a misunderstanding.

[darkbasic]

I specify a luks device explicitely on the command line because my whole rootfs is also encrypted:
luks.uuid=2f99853d-43c1-4ba5-bb82-5031fa8c6f79 luks.name=2f99853d-43c1-4ba5-bb82-5031fa8c6f79=cryptroot luks.options=2f99853d-43c1-4ba5-bb82-5031fa8c6f79=discard luks.key=/crypto_keyfile.bin

But my swap is in a completely different partition and I don't want (nor know how to) unlock it from the command line. It doesn't have a luks header because I don't want to get prompted for password a second time, so it is supposed to automatically generate a key from /dev/urandom (which probably doesn't even have enough entropy at such an early boot stage). So I really want to use crypttab for the swap, while still using the kernel command line for the rootfs. Isn't it possible?

[arvidjaar]

So I really want to use crypttab for the swap, while still using the kernel command line for the rootfs.

It sounds you want rd.luks.* options instead to restrict it to initrd only.

[darkbasic]

Thanks, I didn't know of the difference but it worked.

One more thing: isn't systemd supposed to automatically detect the swap partition and use it? I had to put /dev/mapper/swap in fstab.

[poettering]

@darkbasic yeah, but we don't support automatic discovery for LUKS encrypted swap yet...

[darkbasic]

Thanks, I like the final 'yet' :)

[greyltc]

@poettering, you wrote:

@darkbasic yeah, but we don't support automatic discovery for LUKS encrypted swap yet...

Can you guess when systemd might get this feature?

[poettering]

Can you guess when systemd might get this feature?

Well, somebody needs to do the work. Our TODO list is very much full, so might take a while. If you want it soon, prep a patch, or find somebody to do it for you, that's usually the best way to get something like this in quickest.

[mailinglists35]

I just ran into this on a minimal installation of fedora rawhide; spamming my experience here until I find time to search for duplicates and/or report this to fedora bugzilla bugtracker, as this is the first google result for "because it was not specified on the kernel command line"

booted a q35 uefi vm under kvm with Fedora-Workstation-netinst-x86_64-Rawhide-20181207.n.0.iso

because I wanted a custom partition alignment, I first manually setup partitioning and lvm volumes on the target disk outside the installer.

in the disk setup section of the installer, I chose the previously created boot, root and swap LVs, checked the encryption checkbox for swap and root, setup mount points, setup swap LV as swap.

installation finished, but after reboot the os does not prompt to enter luks password, showing the three dots clipping boot screen of fedora rawhide then eventually times out, dropping me to the init shell. journalctl shows the failure of systemd-cryptsetup-generator like op message.

further digging reveals that the fedora installer assigned in /boot/grub2/grubenv a totally different UUID for luks volumes than the UUID the volumes have been generated by the same installer in /etc/default/grub

the quick solution was to edit /boot/grub2/grubenv and replace the two UUIDs with the UUIDs of the luks volumes indicated by /etc/default/grub.

until I find time to file this in bugzilla, maybe this comment will help others.

cheers