http://bugzilla.suse.com/show_bug.cgi?id=980324 http://bugzilla.suse.com/show_bug.cgi?id=980324#c9 Andrei Borzenkov <arvidjaar@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(arvidjaar@gmail.c | |om) | --- Comment #9 from Andrei Borzenkov <arvidjaar@gmail.com> --- (In reply to Franck Bui from comment #8)

Your fix looks to work but there's also the "--no-block" option which is used in initrd-cleanup.service when isolating initrd-switch-root.target that might look suspicious since it prevents systemd to wait for the isolation of the target to fully complete before starting initrd-switch-root.service.

Oh, no, that's not a problem. My fix makes sure that jobs in transaction that is initiated are ordered correctly. It does not rely on waiting for systemctl result. It works because of this rule: --><-- If one unit with an ordering dependency on another unit is shut down while the latter is started up, the shut down is ordered before the start-up regardless of whether the ordering dependency is actually of type After= or Before=. --><-- My fix orders initrd-switch-root.target After initrd.target; "systemctl isolate initrd-switch-root.target" builds transaction that includes jobs "stop initrd.target" and "start initrd-switch-root.target"; according to the above rule start job will wait for stop job to finish. And "stop initrd.target" will wait for everything else to finish according to normal ordering. Which unfortunately means that if there are units that are not ordered before initrd.target on startup (or even worse, ordered after initrd.target for whatever reason) they still race with initrd-switch-root.service. I do not see any easy way to fix it. This is basically just another case of common request "how to write a unit that is started/stopped after all other units".

I think we should discuss this with upstream. Maybe you should submit your fix through a pull-request to start a discussion on this or open an issue via github.

Sure. I just wanted to get more confidence that it actually fixes problem, as it is race condition, so may appear to work initially. @Per, if you have not observed this problem so far, could you try to revert this change and verify that you get the problem back? -- You are receiving this mail because: You are on the CC list for the bug.