Bug 879431

Summary: cryptsetup-generator doesn't handle nicely if the same LUKS partition is specified on the kernel cmdline and in /etc/crypttab
Product: [Fedora] Fedora Reporter: Volker Sobek <reklov>
Component: systemdAssignee: systemd-maint
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 18CC: avi.kivity, bugzilla, Egonzalez9985, germano.massullo, hafflys, jantho, jmontleo, joe, joelhardi, johannbg, lnykryn, metherid, michael.monreal+bugs, mschmidt, msekleta, notting, plautrba, rdrijsen, redhat-bugzilla, rohan, systemd-maint, vpavlin
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: systemd-201-2.fc18.6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-05-15 22:58:07 EDT Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Attachments:
Description Flags
output of journalctl
none
crypttab
none
fstab
none
journalctl from a minimal installation
none
Current journalctl with same pc/setup that no longer has the issue (systemd-195-15.fc18.x86_64) none

Description Volker Sobek 2012-11-22 19:49:44 EST
Created attachment 650127 [details]
output of journalctl

Description of problem:
Installed Fedora-18-Beta-x86_64-DVD.iso (RC1) with virt-manager on a 8GB disk image with all defaults, using the encrypt my data option and providing an encryption password.

This error doesn't seem to have any bad effect, the system boots fine.
Comment 1 Volker Sobek 2012-11-22 19:50:40 EST
Created attachment 650128 [details]
crypttab
Comment 2 Volker Sobek 2012-11-22 19:51:40 EST
Created attachment 650129 [details]
fstab
Comment 3 Volker Sobek 2012-11-23 06:32:01 EST
Created attachment 650337 [details]
journalctl from a minimal installation

Happens with a minimal install as well, here's the journalctl for booting a minimal install with encrypted disk.

/etc/crypttab:
luks-0a67261c-7c49-4f06-b562-2dccdff09e2f UUID=0a67261c-7c49-4f06-b562-2dccdff09e2f none

/etc/fstab:
#
# /etc/fstab
# Created by anaconda on Fri Nov 23 06:11:16 2012
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
/dev/mapper/fedora-root /                       ext4    defaults,x-systemd.device-timeout=0 1 1
UUID=0fce503e-c99f-4e23-891b-bc257342fb1f /boot                   ext4    defaults        1 2
/dev/mapper/fedora-swap swap                    swap    defaults,x-systemd.device-timeout=0 0 0
Comment 4 Michael Monreal 2013-01-08 16:56:54 EST
Got the same on my laptop with fully up-to-date F18.
Comment 5 Lennart Poettering 2013-01-14 13:05:04 EST
Hmm, what is the contents for /proc/cmdline when this happens?
Comment 6 Michael Monreal 2013-01-14 13:16:10 EST
Mine says:

BOOT_IMAGE=/vmlinuz-3.7.2-201.fc18.x86_64 root=UUID=b52894de-d9e6-4a64-bbb7-3bbc8d15287c ro rd.md=0 rd.lvm=0 rd.dm=0 rd.luks.uuid=luks-4bb1297d-4ec9-4a90-a104-14dbb832ee7e rhgb quiet LANG=en_US.utf8

Anything wrong with that? luks-4bb1297d-4ec9-4a90-a104-14dbb832ee7e seems to be my swap patition. The encrypted home is not listed in cmdline
Comment 7 Volker Sobek 2013-01-14 14:10:01 EST
Created attachment 678393 [details]
Current journalctl with same pc/setup that no longer has the issue (systemd-195-15.fc18.x86_64)

It seems the issue is gone for me with (up-to-date f18).

$ cat /proc/cmdline 
BOOT_IMAGE=/vmlinuz-3.7.1-5.fc18.x86_64 root=/dev/mapper/vg_r61-lv_root ro rd.luks.uuid=luks-8a00e009-daea-4ee4-8354-ee990133237e rd.lvm.lv=vg_r61/lv_swap rd.md=0 rd.dm=0 rd.lvm.lv=vg_r61/lv_root rhgb quiet LANG=en_US.UTF-8 vga=normal
Comment 8 Volker Sobek 2013-01-14 14:19:47 EST
Sorry, I just saw I had a re-install in Oct 28, but I used the same disk, same luks + lvm. So, I *guess* it's fixed since that installation.
Comment 9 Volker Sobek 2013-01-14 14:24:21 EST
(In reply to comment #7)
> Created attachment 678393 [details]
> Current journalctl with same pc/setup that no longer has the issue
> (systemd-195-15.fc18.x86_64)
> 
> It seems the issue is gone for me with (up-to-date f18).
> 
> $ cat /proc/cmdline 
> BOOT_IMAGE=/vmlinuz-3.7.1-5.fc18.x86_64 root=/dev/mapper/vg_r61-lv_root ro
> rd.luks.uuid=luks-8a00e009-daea-4ee4-8354-ee990133237e
> rd.lvm.lv=vg_r61/lv_swap rd.md=0 rd.dm=0 rd.lvm.lv=vg_r61/lv_root rhgb quiet
> LANG=en_US.UTF-8 vga=normal

(In reply to comment #8)
> Sorry, I just saw I had a re-install in Oct 28, but I used the same disk,
> same luks + lvm. So, I *guess* it's fixed since that installation.

Forget about my last two comments please, I forgot that I filed the bug about a VM and not my actual pc! I don't have this VM around anymore, so I can't check, sorry.
Comment 10 Michael Monreal 2013-01-14 15:28:54 EST
It still appears on my system after a reboot with all updates from today.
Comment 11 Michal Schmidt 2013-01-15 05:29:33 EST
(In reply to comment #10)
> It still appears on my system after a reboot with all updates from today.

Do you have systemd-197-1.fc18.1 from updates-testing? The error message in this version should be a little bit more helpful because it says the actual file name.
Comment 12 Michael Monreal 2013-01-15 17:13:45 EST
(In reply to comment #11)
> Do you have systemd-197-1.fc18.1 from updates-testing? The error message in
> this version should be a little bit more helpful because it says the actual
> file name.

$ rpm -qa | grep systemd-197
systemd-197-1.fc18.1.x86_64

But after a reboot I still get the same message, no new information at all.
Comment 13 Lennart Poettering 2013-01-15 17:22:25 EST
So my educated guess is that this happens:

the same luks partition is listed in both cryptsetup and on the kernel cmdline. The  generator too hence tries to create unit files for it twice, the second attempt of course will fail, since the unit file already exists then. And that's the error you see. You can safely ignore it though, as the unit file *is* definitely created.

I guess we should make the cryptsetup tool a bit smarter, and teach it to ignore entries of cryptsetup that are also listed on the kernel cmdline.
Comment 14 Michael Monreal 2013-01-15 17:33:36 EST
I can confim that the partition I see listed in the kernel command line is also listed in /etc/crypttab
Should this not be the case on a correctly installed system? I have not added any of the lines myself.
Comment 15 Lennart Poettering 2013-01-15 17:46:55 EST
well, i think it's OK to pass it on the kernel cmdline, and have it in crypttab too. That has the benefit of making the initrd a bit more system independent.

so, with other words: systemd should be fixed here, dracut and anaconda are fine.
Comment 16 Lennart Poettering 2013-01-15 17:47:50 EST
(In reply to comment #13)
> So my educated guess is that this happens:
> 
> the same luks partition is listed in both cryptsetup and on the kernel
                                            ^^^^^crypttab

> I guess we should make the cryptsetup tool a bit smarter, and teach it to
> ignore entries of cryptsetup that are also listed on the kernel cmdline.
                    ^^^^^crypttab
Comment 17 Michal Schmidt 2013-01-16 06:29:05 EST
(In reply to comment #12)
> But after a reboot I still get the same message, no new information at all.

In your case the message is printed from the initramfs, so you will have to regenerate it with dracut for the new systemd version to take effect in there.
Comment 18 Michael Monreal 2013-01-16 14:06:13 EST
(In reply to comment #17)
> In your case the message is printed from the initramfs, so you will have to
> regenerate it with dracut for the new systemd version to take effect in
> there.

Ah, right... I can now confirm Lennart's theory, it printed the file of the partition that is listed twice.
Comment 19 Michael Zugelder 2013-01-17 15:39:30 EST
Where should the LUKS partition be specified? Because of bug #890533, I have it only in /etc/crypttab. Now it boots fine, but systemd tries to unlock the partition multiple times after it was already unlocked, broadcasting messages and opening password prompts in my terminals.
Comment 20 Easton 2013-01-31 20:27:35 EST
After trying to figure out the cause of the "failed to create unit file /run/systemd/generator/systemd-cryptsetup@luks...."I think this might be correct bug forum. I entered the following and received the same result :

rpm -qa | grep systemd-197

systemd-197-1.fc18.1.x86_64

Can someone please tell me the order of action to resolve this issue. I'm still really new at this and would appreciate any precise actions if available. Thank you in advance!

Easton
Comment 21 Easton 2013-02-05 20:16:34 EST
I regenerate dracut and I still receive the error which prevents me from booting to the desktop.
Comment 22 Lennart Poettering 2013-03-07 11:27:44 EST
Fixed in git.
Comment 23 Fedora Update System 2013-04-10 16:12:35 EDT
systemd-201-2.fc18.1 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/systemd-201-2.fc18.1
Comment 24 Joseph D. Wagner 2013-04-11 05:22:08 EDT
The systemd-cryptsetup message is gone, but now there's a different error.

systemd[1]: Default target could not be isolated, starting instead: Operation refused, unit may not be isolated.
Comment 25 Michal Schmidt 2013-04-11 07:44:05 EDT
(In reply to comment #24)
This message is harmless. In F19 dracut uses an isolatable default target, so it does not trigger this message, but in F18 it is different. I don't want to force a dracut update in F18. It is pointless to report this error on everyone's systems, so I will just downgrade it in F18 to debug level.
Comment 26 Fedora Update System 2013-04-11 19:25:34 EDT
Package systemd-201-2.fc18.2:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-201-2.fc18.2'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.2
then log in and leave karma (feedback).
Comment 27 Joseph D. Wagner 2013-04-13 04:49:21 EDT
Tested ok.  Left positive karma.
Comment 28 Fedora Update System 2013-04-15 19:59:56 EDT
Package systemd-201-2.fc18.4:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-201-2.fc18.4'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.3
then log in and leave karma (feedback).
Comment 29 Fedora Update System 2013-04-17 22:37:25 EDT
Package systemd-201-2.fc18.5:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-201-2.fc18.5'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.5
then log in and leave karma (feedback).
Comment 30 Fedora Update System 2013-05-07 09:39:38 EDT
systemd-201-2.fc18.6 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.6
Comment 31 Fedora Update System 2013-05-09 06:02:06 EDT
Package systemd-201-2.fc18.6:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-201-2.fc18.6'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.6
then log in and leave karma (feedback).
Comment 32 Fedora Update System 2013-05-15 22:58:07 EDT
systemd-201-2.fc18.6 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 33 Resa Drijsen 2013-05-17 14:45:53 EDT
Performed a clean install today. The issue is no longer present for me (systemd-201-2.fc18.6)