You are not logged in.
Pages: 1
Hi there,
the man page for crypttab(5) says that one can specify a block device via UUID= followed by the UUID. I tried this and this does NOT work, at least not with the default init system. (Maybe it works with systemd, I didn't try.) It works fine using the UUID path, like /dev/disk/by-uuid/<my_uuid>. Since I just changed the prefix UUID= to the path without touching the UUID itself, it is not likely to be a typo or any other user error. Is there anything wrong or it is a known bug?
Another question:
I generate my encrypted swap partition via crypttab. It works fine, but since it is created on each boot, it gets a different UUID each time. Is it possible to assign a fixed UUID to it using crypttab? mkswap offers this option (-U …) but I need something to pass it over from crypttab.
Thanks!
Last edited by silentsnake (2012-08-11 15:28:20)
Offline
the man page for crypttab(5) says that one can specify a block device via UUID= followed by the UUID. I tried this and this does NOT work, at least not with the default init system. (Maybe it works with systemd, I didn't try.) It works fine using the UUID path, like /dev/disk/by-uuid/<my_uuid>. Since I just changed the prefix UUID= to the path without touching the UUID itself, it is not likely to be a typo or any other user error. Is there anything wrong or it is a known bug?
Looks like a bug to me (I see no code to deal with this in systemd, and initsrcipts does not deal with it either, so looks like a bug in the manpage). If you file a bug report I'll get back to it. Thanks for pointing it out!
I generate my encrypted swap partition via crypttab. It works fine, but since it is created on each boot, it gets a different UUID each time. Is it possible to assign a fixed UUID to it using crypttab? mkswap offers this option (-U …) but I need something to pass it over from crypttab.
This is not currently possible. Is there a reason not to use /dev/mapper/<the name of your device> ? If there is a reasonable usecase, I'd suggest submitting this upstream to systemd and I'll happily implement it for initsrcipts too (I don't want the two to diverge). Btw, there was a request for LABEL support in a similar way too, but no usecase was given so I didn't give it any more thought.
Offline
It doesn't make any sense to specify the device by UUID or LABEL -- these are attributes of a filesystem (i realize the crypto container itself has a UUID, but this is different and udev doesn't care about this). The filesystem doesn't exist until its unlocked... you're asking for support for a chicken/egg problem. The manpage just needs to be fixed.
Last edited by falconindy (2012-08-11 16:20:51)
Offline
...(i realize the crypto container itself has a UUID, but this is different and udev doesn't care about this).
Are you saying that the luks UUID shouldn't work either, because it does for me...!? I have an encrypted RAID device and I use UUID= with the UUID provided by "cryptsetup luksDump /dev/md0". As a btw, I actually have to use the UUID because simply using /dev/md0 doesn't work because of a bug in systemd/udev. It always tried to open /dev/md0 before the array was actually ready. Maybe this has been fixed by now, haven't tested it...
Offline
UUID work just fine for me too !
can you provide confs ?
https://balaskas.gr
Linux System Engineer - Registered Linux User #420129
Offline
Ah, looking at the wrong code after all... UUID is handled (but LABEL still won't be for the reasons i gave above).
@tomegun: we'll need to do the UUID -> /dev/disk/by-uuid conversion ourselves, since that's part of the cryptsetup-generator.c logic, not cryptsetup.c.
Offline
@falconindy: makes sense. i also looked at the wrong code.
Offline
Thanks a lot for your replies!
As for the swap partition you are right. There is actually no real reason to use a UUID instead of addressing the mapper device directly. I was just thinking that if I'm using UUIDs for everything else I could use it for this as well somehow.
The UUIDs for the crypto devices work perfectly well so far. I was just concerned about the information in the man page, that might confuse others as well. And since fstab allows the UUID=* syntax as well, it seemed right to me. But it is not an issue to use /dev/disk/by-uuid/# instead of UUID=#. If the encrypted partitions are unlocked and mapped to a device, they can be addressed by UUIDs itself, that were assigned while generating the file systems on them – so I don't get the point why this shouldn't work.
Last edited by silentsnake (2012-08-11 19:40:00)
Offline
The UUIDs for the crypto devices work perfectly well so far. I was just concerned about the information in the man page, that might confuse others as well. And since fstab allows the UUID=* syntax as well, it seemed right to me. But it is not an issue to use /dev/disk/by-uuid/# instead of UUID=#. If the encrypted partitions are unlocked and mapped to a device, they can be addressed by UUIDs itself, that were assigned while generating the file systems on them – so I don't get the point why this shouldn't work.
I merged Dave's patch, so this should work in the next initscripts release.
Offline
Pages: 1