Bug 468955

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.