uc20 initrd is racy between the-tool and systemd-modules-load

Bug #1875968 reported by Ian Johnson
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
snapd
Fix Released
Critical
Ian Johnson

Bug Description

With the current state of the initrd, the-tool is currently not exiting if systemd-mount exits with non-zero status, which is problematic in and of itself, but this combined with the fact that mounts are not effectively "re-tried" because systemd-mount starts a transient unit with the args that the-tool uses means that if the mount initially fails the first time, we will never try again.

On top of all that, there is a race between the mounting /dev/disk/by-label/ubuntu-seed and systemd-modules-load.service because in order to mount /dev/disk/by-label/ubuntu-seed, we need to have the nls_iso8859_1 kernel module loaded (which it is by systemd-modules-load.service).

This race combined with the first point about the-tool never trying again means that when we hit this race we will fail to mount /dev/disk/by-label/ubuntu-seed, and then never effectively re-try it, infinitely looping in the initrd, and thus never proceeding or failing the-tool, and finally we can't get a debug shell in the initrd because the debug shell depends on the-tool exiting (or probably more accurately depends on something else failing which depends on the-tool).

The right thing to do here I think is to have the-tool depend on systemd-modules-load.service.

Tags: uc20
tags: added: core20
Revision history for this message
Ian Johnson (anonymouse67) wrote :
Changed in snapd:
assignee: nobody → Ian Johnson (anonymouse67)
importance: Undecided → Critical
status: New → Confirmed
Revision history for this message
Dimitri John Ledkov (xnox) wrote :

Longer term:

DefaultDependencies=no should probably be dropped, in favour of booting to basic.target, and having defaultdependencies satisfied, and then we shouldn't need to worry about such low-level things that normally happen by themselves.

similarly, i fear we might need want/after systemd-udev-trigger.service, as otherwise we might be inspecting unprobed disks for labels yet.

Revision history for this message
Ian Johnson (anonymouse67) wrote :

@xnox yes agreed, DefaultDependencies=no and Wants/After=systemd-udev-trigger.service makes sense for the-tool, but I'd like to test those changes out some before proposing, while the current MP just fixes this specific race and is a good short-term fix I think

tags: added: uc20
removed: core20
Changed in snapd:
status: Confirmed → Fix Released
milestone: none → 2.45
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.