On 03/28/2015 06:45 PM, Sven Hartge wrote: > ~Stack~ <i.am.stack@gmail.com> wrote: > >> 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. > > If you use a static key and not /dev/urandom you can reuse the > swap-space that is already present. But that defeats the purpose of > encrypting the swap-space; you _want_ to forget the key and recreate the > encryption layer on every boot so that there is no chance of any > information leak from previous runs. > >> 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. > > UUID=... uses the UUID of the filesystem or swap-space on a partition, > _not_ the ID of the partition itself. That is totally different ID. > > Note that you have /dev/disk/by-id (which is the physical ID of the > device, partition, device map or md-RAID-set) while /dev/disk/by-uuid is > the UUID of whatever filesystem is on any device. > > You can only use the physical ones in /etc/crypttab. > > I guess by using the wrong (UU)ID the automatic dependency solvers of > systemd create a deadlock while trying to activate the correct units in > the correct order to do what you told it. This then turns into a fine > demonstration of computer sciences GIGO principle: Garbage In - Garbage Out. > > Of course, systemd could be a bit nicer and tell you if there is > something totally wrong, but maybe none of the authors has yet stumbled > upon this problem because they _know_ it does not work and hence never > tried it and never built any safe-guards into systemd to fail in a nicer > way. Thanks for the explanation. I now understand the results of a lot of my experiments today. It makes a lot more sense and I understand they garbage aspect of pointing to the swap file system (which changes) instead of the physical partition for swap. One more question if you don't mind: I understand why the encrypted partition UUID is going to change every time, but the physical partition UUID for my /dev/sda3 shouldn't change though. If they are the same systemd.fsck shouldn't have a problem with the physical partition UUID of /dev/sda3, but yet it does (at least for me). So what is the difference between the UUID pointing to /dev/sda3 and the /dev/disk/by-id pointing to /dev/sda3? Thanks Sven! You have been a great help in me understanding this better!
Attachment:
signature.asc
Description: OpenPGP digital signature