[systemd-devel] [PATCH] cryptsetup-generator: avoid ordering cycle on swap

[Lennart Poettering]

On Mon, 17.10.11 17:28, Tom Gundersen (teg at jklm.no) wrote:

> 
> On Mon, Oct 17, 2011 at 4:24 PM, Lennart Poettering
> <lennart at poettering.net> wrote:
> > On Mon, 17.10.11 13:01, Tom Gundersen (teg at jklm.no) wrote:
> >
> >> Devices with random keys (swap), should not be ordered before local-fs.target,
> >> as this creates a cycle with systemd-load-random-seed.service (and also it
> >> does not make sense, a swap device is not a local-fs).
> >
> > Hmm, your patch makes some sense, but I believe we need to be careful
> > here: we probably shouldn't try to boot up the machine without swap
> > activated. Noawadays swap makes little sense unless you have a memory
> > constrained system, and on those system it's probably quite important to
> > activate swap before we begin with starting the full memory intensive
> > snafu.
> 
> My understanding was that since dev-mapper-swap.device would only
> appear after cryptsetup at swap.service has finished we have an implicit
> ordering:
> 
> cryptsetup at swap.service -> dev-mapper-swap.device ->
> dev-mapper-swap.swap -> swap.target

Indeed, you are right. 

> > Could you rework the patch to order the activation of the crypto volumes
> > before swap.target if they are to be sued for swapping? I think it would
> > make a lot of sense to have all fs luks before local-fs.target still,
> > and all swap luks before swap.target. I'll then merge the patch
> > right-away.
> 
> If I understand correctly, one can use a random key to create a
> temporary filesystem, so we cannot simply order all devices using a
> random key before swap.target. However, if we order the swap devices
> before swap.target and the tmp devices before local-fs.target, then
> the latter will still have an ordering cycle. Come to think of it,
> wouldn't any tmp device always end up in a cycle (following the same
> reasoning as above)?
> 
> dev-mapper-tmp.device -> tmp.mount -> local-fs.target ->
> systemd-random-seed-load.service -> cryptsetup at tmp.service

Yes, you are right. And I have no idea how we should fix that in a
pretty way. Thankfully not many folks are using this feature for now,
but it deserves to be fixed nonetheless.

For now I have applied your original patch and added an entry to the
TODO list.

Thanks!

Lennart

-- 
Lennart Poettering - Red Hat, Inc.