Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

systemd-cryptsetup: Booting with encrypted root partition fails instantly #6381

Closed
williamvds opened this Issue Jul 16, 2017 · 50 comments

Comments

@williamvds
Copy link

williamvds commented Jul 16, 2017

Submission type

Bug report

systemd version the issue has been seen with

systemd 234
+PAM -AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 -SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN default-hierarchy=hybrid

Used distribution

Arch Linux (testing repos)
uname -a:

Linux hostname 4.12.2-1-ARCH #1 SMP PREEMPT Sat Jul 15 20:18:04 UTC 2017 x86_64 GNU/Linux

Downstream issue

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

I should be prompted to enter a passphrase for the root partition, then boot should proceed as normal.

In case of bug report: Unexpected behaviour you saw

  • Failed to start Cryptography Setup for root...
  • Dependency failed for Encrypted Volumes, dev-mapper-root.device, Initrd Boot Device, FS check, /sysroot, Initrd Root Device, Reload Configuration from the Real Boot
  • Drops to emergency mode, but no recovery shell starts

Image

In case of bug report: Steps to reproduce the problem

  1. Have sysroot be a LUKS partition

  2. In bootloader use kernel options rw luks.name=<UUID of LUKS partition>=root root=/dev/mapper/root

  3. Build initramfs with hooks base systemd autodetect modconf block keyboard sd-vconsole sd-encrypt filesystems

  4. Reboot

Issue disappears after downgrading to last cached package - v233.

Workarounds:

  1. Fill in /etc/crypttab.initramfs with name, UUID, and none, rebuild initramfs, only specify root=/dev/mapper/name in kernel options

  2. Use luks.options=timeout=30s in kernel options. Values of 30s and 0s work as normal, but 0 causes the same behaviour.

@WhyNotHugo

This comment has been minimized.

Copy link

WhyNotHugo commented Jul 16, 2017

I've a similar setup, but use uuid to specify everything in the kernel arguments. Same result.

There a fair amount of people reporting this same issue on different places since yesterday (when this hit the arch repos).

@poettering

This comment has been minimized.

Copy link
Member

poettering commented Jul 17, 2017

Please boot with "debug" on the kernel cmdline, and provide the additional log output this generates here.

@poettering

This comment has been minimized.

Copy link
Member

poettering commented Jul 17, 2017

I figure this might have been caused by 0004f69. @keszybz?

@williamvds

This comment has been minimized.

Copy link
Author

williamvds commented Jul 17, 2017

Unfortunately I had to just take pictures because there was no way for me to actually save the text output.
I did my best to stitch it together.

Picture

@keszybz

This comment has been minimized.

Copy link
Member

keszybz commented Jul 17, 2017

https://bugzilla.redhat.com/show_bug.cgi?id=1462378 has been reopened too. It seems the patch does not work as intended.

@uzytkownik

This comment has been minimized.

Copy link

uzytkownik commented Jul 17, 2017

I have similar issue on Gentoo.

PS. "Do not submit bug reports about anything but the two most recently released systemd versions upstream!" - given that two most recent releases of systemd refuse to boot for various reasons maybe it is time to have some automatic boot tests of systemd? Last working for me release was 232.

@poettering

This comment has been minimized.

Copy link
Member

poettering commented Jul 17, 2017

given that two most recent releases of systemd refuse to boot for various reasons maybe it is time to have some automatic boot tests of systemd

We have a CI in place, but it doesn't do LUKS tests right now. (also, we don't test on gentoo. We'd love to, but this would mean the Gentoo folks would have run the CI, really, so that we can hook it up with systemd on github)

@keszybz

This comment has been minimized.

Copy link
Member

keszybz commented Jul 17, 2017

Should be fixed by #6387.

@keszybz keszybz closed this Jul 17, 2017

@uzytkownik

This comment has been minimized.

Copy link

uzytkownik commented Jul 18, 2017

I run into similar issue with MDRAID. It might need similar fix.

@uzytkownik

This comment has been minimized.

Copy link

uzytkownik commented Jul 19, 2017

Even after backporting fix I still have problems (sorry for poor quality of picture & dirt):

Image showing problem

@eworm-de

This comment has been minimized.

Copy link
Contributor

eworm-de commented Jul 19, 2017

Just to make sure: Given you successfully installed a fixed package... Did you rebuild the initramfs?

@uzytkownik

This comment has been minimized.

Copy link

uzytkownik commented Jul 19, 2017

Yes. Previously initramfs was using systemd 232, which worked.

@keszybz

This comment has been minimized.

Copy link
Member

keszybz commented Jul 19, 2017

(A side question: why do you think the UUID of your disk device matters to anyone? For example, mine has UUID=75751556-6e31-438b-99c9-d626330d9a1b. What attack scenario are you protecting against?)

So... even though you obscured the most important information (which devices become available, and what the errors are), it doesn't seem to be the same issue. You have "Found device" and right below that "Failed to start cryptography setup", and we can assume that it's the same device. This issue was about systemd not waiting for the device to show up.

@uzytkownik

This comment has been minimized.

Copy link

uzytkownik commented Jul 19, 2017

@keszybz Force of habit? Waiting until someone think it is good source of entropy for default backdoor password? I have one luks device anyway.

@WhyNotHugo

This comment has been minimized.

Copy link

WhyNotHugo commented Jul 23, 2017

Still an issue for me on 234.11. (oh, and I did rebuild the initramfs).

@keszybz

This comment has been minimized.

Copy link
Member

keszybz commented Jul 23, 2017

@hobarrera what is "234.11"?

@eworm-de

This comment has been minimized.

Copy link
Contributor

eworm-de commented Jul 23, 2017

@keszybz That is versioning from Arch Linux and stands for version 234 with 11 stable commits (your repository systemd-stable, branch v234-stable) on top.

@WhyNotHugo

This comment has been minimized.

Copy link

WhyNotHugo commented Jul 23, 2017

Oh, sorry about that, I was unaware that Arch's versioning scheme was different from upstream's.

@keszybz

This comment has been minimized.

Copy link
Member

keszybz commented Jul 23, 2017

OK, so can someone boot with systemd.debug-shell or rd.break and check what the logs and status for the systemd-cryptsetup@.service? In the screenshot it's saying that it failed with some return code, but the value is cut off.

@keszybz keszybz reopened this Jul 23, 2017

@jdkbx

This comment has been minimized.

Copy link
Contributor

jdkbx commented Jul 25, 2017

For me it just hangs. No Password prompt, no shell.
1s
2s
3s

@bearsh

This comment has been minimized.

Copy link

bearsh commented Jul 27, 2017

here some screenshot from my not booting computer:

  • dsc_0109

  • dsc_0110

  • dsc_0111

@jvoorhis

This comment has been minimized.

Copy link

jvoorhis commented Jul 27, 2017

Also hit this issue booting Arch Linux after upgrading to version 234.11. I worked around this by chrooting from a live environment, downgrading to 233.75-3, and rebuilding initramfs.

@MathijsPlanting

This comment has been minimized.

Copy link

MathijsPlanting commented Jul 27, 2017

Same problem, downgrading to version 233 made my system run again.

@keszybz

This comment has been minimized.

Copy link
Member

keszybz commented Jul 28, 2017

Anyone affected: please paste your /etc/crypttab, /etc/fstab, and /proc/cmdline (it's OK to obfuscate the UUIDs and hostnames — as long as it's done consistenly — I don't care ;)).

@MathijsPlanting

This comment has been minimized.

Copy link

MathijsPlanting commented Jul 28, 2017

/etc/crypttab
swap,cipher=aes-cbc-essiv:sha256,size=256

/etc/fstab

/dev/mapper/vg0-root	/         	ext4      	rw,noatime,data=ordered	0 1
/dev/mapper/vg0-home	/home     	ext4      	rw,noatime,data=ordered	0 2
/dev/sda1           	/boot     	vfat      	rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro	0 2

/proc/cmdline

initrd=\intel-ucode.img initrd=\initramfs-linux.img luks.uuid=d8df5d66-5411-4472-a237-e64d6cd76dcb	luks.name=d8df5d66-5411-4472-a237-e64d6cd76dcb=luks	root=/dev/mapper/vg0-root rw
@jdkbx

This comment has been minimized.

Copy link
Contributor

jdkbx commented Jul 28, 2017

cat /etc/crypttab
luks-50f35450-b86c-4a0b-bf86-eaa4ecd27b4a UUID=50f35450-b86c-4a0b-bf86-eaa4ecd27b4a none luks

cat /etc/fstab

UUID=9E61-F95B                              /boot/efi    vfat   defaults 1 2
UUID=88736d66-0ec9-4cae-a4ed-23397d77dfe5   /            xfs    noatime         0 1
UUID=baf43785-e4ee-465b-b7ae-678b783db1ac   none         swap   sw,discard,noatime  0 0
UUID=6e87c6c5-4f10-4e01-b584-a2a3ddca07d0   /home        xfs    noatime 0 1

cat /proc/cmdline
i915.modeset=1 pax_size_overflow_report_only threadirqs pcie_aspm=force resume=UUID=baf43785-e4ee-465b-b7ae-678b783db1ac acpi_backlight=video "acpi_osi=!Windows 2012" init=/lib/systemd/systemd

dracut is run with the following cmdline argument (--kernel-cmdline)
i915.modeset=1 pax_size_overflow_report_only threadirqs pcie_aspm=force resume=UUID=baf43785-e4ee-465b-b7ae-678b783db1ac acpi_backlight=video 'acpi_osi=!Windows 2012' rd.shell rd.lvm.lv=vgfhg2/home rd.lvm.lv=vgfhg2/swap init=/lib/systemd/systemd systemd.debug-shell rd.break

@jurriaan

This comment has been minimized.

Copy link

jurriaan commented Jul 28, 2017

Having the same problems after upgrading systemd on Arch

cat /proc/cmdline

BOOT_IMAGE=/vmlinuz-linux root=/dev/mapper/VolumeGroup-root rw rootflags=subvol=root-a luks.uuid=some-uuid resume=UUID=swap-uuid quiet

sudo cat /etc/crypttab | egrep -v '^(#|$)':

cat /etc/fstab | egrep -v '^(#|$)'

UUID=another-lvm2-uuid	/         	btrfs     	rw,relatime,ssd,space_cache,subvolid=257,subvol=/root-a,subvol=root-a	0 0
UUID=another-lvm2-uuid	/home     	btrfs     	rw,relatime,ssd,space_cache,subvolid=259,subvol=/home,subvol=home	0 0
UUID=some-uuid      	/boot     	vfat      	rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro	0 2
@WhyNotHugo

This comment has been minimized.

Copy link

WhyNotHugo commented Jul 28, 2017

[root@athena hugo]# cat /etc/crypttab 
[root@athena hugo]# cat /etc/fstab
UUID=4f728876-83e8-4af7-be24-56903b2c530c   swap  swap defaults
UUID=D32D-44FB                              /boot vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro     0 2
[root@athena hugo]# cat /proc/cmdline
initrd=\intel-ucode.img initrd=\initramfs-linux.img rd.luks.uuid=8374545b-2f4b-4092-a6dd-ddfba49adadc resume=UUID=4f728876-83e8-4af7-be24-56903b2c530c root=UUID=0d145bc4-d4d4-4be8-8227-fa73d8f47113 elevator=noop rw quiet acpi_osi="!Darwin"
[root@athena hugo]# 

My other system is almost the same, but has a single entry in crypttab (not the OS or anything critical though).

@zsilencer

This comment has been minimized.

Copy link

zsilencer commented Jul 29, 2017

Not only did I have to downgrade to 233, but had to set luks.options=timeout=30s as well. Crazy that a simple systemd update renders your entire system unbootable with no chance of recovery unless you have a LiveUSB sitting around.

@mason-larobina

This comment has been minimized.

Copy link

mason-larobina commented Jul 30, 2017

Removing the systemd hook in arch and using udev fixed this for me. It's faster too.

EDIT: For anybody else interested:

/etc/mkinitcpio.conf

# before
HOOKS="base systemd autodetect keyboard modconf block sd-encrypt filesystems fsck"
# after
HOOKS="base udev autodetect keyboard keymap modconf block encrypt filesystems fsck"

and kernel params:

# before
options luks.uuid=094... root=/dev/mapper/luks-094...
# after
options cryptdevice=UUID=094...:root root=/dev/mapper/root

andrewsoutar added a commit to andrewsoutar/systemd that referenced this issue Jul 30, 2017

Fix systemd#6381
0004f69 causes `arg_timeout` to be infinity instead of 0 when timeout=0. The
logic here now matches this change.

@andrewsoutar andrewsoutar referenced this issue Jul 30, 2017

Merged

Fix #6381 #6486

@andrewsoutar

This comment has been minimized.

Copy link
Contributor

andrewsoutar commented Jul 30, 2017

I was experiencing this too. The commit in the PR above fixed it for me.
For those of you on Arch, I'll have a PKGBUILD up soon that incorporates the changes so you can test.

@andrewsoutar

This comment has been minimized.

Copy link
Contributor

andrewsoutar commented Jul 30, 2017

OK, anyone on Arch can test https://github.com/andrewsoutar/pkgbuild-systemd-fix-6381 - it will build systemd with my patch (rebased onto systemd-stable). The build packages should be drop-in replacements for systemd, libsystemd, and systemd-sysvcompat.

andrewsoutar added a commit to andrewsoutar/systemd that referenced this issue Jul 30, 2017

Fix systemd#6381
0004f69 causes `arg_timeout` to be infinity instead of 0 when timeout=0. The
logic here now matches this change.

andrewsoutar added a commit to andrewsoutar/systemd that referenced this issue Jul 30, 2017

Fix systemd#6381
0004f69 causes `arg_timeout` to be infinity instead of 0 when timeout=0. The
logic here now matches this change.
@Leryan

This comment has been minimized.

Copy link

Leryan commented Jul 30, 2017

@andrewsoutar

Just fetched your repository, then makepkg -s && makepkg:

==> Starting prepare()...
Fetching origin
Fetching upstream
remote: Counting objects: 960, done.
remote: Compressing objects: 100% (335/335), done.
remote: Total 960 (delta 664), reused 862 (delta 568)
Receiving objects: 100% (960/960), 141.15 KiB | 0 bytes/s, done.
Resolving deltas: 100% (664/664), completed with 254 local objects.
From ../systemd
 * [new branch]          master     -> upstream/master
 * [new tag]             001        -> 001
 * [new tag]             002        -> 002
 * [new tag]             003        -> 003
 * [new tag]             004        -> 004
 * [new tag]             005        -> 005
 * [new tag]             006        -> 006
 * [new tag]             007        -> 007
 * [new tag]             008        -> 008
 * [new tag]             009        -> 009
 * [new tag]             010        -> 010
 * [new tag]             011        -> 011
 * [new tag]             012        -> 012
 * [new tag]             013        -> 013
 * [new tag]             014        -> 014
 * [new tag]             015        -> 015
 * [new tag]             016        -> 016
 * [new tag]             017        -> 017
 * [new tag]             018        -> 018
 * [new tag]             019        -> 019
 * [new tag]             020        -> 020
 * [new tag]             021        -> 021
 * [new tag]             022        -> 022
 * [new tag]             023        -> 023
 * [new tag]             024        -> 024
 * [new tag]             025        -> 025
 * [new tag]             026        -> 026
 * [new tag]             027        -> 027
 * [new tag]             028        -> 028
 * [new tag]             029        -> 029
 * [new tag]             030        -> 030
 * [new tag]             031        -> 031
 * [new tag]             032        -> 032
 * [new tag]             033        -> 033
 * [new tag]             034        -> 034
 * [new tag]             035        -> 035
 * [new tag]             036        -> 036
 * [new tag]             037        -> 037
 * [new tag]             038        -> 038
 * [new tag]             039        -> 039
 * [new tag]             040        -> 040
 * [new tag]             042        -> 042
 * [new tag]             043        -> 043
 * [new tag]             044        -> 044
 * [new tag]             045        -> 045
 * [new tag]             046        -> 046
 * [new tag]             047        -> 047
 * [new tag]             048        -> 048
 * [new tag]             049        -> 049
 * [new tag]             050        -> 050
 * [new tag]             051        -> 051
 * [new tag]             052        -> 052
 * [new tag]             053        -> 053
 * [new tag]             054        -> 054
 * [new tag]             055        -> 055
 * [new tag]             056        -> 056
 * [new tag]             057        -> 057
 * [new tag]             058        -> 058
 * [new tag]             059        -> 059
 * [new tag]             060        -> 060
 * [new tag]             061        -> 061
 * [new tag]             062        -> 062
 * [new tag]             064        -> 064
 * [new tag]             174        -> 174
 * [new tag]             175        -> 175
 * [new tag]             176        -> 176
 * [new tag]             177        -> 177
 * [new tag]             178        -> 178
 * [new tag]             179        -> 179
 * [new tag]             180        -> 180
 * [new tag]             181        -> 181
 * [new tag]             182        -> 182
==> ERROR: failed to validate tag v234

==> ERROR: A failure occurred in prepare().
    Aborting...
@andrewsoutar

This comment has been minimized.

Copy link
Contributor

andrewsoutar commented Jul 30, 2017

@Leryan Forgot to mention that. It's verifying based on the upstream systemd PGP-signed tags - you need to get the PGP key.
Try gpg --recv-key 63CDA1E5D3FC22B998D20DD6327F26951A015CC4 and see if it builds after that.

@Leryan

This comment has been minimized.

Copy link

Leryan commented Jul 30, 2017

==> Starting prepare()...
fatal: remote upstream already exists.
==> ERROR: A failure occurred in prepare().
    Aborting...

I removed source folders, changes nothing. I had to comment git add remote upstream in prepare, currently building.

@andrewsoutar

This comment has been minimized.

Copy link
Contributor

andrewsoutar commented Jul 30, 2017

Hmm... I got that a couple of times. If you were seeing the same thing that I was, a rm -rf src fixed it for me.

@Leryan

This comment has been minimized.

Copy link

Leryan commented Jul 30, 2017

I had no src folder, only systemd and systemd-stable. Are you sure the github repo is up to date?

Also i can't install built packages without a dependency problem:

pacman -U --force libsystemd-fix-6381-234.13-1-x86_64.pkg.tar systemd-fix-6381-234.13-1-x86_64.pkg.tar systemd-sysvcompat-fix-6381-234.13-1-x86_64.pkg.tar
error: target not found: libsystemd-fix-6381
error: target not found: systemd-fix-6381
loading packages...
resolving dependencies...
looking for conflicting packages...
:: libsystemd-fix-6381 and libsystemd are in conflict. Remove libsystemd? [y/N] y
:: systemd-fix-6381 and systemd are in conflict. Remove systemd? [y/N] y
:: systemd-sysvcompat-fix-6381 and systemd-sysvcompat are in conflict. Remove systemd-sysvcompat? [y/N] y
error: failed to prepare transaction (could not satisfy dependencies)
:: ceph: removing libsystemd breaks dependency 'libsystemd'
:: dbus: removing libsystemd breaks dependency 'libsystemd'
:: device-mapper: removing libsystemd breaks dependency 'libsystemd'
:: dhcpcd: removing libsystemd breaks dependency 'libsystemd'
:: docker: removing libsystemd breaks dependency 'libsystemd'
:: libatasmart: removing libsystemd breaks dependency 'libsystemd'
:: libgudev: removing libsystemd breaks dependency 'libsystemd'
:: libusb: removing libsystemd breaks dependency 'libsystemd'
:: lvm2: removing libsystemd breaks dependency 'libsystemd'
:: procps-ng: removing libsystemd breaks dependency 'libsystemd'
:: util-linux: removing libsystemd breaks dependency 'libsystemd'
error: no targets specified (use -h for help)

Edit: @andrewsoutar maybe you could open bugreports on the forked project and we continue there?

@andrewsoutar

This comment has been minimized.

Copy link
Contributor

andrewsoutar commented Jul 30, 2017

The src directory (on my machine, maybe your config is different) was generated by makepkg when it cloned the systemd source to build from. I guess the PKGBUILD got confused when it encountered the same src directory already checked out. (That's what happened for me, anyways.)
About the dependency problem... I got that too. There must be a cleaner way to work around it, but I haven't found it yet. For now, pacman -Udd *.pkg.tar should be enough to get the packages installed.
EDIT: spoke too soon. I just pushed a fix for the dependency issue. You can rebuild if you want, but it's not necessary - it's just a metadata fix.

@Leryan

This comment has been minimized.

Copy link

Leryan commented Jul 30, 2017

@andrewsoutar thanks. i installed it in a fresh install with luks as root and all… can't boot. Just to be sure:

/etc/default/grub:

GRUB_CMDLINE_LINUX="luks.uuid=2a1b7c1c-912f-4429-8887-58eb88cefd29 luks.name=UUID=2a1b7c1c-912f-4429-8887-58eb88cefd29=cryptroot luks.options=timeout=10s root=/dev/mapper/cryptroot"

/etc/mkinitcpio.conf

HOOKS="base systemd autodetect modconf keyboard sd-vconsole block sd-encrypt filesystems fsck"

I have the same problem as described in the initial post.

I guess for now i'll just stick with udev and encrypt hooks.

Edit: fixed luks.name parameter. systemd is askin for passphrase but dev-mapper-cryptroot.device goes to timeout.

@andrewsoutar

This comment has been minimized.

Copy link
Contributor

andrewsoutar commented Jul 30, 2017

@Leryan:
First, by "fixed luks.name parameter", I'm assuming you meant that you have removed the "UUID=" portion of it? (So it becomes luks.name=2a1b7c1c-912f-4429-8887-58eb88cefd29=cryptroot) If not, try that.
Second, if it's still not working, can you try to get an emergency shell and post the contents of /run/systemd/generator/systemd-cryptsetup@*.service?

@Leryan

This comment has been minimized.

Copy link

Leryan commented Jul 30, 2017

@andrewsoutar i added UUID= as arch documentation tell it, without systemd doesn't event ask for passphrase.

The emergency shell isn't launching, tips to do that? Maybe with systemd.debug-shell on kernel command line?

Edit

@andrewsoutar

This comment has been minimized.

Copy link
Contributor

andrewsoutar commented Jul 30, 2017

@Leryan Yes, I see that the Arch documentation is rather ambiguous. But from looking at the source, you should have something like luks.name=2a1b7c1c-912f-4429-8887-58eb88cefd29=cryptroot instead of luks.name=UUID=2a1b7c1c-912f-4429-8887-58eb88cefd29=cryptroot.

It doesn't look like mkinitcpio automatically includes the systemd debug-shell in the initramfs. Regardless, the emergency shell should be activated after mounting the rootfs fails. I've sometimes had issues with sulogin (which emergency.service uses) in the initramfs. Try dropping this into /etc/systemd/system/emergency.service.d/just-shell.conf:

[Service]
ExecStart=
ExecStart=/bin/sh

and add /etc/systemd/system/emergency.service.d/just-shell.conf to the FILES= line in /etc/mkinitcpio.conf, the rebuild your initramfs. (After you're finished debugging, remember to undo this - it's not particularly secure.)

@Leryan

This comment has been minimized.

Copy link

Leryan commented Jul 30, 2017

Ok so you were right and i think i tripped myself on something the first time i reported that you patch didn't worked. So, here are the infos from a booted system:

[root@archlinux ~]# cat /proc/cmdline 
BOOT_IMAGE=/vmlinuz-linux root=UUID=f0479b00-1552-46ae-be6c-2a52ece53b73 rw luks.uuid=2a1b7c1c-912f-4429-8887-58eb88cefd29 luks.name=2a1b7c1c-912f-4429-8887-58eb88cefd29=cryptroot luks.options=timeout=10s root=/dev/mapper/cryptroot quiet

[root@archlinux ~]# pacman -Qq |grep systemd
libsystemd-fix-6381
systemd-fix-6381
systemd-sysvcompat-fix-6381

It worked as expected. However it seems that luks.options=timeout=10s was ignored since i always had 90s before failure.

@andrewsoutar

This comment has been minimized.

Copy link
Contributor

andrewsoutar commented Jul 30, 2017

OK - first, about your timeout= option... do you mean that it still gave you 90s to enter your passphrase? If so, could you post your /run/systemd/generator/systemd-cryptsetup@*.service? (From the booted machine)
Second, can you try testing without setting a timeout= on the kernel command line? I think this particular bug will not manifest itself it you set one.

@Leryan

This comment has been minimized.

Copy link

Leryan commented Jul 30, 2017

Hm. In fact i also booted my real system with sd-encrypt.

I have a problem for the second encrypted disk using /etc/crypttab (uses an on-disk key), systemd drops me to an emergency shell.

Also if i don't type the passphrase in time the unit fails.

@andrewsoutar i'll try that immediately.

@Leryan

This comment has been minimized.

Copy link

Leryan commented Jul 30, 2017

Oh ok i missed that. Without luks.options=... it fails.

So, this is with the stock systemd:

And with your fix it's ok without luks.options, so i guess you nailed it.

[root@archlinux ~]# cat /proc/cmdline 
BOOT_IMAGE=/vmlinuz-linux root=UUID=f0479b00-1552-46ae-be6c-2a52ece53b73 rw luks.uuid=2a1b7c1c-912f-4429-8887-58eb88cefd29 luks.name=2a1b7c1c-912f-4429-8887-58eb88cefd29=cryptroot root=/dev/mapper/cryptroot quiet
[root@archlinux ~]# pacman -Qq |grep systemd
libsystemd-fix-6381
systemd-fix-6381
systemd-sysvcompat-fix-6381

Initrd regenerated before rebooting, and i checked twice. I guess you nailed it.

martinpitt added a commit that referenced this issue Jul 31, 2017

cryptsetup: fix infinite timeout (#6486)
0004f69 causes `arg_timeout` to be infinity instead of 0 when timeout=0. The
logic here now matches this change.

Fixes #6381
@bearsh

This comment has been minimized.

Copy link

bearsh commented Aug 1, 2017

I can confirm, #6486 fixed the issue, thx

andir added a commit to andir/systemd that referenced this issue Sep 7, 2017

cryptsetup: fix infinite timeout (systemd#6486)
0004f69 causes `arg_timeout` to be infinity instead of 0 when timeout=0. The
logic here now matches this change.

Fixes systemd#6381

andir added a commit to andir/systemd that referenced this issue Sep 22, 2017

cryptsetup: fix infinite timeout (systemd#6486)
0004f69 causes `arg_timeout` to be infinity instead of 0 when timeout=0. The
logic here now matches this change.

Fixes systemd#6381
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.