Bug 1224499 - dracut doesn't seem to consider /etc/crypttab
Summary: dracut doesn't seem to consider /etc/crypttab
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: dracut
Version: 22
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: dracut-maint-list
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-05-23 19:18 UTC by Jakub Dorňák
Modified: 2016-12-01 00:58 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1310520 (view as bug list)
Environment:
Last Closed: 2016-07-19 14:13:29 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Jakub Dorňák 2015-05-23 19:18:56 UTC
Description of problem:
My /etc/crypttab contains this lines:
luks-root /dev/md/root none
luks-home /dev/md/home none
luks-swap /dev/md/swap none

But the initramfs created by dracut creates the luks devices of "luks-UUID", which makes swap not work.

There is a workaround to change /dev/md/swap to UUID=xxx in /etc/fstab, but dracut should respect the crypttab anyway.


Version-Release number of selected component (if applicable):
dracut-041-10.fc22.1.x86_64


Additional info:
crypttab inside init ramdisk contains correct records:
# lsinitrd /boot/initramfs-4.0.4-300.fc22.x86_64.img -f /etc/crypttab
root /dev/md/root none
swap /dev/md/swap none

Comment 1 Harald Hoyer 2015-06-16 12:59:59 UTC
What is your kernel command line?

Comment 2 Jakub Dorňák 2015-06-29 13:04:37 UTC
I tried many different kernel command lines.
You tell me, which command line to use, if I want dracut to open my /dev/md127 as /dev/mapper/luks-root and /dev/md126 as /dev/mapper/luks-swap.

Comment 3 Harald Hoyer 2015-07-09 10:42:13 UTC
hmm..

# lsinitrd /boot/initramfs-4.0.4-300.fc22.x86_64.img -f /etc/crypttab
root /dev/md/root none
swap /dev/md/swap none

versus:
My /etc/crypttab contains this lines:
luks-root /dev/md/root none
luks-home /dev/md/home none
luks-swap /dev/md/swap none

so, there is "root" versus "luks-root" ??

Comment 4 Jakub Dorňák 2015-07-09 21:00:25 UTC
It is just a typo (result of trying so many ways).

Originally, I had in my crypttab:
root /dev/md/root none
swap /dev/md/swap none
home /dev/md/home none

and initrd contained:
root /dev/md/root none
swap /dev/md/swap none

(it is probably because dracut does not need home)

Later I changed it to:
luks-root /dev/md/root none
luks-swap /dev/md/swap none
luks-home /dev/md/home none

and initrd contained:
luks-root /dev/md/root none
luks-swap /dev/md/swap none

The point is, that dracut stores /etc/crypttab in initrd correctly, but it is being ignored during boot. And the question remains the same: how to make dracut use given crypttab to decrypt filesystems?

Comment 5 Harald Hoyer 2015-07-10 07:33:35 UTC
I will try to reproduce the issue the next days and debug to see what is going wrong.

Comment 6 Harald Hoyer 2015-07-16 08:27:09 UTC
Ok, I was able to boot, if I removed any "rd.luks.uuid=" options from the kernel command line, as long as /etc/crypttab in the real root and the initrd are in sync.

Comment 7 Harald Hoyer 2015-07-16 08:36:09 UTC
Also make sure /etc/mdadm.conf is correct and in sync.

Adding rd.md.uuid=... options to the kernel cmdline helps also.

# dracut --print-cmdline

gives you a hint, how those rd.md.uuid=... options should look like.

Also, I will fix dracut to better cope with the situation hopefully.

Comment 8 Fedora End Of Life 2016-07-19 14:13:29 UTC
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 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.


Note You need to log in before you can comment on or make changes to this bug.