[systemd-devel] [PATCH] cryptsetup-generator: avoid ordering cycle on swap
lennart at poettering.net
Tue Nov 1 15:53:22 PDT 2011
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
> 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
Lennart Poettering - Red Hat, Inc.
More information about the systemd-devel