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): plymouth-0.6.0-0.2008.10.27.5.fc10.x86_64 How reproducible: 100% Steps to Reproduce: 1.Boot a system with encrypted raid devices 2. 3. 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 luks-9cfcdd2a-d2ff-4c30-818c-344764c7cc21
Can you attach your /etc/crypttab? Did you do an upgrade from F9, or have you been following rawhide for a while?
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.
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.
As a follow up I am now getting a clean boot using the following: Grub entry: title Fedora (2.6.27.4-65.fc10.x86_64) root (hd0,0) kernel /vmlinuz-2.6.27.4-65.fc10.x86_64 ro root=/dev/mapper/luks-9cfcdd2a-d2ff-4c30-818c-344764c7cc21 elevator=deadline initrd /initrd-2.6.27.4-65.fc10.x86_64.img /etc/crypttab: 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
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.)
What are the errors you get?
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.
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.
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.