Bug 468955 - Early boot naming of encrypted software raid devices conflicts with udev naming later in the boot process
Early boot naming of encrypted software raid devices conflicts with udev nami...
Product: Fedora
Classification: Fedora
Component: mkinitrd (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Jones
Fedora Extras Quality Assurance
Depends On:
Blocks: F10Blocker/F10FinalBlocker
  Show dependency treegraph
Reported: 2008-10-29 00:40 EDT by Bruno Wolff III
Modified: 2008-11-10 12:46 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-11-10 12:46:02 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Bruno Wolff III 2008-10-29 00:40:20 EDT
Description of problem:
Recently I had to modify my grub.conf and fstab files to use names based on luks ids rather than raid device names for root and swap, but not other encrypted raid devices. Even so I got a number of error messages while udev tried to mount the device names root and swap used to be know as. Eventually enough returns got through that and the system finished booting.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.Boot a system with encrypted raid devices
Actual results:
Boot fails until changes listed above are made, and then there are still warnings.

Expected results:
Clean boot

Additional info:
While using the luks ids seems like a good idea in the long run, this will impact some existing users and it seems a bit late in the process to make this change.
[bruno@cerberus ~]$ ls /dev/mapper
control                                    luks-md3
luks-9979e281-5710-476f-8536-e49846d53398  luks-md4
Comment 1 Ray Strode [halfline] 2008-10-29 09:53:59 EDT
Can you attach your /etc/crypttab?

Did you do an upgrade from F9, or have you been following rawhide for a while?
Comment 2 Bruno Wolff III 2008-10-29 10:47:36 EDT
I upgrade from F9 to rawhide in September (my memory is early September). Since around the beta I have been tracking koji (with dist-f10 until today when I switched to dist-f10-updates-candidate).
[root@cerberus bruno]# cat /etc/crypttab
luks-md2                /dev/md2        none
luks-md4                /dev/md4        none
luks-md3                /dev/md3        none
luks-md1                /dev/md1        none

So it looks like I needed to make another change as well to cut out the errors in the udev part of the boot. I'll switch things over (to luks ids) once I get to the office.
It seems odd that since luks ids are being used now, that those can't just be grabbed off the devices rather than using a file to provide a mapping.
Comment 3 Bruno Wolff III 2008-10-29 11:35:56 EDT
I forgot to add that when I updated I did a yum update. Probably September was early enough that it wouldn't matter for this issue, but I figured I should mention it since anaconda can do things during an upgrade that yum can't.
Comment 4 Bruno Wolff III 2008-10-29 14:17:30 EDT
As a follow up I am now getting a clean boot using the following:

Grub entry:
title Fedora (
        root (hd0,0)
        kernel /vmlinuz- ro root=/dev/mapper/luks-9cfcdd2a-d2ff-4c30-818c-344764c7cc21 elevator=deadline
        initrd /initrd-

luks-0459b95f-cc7b-4229-8f07-c3012582c726                /dev/md3        none
luks-b93e9fce-0ef0-4d55-a5c8-56deabaf2f61                /dev/md4        none

/etc/fstab:/dev/mapper/luks-9cfcdd2a-d2ff-4c30-818c-344764c7cc21 /                       ext3    defaults,noatime,barrier=1        1 1
/dev/mapper/luks-b93e9fce-0ef0-4d55-a5c8-56deabaf2f61    /home                   ext3    defaults,noatime,barrier=1        1 2
/dev/mapper/luks-0459b95f-cc7b-4229-8f07-c3012582c726    /play                   ext3    defaults,noatime,barrier=1        1 2
/dev/md0                /boot                   ext3    defaults,noatime,barrier=1        1 2
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0
/dev/mapper/luks-9979e281-5710-476f-8536-e49846d53398 swap                    swap    defaults        0 0
Comment 5 Bruno Wolff III 2008-10-29 14:59:50 EDT
I retested the rescue image from yesterday and it is now mounting everything without intervention. (I didn't mention in the bug report, but did on the lists, that the change also messed up rescue boots as while the devices were getting set up the names didn't match fstab so they weren't getting mounted.)
Comment 6 Bill Nottingham 2008-11-04 14:11:22 EST
What are the errors you get?
Comment 7 Bruno Wolff III 2008-11-04 15:27:05 EST
Now I don't get an errors since I manually update /etc/fstab and /etc/crypttab.
Without fstab being right the root file system was getting mounted, pretty much ending things for a normal boot. For rescue mode the devices were being set up but not mounted under /mnt/sysimage.
When I had partially fixed /etc/fstab but not /etc/crypttab I was getting a message about not being able to find the devices that used to correspond to root and swap in /etc/crypttab. That made sense with device names not matching any more.
My issue isn't really with the final result, but whether or not people are going to automatically go from the old way to the new way during an upgrade. And even if this is handled by anaconda there should be a warning with the yum upgrade instructions about this case.
Comment 8 Bill Nottingham 2008-11-04 15:35:35 EST
crypttab differences should be fixed with the latest initscripts (in that it ignores any devices set up elsewhere). As for upgrades... we may want to do something.
Comment 9 Bruno Wolff III 2008-11-10 12:46:02 EST
As discussed on Anaconda-devel-list, Bill checked that upgrades should work OK now.
I am not in a position to retest this now, but things appear to be all addressed so I am closing this ticket.

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