On 03/28/2015 02:15 PM, David Wright wrote: > Quoting ~Stack~ (i.am.stack@gmail.com): [snip] >> $ 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. Maybe that was the problem with the UUID?? 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 ---- 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. Thanks for pointing that out David! ~Stack~
Attachment:
signature.asc
Description: OpenPGP digital signature