Bugzilla – Bug 1222087
Systemd generated two service file for the same encrypted partition, leads to boot failure
Last modified: 2024-04-15 12:28:49 UTC
User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:123.0) Gecko/20100101 Firefox/123.0 Build Identifier: After installing TW 20240326 with /home encrypted, the OS fails to boot and is thrown to emergency.target. Reproducible: Sometimes Steps to Reproduce: 1. Install Tumbleweed with /home (or other) partition encrypted 2. Try to boot Actual Results: It fails with device already in use error and drops you in emergency shell Expected Results: It should correctly After investigation I found that both `systemd-gpt-auto-generator` and `systemd-cryptsetup-generator` create a service for the same partition. The first, located in `/run/systemd/generator/systemd-cryptsetup@cr\x2dauto\x2d1.service` is generated from `systemd-cryptsetup-generator` and is bound by UUID to the partition. The second, located in `/run/systemd/generator.late/systemd-cryptsetup@home.service` is generated by `systemd-gpt-auto-generator` and is bound by disk sequence (/dev/disk/by-diskseq/2-part3) Both are trying to access the same disk, which inevitably ends up in one failing because of the device already used if one got it before the other. It actually fails to boot sometimes, but more than not, I assume that to be of a race condition due to the two services. Removing the secondary service resolves the issue.
Created attachment 873866 [details] Generated Services
(In reply to Nicolas FORMICHELLA from comment #0) > Steps to Reproduce: > 1. Install Tumbleweed with /home (or other) partition encrypted I think that in order to reproduce your issue, you also have to manually set the DPS Partition ID using YaST or gdisk, because the default just sets the "Linux" type, and the systemd-gpt-auto-generator does not recognize any partitions and does not do create any device unit at boot in this case. > After investigation I found that both `systemd-gpt-auto-generator` and > `systemd-cryptsetup-generator` create a service for the same partition. What is happening is documented in the systemd-gpt-auto-generator(8) man page: "The /home/, /srv/, /var/, /var/tmp/ and swap partitions may be encrypted in LUKS format. In this case, a device mapper device is set up under the names /dev/mapper/home, /dev/mapper/srv, /dev/mapper/var, /dev/mapper/tmp or /dev/mapper/swap. Note that this might create conflicts if the same partition is listed in /etc/crypttab with a different device mapper device name." If you have an encrypted partition with the DPS UUID, you need to disable the systemd-gpt-auto-generator by adding `systemd.gpt_auto=0` to the kernel command line, or remove its entry from /etc/crypttab.
It sounds to me that the gpt-auto generator shouldn't interfere and should refrain from generating a mount unit if one of the path is already handled by fstab like it does for /boot already. @Nicolas, just to be sure, can you firm that there's an entry for /home in /etc/fstab ?
> @Nicolas, just to be sure, can you firm that there's an entry for /home in /etc/fstab ? There is an entry in fstab for /home from install indeed
Then that looks like a generic issue. Can you please report your issue to upstream [1] by making sure to outline the fact that /home is supposed to be mounted by fstab in your case ? Thanks. [1] https://github.com/systemd/systemd/issues