~Stack~ <i.am.st...@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. 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/4bga2r0jj...@mids.svenhartge.de
