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-repart very slow creation of partitions with Encrypt= #32760

Open
jmbaur opened this issue May 11, 2024 · 1 comment
Open

systemd-repart very slow creation of partitions with Encrypt= #32760

jmbaur opened this issue May 11, 2024 · 1 comment
Labels
bug 🐛 Programming errors, that need preferential fixing repart

Comments

@jmbaur
Copy link

jmbaur commented May 11, 2024

systemd version the issue has been seen with

255.4

Used distribution

NixOS

Linux kernel version used

6.8.9

CPU architectures issue was seen on

x86_64

Component

systemd-repart

Expected behaviour you didn't see

Repart takes a few seconds to partition and format the disk on first boot, then booting continues. I originally saw this issue on the mailing list (https://lists.freedesktop.org/archives/systemd-devel/2023-June/049165.html) and noticed an issue did not also exist on github.

Unexpected behaviour you saw

Repart doesn't finish and booting fails after the timeout is reached for the attempt to find the dm-crypt device for the root partition.

Steps to reproduce the problem

Create a repart config to be used in the initrd with a partition of type "root" with Encrypt=tpm2. I'm unsure if the issue is related to having tpm2 or if it is also present with key-file. I haven't been able to reproduce the issue in a VM, only on real hardware (happens on a laptop with 512GiB disk and also a desktop with 1TiB disk). I'll paste debug logs soon, as the process to get them is destructive without being able to reproduce in a VM.

Additional program output to the terminal or log subsystem illustrating the issue

https://gist.github.com/jmbaur/2a374649d73d9454fe2982773a02cdcc

@jmbaur jmbaur added the bug 🐛 Programming errors, that need preferential fixing label May 11, 2024
@poettering
Copy link
Member

Hmm, it's the mkfs.btrfs that just hangs. Weird. I'd assume that even on a 500G disk it should be snappy to finish...

No idea what mkfs.btrfs is doing there...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug 🐛 Programming errors, that need preferential fixing repart
Development

No branches or pull requests

2 participants