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
Comments
|
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). |
|
Please boot with "debug" on the kernel cmdline, and provide the additional log output this generates here. |
|
Unfortunately I had to just take pictures because there was no way for me to actually save the text output. |
|
https://bugzilla.redhat.com/show_bug.cgi?id=1462378 has been reopened too. It seems the patch does not work as intended. |
|
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. |
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) |
|
Should be fixed by #6387. |
|
I run into similar issue with MDRAID. It might need similar fix. |
|
Just to make sure: Given you successfully installed a fixed package... Did you rebuild the initramfs? |
|
Yes. Previously initramfs was using systemd 232, which worked. |
|
(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. |
|
@keszybz Force of habit? Waiting until someone think it is good source of entropy for default backdoor password? I have one luks device anyway. |
|
Still an issue for me on 234.11. (oh, and I did rebuild the initramfs). |
|
@hobarrera what is "234.11"? |
|
@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. |
|
Oh, sorry about that, I was unaware that Arch's versioning scheme was different from upstream's. |
|
OK, so can someone boot with |
|
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. |
|
Same problem, downgrading to version 233 made my system run again. |
|
Anyone affected: please paste your |
|
/etc/crypttab /etc/fstab /proc/cmdline |
|
cat /etc/crypttab cat /etc/fstab cat /proc/cmdline dracut is run with the following cmdline argument (--kernel-cmdline) |
|
Having the same problems after upgrading systemd on Arch
|
My other system is almost the same, but has a single entry in |
|
Not only did I have to downgrade to 233, but had to set |
|
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 and kernel params: |
0004f69 causes `arg_timeout` to be infinity instead of 0 when timeout=0. The logic here now matches this change.
|
I was experiencing this too. The commit in the PR above fixed it for me. |
|
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. |
0004f69 causes `arg_timeout` to be infinity instead of 0 when timeout=0. The logic here now matches this change.
0004f69 causes `arg_timeout` to be infinity instead of 0 when timeout=0. The logic here now matches this change.
|
Just fetched your repository, then |
|
@leryan Forgot to mention that. It's verifying based on the upstream systemd PGP-signed tags - you need to get the PGP key. |
I removed source folders, changes nothing. I had to comment |
|
Hmm... I got that a couple of times. If you were seeing the same thing that I was, a |
|
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: Edit: @andrewsoutar maybe you could open bugreports on the forked project and we continue there? |
|
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.) |
|
@andrewsoutar thanks. i installed it in a fresh install with luks as root and all… can't boot. Just to be sure:
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. |
|
@leryan: |
|
@andrewsoutar i added The emergency shell isn't launching, tips to do that? Maybe with Edit |
|
@leryan Yes, I see that the Arch documentation is rather ambiguous. But from looking at the source, you should have something like 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 and add |
|
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: It worked as expected. However it seems that |
|
OK - first, about your |
|
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. |
|
Oh ok i missed that. Without So, this is with the stock systemd: And with your fix it's ok without luks.options, so i guess you nailed it. Initrd regenerated before rebooting, and i checked twice. I guess you nailed it. |
|
I can confirm, #6486 fixed the issue, thx |
0004f69 causes `arg_timeout` to be infinity instead of 0 when timeout=0. The logic here now matches this change. Fixes systemd#6381
0004f69 causes `arg_timeout` to be infinity instead of 0 when timeout=0. The logic here now matches this change. Fixes systemd#6381




Submission type
Bug report
systemd version the issue has been seen with
Used distribution
Arch Linux (testing repos)
uname -a: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
Image
In case of bug report: Steps to reproduce the problem
Have sysroot be a LUKS partition
In bootloader use kernel options
rw luks.name=<UUID of LUKS partition>=root root=/dev/mapper/rootBuild initramfs with hooks
base systemd autodetect modconf block keyboard sd-vconsole sd-encrypt filesystemsReboot
Issue disappears after downgrading to last cached package - v233.
Workarounds:
Fill in
/etc/crypttab.initramfswith name, UUID, andnone, rebuild initramfs, only specifyroot=/dev/mapper/namein kernel optionsUse
luks.options=timeout=30sin kernel options. Values of30sand0swork as normal, but0causes the same behaviour.The text was updated successfully, but these errors were encountered: