On 03/28/2015 03:37 PM, Sven Hartge wrote: > ~Stack~ <i.am.stack@gmail.com> wrote: [snip] >> 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. Oh. Then yeah, that does explain some things...quite a bit actually. >> 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. Huh. More thoughts on that below. >> 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. OK. So that actually does explain a lot. In another post on this thread you asked where I got that UUID from. That question fits in well here so I am just going to dump it all here. :-) I just checked a number of my systems with blkid and the UUID's I am using are indeed the physical /dev/sdx# UUID's.. All of the bizarre behavior totally make sense in those layers you described if the LUKS swap UUID is auto generated and different every boot. On the older Wheezy systems I also show a UUID for the LUKS swap device but I am not using that one. I rebooted a host and it did change. I have finally joined two previously disconnected thoughts in my brain and learned something today! :-) But at the same time, I am still not sure as to why systemd.fsck has issues with the UUID of the partition but is OK with the /dev/disk/by-id/pointer. Is this the correct way of doing it? (EG: have I been doing it wrong this whole time by using the physical partitions UUID? Should I update my other not-yet-updated-to-Jessie hosts to use /dev/disk/by-id?) Thanks for clarifying this! I do appreciate it. ~Stack~
Attachment:
signature.asc
Description: OpenPGP digital signature