You are not logged in.
I see that "PARTLABEL=" is supported in /etc/cryptab although it isn't documented. I am having trouble expressing a partlabel containing whitespace.
I have read here how "fstab" supports octal escape (\040) but these don't seem to work in /etc/crypttab.
Take a label "A B". This would have device symlink like
/dev/disk/by-partlabel/A\x20B
where "A\x20B" is the output of "systemd-escape A B"
Placing an entry in /etc/crypttab like
cryptvol PARTLABEL=A\040B none
results in device units like
dev-disk-by\x2dpartlabel-A\x5cx5c040B
I also tried "A\x20B" I get "dev-disk-by\x2dpartlabel-A\x5cx5cx20B"
Is it possible to use whitespace in PARTLABEL in /etc/crypttab?
Offline
Should be easier to change the partlabel with gdisk by pressing 'c'.
Offline
Should be easier to change the partlabel with gdisk by pressing 'c'.
That may be true but it doesn't really answer the question.
Offline
Have you tried escaping the spaces with backslashes or using quotes?
On the other and, what teateawhy says is true, changing the partlabel is probably easier _and_ more reliable. I would also use uuid instead of a name as I suppose the chance of ever finding a similar uuid is less than finding a similar name.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
Yes I have tried backslashes, quotes and everything else one would use to escape whitespace. I couldn't get any of them to work.
I agree that it might be _easier_ to change the label, or not use the label to work around the problem and this is what I have actually done. I am not using UIID here specifically because it's one of a number of removable devices that containin a partition with the same name (multiple copies of the same thing on multiple USB flash drives). In other words, I want to specifically cater for multiple devices with the same name (of course only one would ever be inserted at once). I could, I suppose, make them all have the same UUID but that isn't what UUIDs are about (they're meant to be unique).
But back to my original question, I really would like to know if I can use whitespace in the same way as I can in /etc/fstab. If this is not possible then I can report it upstream. My gut feeling is that it isn't possible but, as is often the case, some other Arch user might know different
Offline
I also wasn't sure how spaces can be escaped /etc/crypttab.initramfs. I googled and found this thread.
I investigated this issue and found relevant source code at:
- https://cgit.freedesktop.org/systemd/sy … c2abf3472b
- https://github.com/systemd/systemd/blob … til.c#L253
- https://github.com/systemd/systemd/blob … odes.c#L19
Basically, SystemD does escape any character that's not in [0-9A-Za-z], and converts them to \xXX. That's the only escape it performs.
However, the space character is also a delimiter in /etc/crypttab. This means my configuration PARTLABEL="Arch Linux" turns into \x22Arch.
There's really nothing we can do. We have to avoid using spaces in partition labels.
If anything, SystemD should fix this and improve the parsing of the /etc/crypttab file.
Offline
There's really nothing we can do. We have to avoid using spaces in partition labels.
If anything, SystemD should fix this and improve the parsing of the /etc/crypttab file.
but if you add escape sequences now, all the people who use escape sequences in their labels, have to escape their escape sequences…
… … …
How about you just don't use spaces or any kind of special character in there.
It only causes problems, in crypttab, in fstab, everywhere.
Offline
but if you add escape sequences now, all the people who use escape sequences in their labels, have to escape their escape sequences…
It would be quite bizzare if people had escape sequences in their labels. I'm just proposing to parse the file properly. Quoted values aren't being parsed properly. Even the devs have a comment at https://github.com/systemd/systemd/blob … til.c#L233 saying how bad the parsing is.
How about you just don't use spaces or any kind of special character in there.
That is the only choice currently. But this seems like a bizarre limitation. Imagine a programming language that's limited to ASCII only in this day and age.
If someone else raised the issue with spaces in the past, and I encountered it again, I'm sure many others have thought of it too.
It's possible that the devs could be all for backwards compatibility, but I think negative effects of fixing this issue is quite minimal.
Offline