Can you provide a link to the patch you want to get included? Do you know what it's upstream status it?

You can also use /dev/disk/by-{id,label,path,uuid}

I can use pam_mount which runs cryptsetup using a /dev/disk/by-id device specification. I also doupt, that it is really useful to add the support for UUID/labels to every command that operates on disk devices, because /dev/disk already makes it possible for every such command.

Uh, I just noticed that only a minor fraction of all uuids of filesystems/devices that appear running blkid are shown in /dev/disk/by-uuid. It seems that devices from lvm are not shown there, which is probably something that should be fixed.
I only checked for Fedora 8 yet, maybe it is fixed in newer releases.

Yes Ubuntu uses the
 /dev/disk/by-{id,label,path,uuid}
format.

I will adjust the bug title.

(In reply to comment #3)
> Yes Ubuntu uses the
>  /dev/disk/by-{id,label,path,uuid}
> format.
> 
> I will adjust the bug title.

Can you please explain where you want to have cryptsetup use the /dev/disk/by-* format? Do you maybe want the installer to create such entries in /etc/crypttab? Please explain in detail what you did, what happened and what you expected.

You want me to explain the move away from changeable disk device names to unique static labels or disk identifiers?

(In reply to comment #5)
> You want me to explain the move away from changeable disk device names to
> unique static labels or disk identifiers?

No, I want you to explain where to want to have cryptsetup use the /dev/disk/by-* format and hat you did, what happened and what
you expected, that made you create this bug report. For me this works:

cryptsetup luksOpen /dev/disk/by-uuid/28aa012c-8f04-4e00-9d01-4e2a7dd1ff6d /mnt/foo/

Therefore your bug report does not make much sense to me.

> Do you maybe want the installer to create such entries in /etc/crypttab

Yes I do, sorry missed this.

(In reply to comment #7)
> > Do you maybe want the installer to create such entries in /etc/crypttab
> 
> Yes I do, sorry missed this.

Ok, then this needs to be assigned to anaconda, because that's the installer. Here in summary for the anaconda maintainers:

Anaconda should use /dev/disk/by-id/[1] entries for /etc/crypttab by default for encrypted partitions instead of using direct device names like /dev/sda1, because these can change arbitrarily.


[1] Afaics is /dev/disk/by-id always unique as long as hard disk manufacturers do not asign serial numbers twice to hard disks, whereas labels or uuids have a much higher probability to collide.

We have been using UUIDs in crypttab since anaconda-11.4.1.34-1, which I believe was included in the F10-Beta.

(In reply to comment #9)
> We have been using UUIDs in crypttab since anaconda-11.4.1.34-1, which I
> believe was included in the F10-Beta.

I just installed a F10 Snap3 i386 and these are my findings:

1) Using UUIDs instead of device ids is probably a better choice wrt. usability, because one can then easier dd a disk image to another harddisk and boot from it.

2) For encrypted root fs, /etc/crypttab is not the problem (which contains a UUID for the lvm containing itself). I am not even sure, whether the /etc/crypttab make s sense here ;-)

3) The initramfs uses a hardcoded /dev/sda2 instead of a UUID, which afaics renders the UUID approach useless currently. It is probably a problem that udev is not included in the initramfs and therefore the /dev/disk/by-* devices do not currently exist.
Easy test command:

lsinitrd /boot/initrd* | grep cryptsetup


4) I should have probably also setup a seperate luks partitions to see how it is generated and included in the FS.


Currently I would conclude that currently mkinitrd should be improved to use UUIDs somehow (which may either require a patch for cryptsetup or some udev in the initramfs) to fix this issue that I described in 3) and is maybe also the problem the reported noticed.

This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

I believe that there is nothing to fix in anaconda regarding this issue. There was also a new bug reported about this with obviously less comments, which is therefore more clear, I close this bug report.

*** This bug has been marked as a duplicate of bug 474710 ***