~Stack~ <i.am.st...@gmail.com> wrote: > On 03/28/2015 02:15 PM, David Wright wrote: Quoting ~Stack~ > (i.am.st...@gmail.com):
>>> $ grep swap /etc/crypttab >>> # causes systemd to fsck swap >>> #sda3_crypt UUID=ef2496cd-ca4d-43aa-8c90-dba084029f6e /dev/urandom >>> cipher=aes-xts-plain64,size=256,swap >>> # systemd doesn't fsck swap >>> sda3_crypt /dev/sda3 /dev/urandom cipher=aes-xts-plain64,size=256,swap >> >> That cure looks retrograde to me because it throws away the uniqueness >> of UUIDs. What if /dev/sda3 changes, for whatever reason. >> >> A systemd 216 man page for crypttab says: >> "WARNING: Using the swap option will destroy the contents of the >> named partition during every boot, so make sure the underlying >> block device is specified correctly." >> >> Could you not try using a /dev/disk/by-foo/... entry instead and see >> if that works? (I don't recognise the particular one Sven uses.) > Ohhhh....Good catch! That completely blitzed my mind. I knew there was a > reason for the UUID's! :-) > In my /dev/disk/by-id/ directory I have both "dm-name-sda3_crypt" and > "dm-uuid-CRYPT-PLAIN-sda3_crypt" which point to "../../dm-1". I can > not use either of those in my /etc/crypttab because then I get the > systemd.fsck problem again. Those device nodes only appear _after_ /etc/crypttab has been parsed. By using them inside the crypttab, you create a chicken-and-egg problem. > Maybe that was the problem with the UUID?? I guess, you used the UUID of the swap inside the crypted device. But this UUID changes on every boot, so it is of no use. > However, I also have "ata-TOSHIBA_MK3259GSXP_42K5CE0TT-part3" and > "wwn-0x10001354922489237504x-part3" that point to "../../sda3". Both of > those will boot correctly and mount swap. Here is my update that works: > ---- > sda3_crypt /dev/disk/by-id/ata-TOSHIBA_MK3259GSXP_42K5CE0TT-part3 > /dev/urandom cipher=aes-xts-plain64,size=256,swap > ---- Of course. /etc/crypttab needs the device on which to create the crypted device mapping. > So my guess, if I understand this correctly, is that if I use the > encrypted container, systemd.fsck freaks out, tries to and fails to > mount, then just ignores swap altogether. However, if I tell LUKS to > encrypt the actual partition, that somehow means systemd.fsck is happy > with it. So bizarre. No, not bizzare at all, quite logic if one thinks about what layer is put on top of what other layer. You have /dev/disk/by-id/ata-TOSHIBA_MK3259GSXP_42K5CE0TT-part3 at the bottom. On top of that, you get /dev/mapper/sda3_crypt. And on top of that you get your swap-space. Grüße, Sven. -- Sigmentation fault. Core dumped. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/3bg9o3djj...@mids.svenhartge.de
