Bug 904332

crypttab processing and systemd-cryptsetup-generator is fully handled by systemd, cryptsetup provides just backend library, reassigning...

(In reply to comment #0)
> Obviously something went wrong with accessing my luks device. I see this on
> screen:
> 
> systemd-cryptsetup-generator[222]: Failed to create unit file ... File exists

This error message is a known issue of systemd-cryptsetup-generator, where an encrypted device is listed both in /etc/crypttab and on the kernel command line. It should be harmless though.

> However, I can boot the box if I add "enforcing=0" as a boot parameter

Could you please do that and then look for SELinux AVC denial messages in dmesg and /var/log/audit/audit.log? Attach them if you find any. Thanks.

Hello all. I'm getting the same error. I did a fresh install with F18 then updated and once I rebooted it got the error. I am new and not sure if I'm placing the enforcing=0 in the correct spot. If someone could please help me I would really appreciate it. I hit e when grub loads and then I've placed enforcing=0 in many different places and none seem to correct my issue. Thank you.

(In reply to comment #3)
> not sure if I'm placing the enforcing=0 in the correct spot.

The correct spot is on the kernel's command line, that is the line beginning with: linux /vmlinuz-...
Also make sure you don't exit grub's editor with Esc. Use Ctrl+X or F10.

(In reply to comment #4)
> (In reply to comment #3)
> > not sure if I'm placing the enforcing=0 in the correct spot.
> 
> The correct spot is on the kernel's command line, that is the line beginning
> with: linux /vmlinuz-...
> Also make sure you don't exit grub's editor with Esc. Use Ctrl+X or F10.

Thank you very much for your reply, just for simplicity where in the following code would you place that parameter, and is their anything that should be removed? I do appreciate your time!

linux   /vmlinuz-3.7.2-204.fc18.x86_64 root=/dev/mapper/luks-e65a0c99-d182-4860-9b7c-8c1848d81b92 cryptdevice=/dev/sda2:luks-e65a0c99-d182-4860-9b7c-8c1848d81b92 ro rd.md=0 rd.dm=0 rd.luks.uuid=luks-e65a0c99-d182-4860-9b7c-8c1848d81b92 KEYTABLE=de-latin1 quiet SYSFONT=latarcyrheb-sun16 rhgb rd.lvm=0 LANG=en_US.UTF-8

Does anyone have any other ideas. I have tried adding enforcing=0 at the beginning, middle, and end of the kernel line and I have even tried to edit the grub.cfg via /boot/efi/EFI/fedora. And I still get the same error. I'm lost any help would be greatly appreciated. Thank you.

(In reply to comment #5)
> Thank you very much for your reply, just for simplicity where in the
> following code would you place that parameter, and is their anything that
> should be removed? I do appreciate your time!
> 
> linux   /vmlinuz-3.7.2-204.fc18.x86_64 [...] LANG=en_US.UTF-8

Everything after "/vmlinuz-3.7.2-204.fc18.x86_64" are kernel parameters. I'd put it at the very end of the line.

(In reply to comment #6)
> Does anyone have any other ideas. I have tried adding enforcing=0 at the
> beginning, middle, and end of the kernel line and I have even tried to edit
> the grub.cfg via /boot/efi/EFI/fedora. And I still get the same error.

What do exactly do you mean by "the same error"? There is room for confusion here. If you mean just the message "systemd-cryptsetup-generator... Failed to create unit file ... File exists", that's expected. As I said in comment #2, the error message itself is harmless.
If on the other had you mean that you are unable to boot even with "enforcing=0", then you may be seeing a different bug than udo.rader.

I am actually not so sure anymore, that I am seeing a luks-setup issue at all.

I've added enforcing=0 to my grub.cfg file and were able to boot w/o any further problems for the past couple of days.

Yet, when I remove enforcing=0 now, I am still able to boot ...

Don't know, maybe I've hit some other intermittent problem that was fixed by some update ...

I will observe and test a little bit and see, if I can still reproduce the issue.

(In reply to comment #7)
> (In reply to comment #5)
> > Thank you very much for your reply, just for simplicity where in the
> > following code would you place that parameter, and is their anything that
> > should be removed? I do appreciate your time!
> > 
> > linux   /vmlinuz-3.7.2-204.fc18.x86_64 [...] LANG=en_US.UTF-8
> 
> Everything after "/vmlinuz-3.7.2-204.fc18.x86_64" are kernel parameters. I'd
> put it at the very end of the line.
> 
> (In reply to comment #6)
> > Does anyone have any other ideas. I have tried adding enforcing=0 at the
> > beginning, middle, and end of the kernel line and I have even tried to edit
> > the grub.cfg via /boot/efi/EFI/fedora. And I still get the same error.
> 
> What do exactly do you mean by "the same error"? There is room for confusion
> here. If you mean just the message "systemd-cryptsetup-generator... Failed
> to create unit file ... File exists", that's expected. As I said in comment
> #2, the error message itself is harmless.
> If on the other had you mean that you are unable to boot even with
> "enforcing=0", then you may be seeing a different bug than udo.rader.

Thank you for your response, Yes I receive the same message, and it freezes at that message and I am no longer able to boot into Xfce desktop.

The cryptsetup message won't stop you from booting, it's purely a cosmetic issue.

Weill close the bug now, as the issue went away per comment #8.

Feel free to reopen if this problem resurfaces again, in which case we probably shoudl reassign this to SELinux.

Easton, if you continue to have an issue with the boot, please file a separate bug.

yes, right, I forgot about this report and it can indeed be closed.

On my side, I've traced the problem down to plymouth. Sometimes the text field requesting the encryption key just does not appear, neither graphically nor in text console style.

Entering the encryption key even without seeing the password prompt boots up the system without problems.

Unfortunately the problem only shows randomly ...

I had now the same problem, freshly running on F-18 (previously F-17).
I use cryptsetup LUKS over mdadm, set it up by hand in the past.
SELinux I have fully disabled, not mentioned on kernel commandline.

I could not boot new yum-installed kernel with the message:
systemd-cryptsetup-generator[222]: Failed to create unit file ... File exists

The problem was that grub.cfg contained:
  linux /vmlinuz... root=/dev/mapper/host1root
which I had to replace by:
  linux /vmlinuz... root=UUID=393b7ea1-33fa-4d85-a05b-9ade4f2b8798

New grub.cfg from grub2-mkconfig creates it bootable (with root=UUID=...).

And really, after successful boot I see:
$ ls -l /dev/mapper/
crw------- 1 root root 10, 236 Apr  2  2013 control
lrwxrwxrwx 1 root root       7 Apr  2  2013 host1swap -> ../dm-0
lrwxrwxrwx 1 root root       7 Apr  2  2013 luks-28e0d1d7-c2b6-4c67-8b32-2efa2824011c -> ../dm-1

But I am very sure I had also "host1root" there before.

# cat /etc/crypttab 
host1root   UUID=28e0d1d7-c2b6-4c67-8b32-2efa2824011c none
host1swap   UUID=0fc6128b-b90f-477a-825a-e51da8919949 none
# cat /etc/fstab
/dev/mapper/host1root /     ext4 defaults 1 1
/dev/mapper/host1swap none  swap defaults 0 0
# tune2fs -l /dev/mapper/luks-28e0d1d7-c2b6-4c67-8b32-2efa2824011c
Filesystem UUID:          393b7ea1-33fa-4d85-a05b-9ade4f2b8798
# cryptsetup luksUUID /dev/md127 
28e0d1d7-c2b6-4c67-8b32-2efa2824011c

I believe the bug is systemd does not create the "host1root" alias.

Created attachment 730936 [details]
boot log in KVM

If you look at the log you may also see this device I did not mention above:
host1unsafe UUID=af00f48d-b836-4863-aa2b-7aea9f362f0d none

There is this suspicious warning but it boots:
systemd-cryptsetup-generator[315]: Failed to create unit file /run/systemd/generator/systemd-cryptsetup@luks\x2d28e0d1d7\x2dc2b6\x2d4c67\x2d8b32\x2d2efa2824011c.service: File exists

This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.