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.
Created attachment 650128 [details] crypttab
Created attachment 650129 [details] fstab
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
Got the same on my laptop with fully up-to-date F18.
Hmm, what is the contents for /proc/cmdline when this happens?
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
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
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.
(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.
It still appears on my system after a reboot with all updates from today.
(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.
(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.
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.
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.
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.
(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
(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.
(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.
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.
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
I regenerate dracut and I still receive the error which prevents me from booting to the desktop.
Fixed in git.
systemd-201-2.fc18.1 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/systemd-201-2.fc18.1
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.
(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.
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).
Tested ok. Left positive karma.
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).
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).
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
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).
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.
Performed a clean install today. The issue is no longer present for me (systemd-201-2.fc18.6)