Le mardi 01 novembre 2011 à 23:53 +0100, Lennart Poettering a écrit : > On Mon, 17.10.11 17:28, Tom Gundersen (t...@jklm.no) wrote: > > > > > On Mon, Oct 17, 2011 at 4:24 PM, Lennart Poettering > > <lenn...@poettering.net> wrote: > > > On Mon, 17.10.11 13:01, Tom Gundersen (t...@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@swap.service has finished we have an implicit > > ordering: > > > > cryptsetup@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@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.
Unfortunately, I've just discovered this fix is needed but not sufficiant : - it works for encrypted swap - it doesn't work for encrypted tmp (using /dev/urandom as password), since /tmp is a needed dependency for local-fs.target, so, it causes a similar dependency loop, between local-fs.target, systemd-random-seed-load.service and cryptsetup.target and tmp.mount Except it is not seen as a loop by systemd (so, it is not broken by cycle breaker) and instead, a timeout is set on tmp.mount which fails after 180s. So far, the only solution I found is to "patch" on the fly systemd-random-seed-load.service, using a generator, to remove local-fs.target from After= list, when /dev/*random is specified in /etc/crypttab. Not very pretty, better suggestions welcome ;) -- Frederic Crozat <fcro...@suse.com> SUSE _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
