Re: [solved securely now??] What is the correct way to set encrypted swap with systemd?
~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.
Grüße,
Sven.
--
Sigmentation fault. Core dumped.
Reply to: