Bug 1222087

Summary: Systemd generated two service file for the same encrypted partition, leads to boot failure
Product: [openSUSE] openSUSE Tumbleweed Reporter: Nicolas FORMICHELLA <stigpro>
Component: BasesystemAssignee: systemd maintainers <systemd-maintainers>
Status: RESOLVED UPSTREAM QA Contact: E-mail List <qa-bugs>
Severity: Critical    
Priority: P5 - None CC: antonio.feijoo, aplanas, aschnell, fbui, grasland, hvogel, lmb, stigpro
Version: Current   
Target Milestone: ---   
Hardware: x86-64   
OS: openSUSE Tumbleweed   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: Generated Services

Description Nicolas FORMICHELLA 2024-03-27 18:20:10 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.
Comment 1 Nicolas FORMICHELLA 2024-03-27 18:21:16 UTC 
Created attachment 873866 [details]
Generated Services
Comment 2 Antonio Feijoo 2024-04-01 13:52:01 UTC 
(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.
Comment 3 Franck Bui 2024-04-02 08:55:11 UTC 
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 ?
Comment 4 Nicolas FORMICHELLA 2024-04-15 11:59:23 UTC 
> @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
Comment 5 Franck Bui 2024-04-15 12:28:49 UTC 
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