[systemd-devel] /cdrom mounted from initrd is stopped on boot, possibly confused about device-bound

[Lennart Poettering]

On Mi, 09.10.19 14:28, Dimitri John Ledkov (xnox at ubuntu.com) wrote:

> Ubuntu installer images use initrd, which has udevd but no systemd.
>
> It mounts /dev/sr0 as /root/cdrom, then pivots to /root, meaning
> /root/cdrom becomes just /cdrom and exec systemd as pid 1.
>
> At this point cdrom.mount is stopped as it's bound to an inactive
> dev-sr0.device. Then sometime later dev-sr0.device becomes active, but
> nothing remounts /cdrom back in.
>
> My question is why on startup, when processing cdrom.mount it
> determines that dev-sr0 is inactive, when clearly it's fully
> operational (it contains media, media is locked, and is mounted, and
> is serving content).
>
> I notice that SYSTEMD_MOUNT_DEVICE_BOUND is set to 1 on the udev
> device, and it seems impossible to undo via mount unit.

60-cdrom_id.rules sets that.
>
> I also wonder why, initially, /dev/sr0 is inactive, but later becomes
> active - as in what causes it to become active, and what is missing in
> the initrd.

When PID 1 initializes and udev is not running no device is considered
to be around. The devices only appear when they are triggered by
systemd-udevd-trigger.service for the first time.

> Things appear to work if I specify in the 60-cdrom_id.rules
> SYSTEMD_READY=1, then on boot there are no working messages that
> cdrom.mount is bound to an inactive device.
>
> Shouldn't 60-cdrom_id.rules set SYSTEMD_READY=1 if after importing
> cdrom_id variables ID_CROM_MEDIA is not-empty? Such that
> dev-sr0.device initial state is correct, if one booted with cdrom
> media in place.

SYSTEMD_READY=1 doesn't do anything, it's SYSTEMD_READY=0 that has an
effect. i.e. a device that lacks SYSTEMD_READY= at all is equivalent
to SYSTEMD_READY=1. The only reason for setting the property is to
turn the readiness off, it's by default considered ready if the
"systemd" udev tag is set.

Lennart

--
Lennart Poettering, Berlin