When e.g. tmp.mount is present in the initrd, and we serialize it, switch root,
and deserialize, the new systemd is confused because it thinks /tmp is mounted.
In general, it doesn't make sense to serialize anything that refers to paths in
the old root file system.
This fixes two errors for me:
1. tmp.mount was not mounted properly before local-fs.target. It would be
mounted as some point (I guess when we re-read /proc/self/mountinfo for some
other reason). In effect systemd-tmpfiles-setup.service would see one fs, and
some other units started later a different one. In particular gdm.service would
fail because the pre-created /tmp/.X11-unix with proper permissions would not
exist at time it was started.
2. # systemd[1]: proc-sys-fs-binfmt_misc.automount: Got hangup/error on autofs pipe from kernel. Likely our automount point has been unmounted by someone or something else?
# systemd[1]: proc-sys-fs-binfmt_misc.automount: Failed with result 'unmounted'.
# systemd[1]: Mounting proc-sys-fs-binfmt_misc.mount...
# systemd[1]: Mounted proc-sys-fs-binfmt_misc.mount.
# systemd[1]: Starting systemd-binfmt.service...
# systemd[1]: Finished systemd-binfmt.service.
# systemd[1]: proc-sys-fs-binfmt_misc.automount: Path /proc/sys/fs/binfmt_misc is already a mount point, refusing start.
# systemd[1]: Failed to set up automount proc-sys-fs-binfmt_misc.automount.
# systemd[1]: proc-sys-fs-binfmt_misc.automount: Path /proc/sys/fs/binfmt_misc is already a mount point, refusing start.
# systemd[1]: Failed to set up automount proc-sys-fs-binfmt_misc.automount.
# systemd[1]: proc-sys-fs-binfmt_misc.automount: Path /proc/sys/fs/binfmt_misc is already a mount point, refusing start.
# systemd[1]: Failed to set up automount proc-sys-fs-binfmt_misc.automount.
# systemd[1]: Stopping systemd-binfmt.service...
# systemd[1]: systemd-binfmt.service: Deactivated successfully.
# systemd[1]: Stopped systemd-binfmt.service.
I couldn't understand the error here, but in retrospect the first line is entirely
correct: "someone or something else" was the old systemd unmounting the old root.
The usual: bitfields make sense as a memory-saving measure when we have many
objects of a given type. When the object appears at most in a few copies, the
overhead of additional code to access bitfields is more than the savings.
unit_serialize_item() was dropped in d68c645bd3.
But "cannot be restored from other sources" is also not entirely true: for
example for mounts we may be able to figure out most state from /p/s/mountinfo.
So let's make the comment more oblique.
If the name of the old device didn#t work for us, we don't have to clean
anything up, since we know for sure that there won't be a device unit
for it. hence downgrade log message about it.
We want to propagate errors here, since we want to make dependent on the
success of creating the main device unit the creation of the auxiliary
device units. Thus if we suppress errors here we might end up in exotic
corner cases in a situation were we create the auxiliary ("following")
device units without the primary one.
This adds --visible=yes|no|asterisk which allow controlling the echo of
the password prompt in detail. The existing --echo switch is then made
an alias for --visible=yes (and a shortcut -e added for it too).
The value is set dynamically when sd_device_get_subsystem() is called
first time.
Fixes the following issue:
```
$ build/udevadm test /sys/class/block/dm-1
...
Assertion '_subsystem' failed at src/libsystemd/sd-device/sd-device.c:767, function device_set_subsystem(). Aborting.
Program received signal SIGABRT, Aborted.
```
I always found this a bit annoying.
With the patch:
$ SYSTEMD_LOG_LEVEL=debug build/udevadm test /sys/class/block/dm-1
...
Loaded timestamp for '/etc/systemd/network'.
Loaded timestamp for '/usr/lib/systemd/network'.
Parsed configuration file /usr/lib/systemd/network/99-default.link
Parsed configuration file /etc/systemd/network/10-eth0.link
Created link configuration context.
Loaded timestamp for '/etc/udev/rules.d'.
Loaded timestamp for '/usr/lib/udev/rules.d'.
...