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