Ugly magic device name being enforced in Fedora 19

[Björn Persson]

I upgraded a laptop from F18 to F19 today. When I rebooted it after the
upgrade it failed to mount the root filesystem.

The disk is encrypted and /etc/crypttab looked like this:

rot1  UUID=cbb96d39-a39a-4f78-b39a-19c4053f3d7a none 
home1 UUID=38fc5950-726a-4ff5-a106-55c85ae47a0e none 

That worked OK in F18. SystemD wasn't entirely happy and never
considered the boot process finished, but the system was perfectly
usable. In F19 SystemD didn't seem to realize that the root filesystem
was available as /dev/mapper/rot1. It waited for a long time for a
device named /dev/mapper/luks-cbb96d39-a39a-4f78-b39a-19c4053f3d7a to
appear, and eventually dropped me in an emergency shell.

After rebooting with an F18 kernel I edited /etc/crypttab like this:

luks-cbb96d39-a39a-4f78-b39a-19c4053f3d7a  UUID=cbb96d39-a39a-4f78-b39a-19c4053f3d7a none 
home1 UUID=38fc5950-726a-4ff5-a106-55c85ae47a0e none 

Then I reinstalled the F19 kernel package to get the initramfs
regenerated. Now /dev/mapper/luks-cbb96d39-a39a-4f78-b39a-19c4053f3d7a
exists so SystemD is happy, but I'm unhappy because I have a long string
of gibberish instead of a human-readable device name. The entry
in /etc/crypttab looks quite pointless, mapping a UUID to the same UUID,
but it seems to be the only way that works.

Is it supposed to be like this? Should it be impossible to give the root
filesystem a human-readable name? And where did SystemD get the name
luks-cbb96d39-a39a-4f78-b39a-19c4053f3d7a from? I hadn't configured that
name anywhere until now when I was forced to.

Björn Persson

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20130808/25a81de5/attachment.sig>