Description of problem: Systemd update to 37-6 on 29.10.2011 broke my encrypted partition automount. Problem probably is with systemd not asking the password anymore and failing due not being able to mount partition configured to be automatically mounted during boot. Version-Release number of selected component (if applicable): systemd-37-6.mga2 How reproducible: Always. Steps to Reproduce: 1. Create encrypted partition using cryptsetup 2. Configure /etc/crypttab to include correct config 3. Configure /etc/fstab to automount secure partition using "LABEL=" 4. Reboot
Blocks: (none) => 2120
Are you using dracut or mkinitrd?
CC: (none) => sander.lepik
mkinitrd
Please test with dracut as well as it will be preferred in the future.
Same thing with dracut and last nights' systemd update to 37-7.
Priority: Normal => release_blockerCC: (none) => dmorganecSeverity: normal => critical
Same thing, when doing a cauldron installation using the boot.iso. The encrypted device can't be mounted during the installation and it is not mounted at boot time.
CC: (none) => oliver.bgr
Any news on this one? Colin, I assigned it to you, please reassign to someone else, if it's not your bug.
CC: (none) => mageiaAssignee: bugsquad => dmorganec
Sorry no input yet. I've just not had time to look at this as I don't have this kind of setup to hand easily. I was hoping to setup various VMs etc, but just not gotten around to it yet. If you have the ability to debug it Oliver, then please do by all means and I can offer advice where applicable.
The boot process stops between last "Started Initialize storage subsystems (RAID, LVM, etc.)." message and "Starting LSB: Supports the direct execution of binary formats...." message. I does not give any password question nor does it indicate finding any encrypted partition. I do have correctly set /etc/crypttab as it has worked before.
Just to double check do you now use dracut as initrd? If not, please try it. I'm only suggesting this as it could related to how udev is used to identify encrypted partitions. This is a bit of a random suggestion as I've still not had time to look fully into this issue.
Dracut. I started with mkinitrd and moved to dracut. Same problem remains.
Strangely enough: When switching to the AMD graphics in drakx11, the system asks for the decryption password at boot and the partition get decrypted. When switching to the Sandy Bridge integrated graphics, the system does not ask for the password and thus the partition is not decrypted. The problem is, the X server doesn't run, when using the AMD graphics, but that's off topic here.
I wonder if this is KMS integration in plymouth. I had intended to update our plymouth to the git master version (similar to fedora) which may integrate better when asking for passwords. I guess the AMD graphics disable KMS. IIRC you can pass nokms=1 (tho' not sure if this works with dracut...) to disable kms even on intel so that could be a test if you can figure out the necessary foo to do it...
General ping for Alpha 3
Whiteboard: (none) => QA
CC: (none) => dan
can you test with systemd 39 ?
Tested with systemd 39 but problem is still there.
I suspect it's more of a plymouth issue over all. Can you remove the "splash=.." option from the kernel command line - does it ask you for a password then?
Created attachment 1444 [details] Booting failed if automounted encrypted partition in /etc/fstab
I tried with no "splash=..." but no luck. Attachment 1444 [details] contains image on where the boot ends up.
OK, so I guess /mnt/secure is the problem? As a workaround, you can add noauto to the fstab options, but can can you show me the current line in fstab such that I can create a similar setup here to reproduce. Cheers
Created attachment 1445 [details] Booting failed if automounted encrypted partition in /etc/fstab
# grep secure /etc/fstab LABEL=secure /mnt/secure ext4 discard,acl,noatime 0 0 # cat /etc/crypttab secure UUID="<blk_id_removed>" Could you please remove attachment 1444 [details]. I cannot do it. I made another image which is smaller, attachment 1445 [details].
No change without "splash=..." line. But the strange behaviour described in comment 11, is gone. The system does not ask for any password, no matter what kernel command line and graphics driver used.
Comment on attachment 1444 [details] Booting failed if automounted encrypted partition in /etc/fstab I can only obsolete it, not delete it.
Attachment 1444 is obsolete: 0 => 1
(In reply to comment #23) > > I can only obsolete it, not delete it. > Ok. Thanks anyway for obsoleting, hopefully someone will eventually delete it.
Blocks: (none) => 1292
what about this bug with systemd 40 ?
The problem is solved. Encrypted partition can be mounted during boot so from my point of view this bug can be closed.
Confirming, it's working again as it should be.
Closing as fixed then.
Status: NEW => RESOLVEDResolution: (none) => FIXED