Currently, we mount via file descriptors using /proc/self/fd. This
works, but it means that in /proc/mounts and various other files,
the source of the mount will be listed as /proc/self/fd/xxx. For other
software that parses these files, /proc/self/fd/xxx doesn't mean anything,
or worse, it means the completely wrong thing, as it will refer to one of
their own file descriptors instead.
Let's improve the situation by using /proc/pid/fd instead. This allows
processes parsing /proc/mounts to do the right thing more often than not.
One scenario where even this doesn't work if when containers are involved,
as with the pid namespace unshared, even /proc/pid/fd will mean the wrong
thing, but it's no worse than /proc/self/fd which will always means the wrong
thing.
This also doesn't work if we mount via file descriptor and then exit, as the pid will
be gone, but it does work as long as the process that did the mount is alive, which
makes it useful for systemd-dissect --with for example if the program we run in the
image wants to parse /proc/mounts.
This setting indicates which directories in the target partition
should be btrfs subvolumes. If set, we'll try to create these
directories as subvolumes.
Note that this only works when running as root without --offline,
as mkfs.btrfs does not support creating subvolumes.
The subvolumes set is a set of source inodes similar to how the
denylist hashmap contains source inodes as keys. It indicates
directories in the source tree that should become subvolumes in
the target tree.
When we don't know the sector size of the actual block device, because
we're building an image in a loopback file and no sector size was specified
explicitly, let's use 4096 as the sector size for filesystems, verity and
LUKS. This should be the most compatible option, since 4096 will also work
on devices with sector size 512 or 2048.
For the actual GPT partition table size, we stick with 512 as the default
value since UEFI firmware and the kernel will only try to read the GPT
partition table from the first LBA on the device and the sector size for
most devices is still 512. It can also be trivially modified when copying
the image to another device using --copy-from + --sector-size.
This reverts commit 1483892a42.
As the commit says, it does not solve the race. Moreover, it introduces
an regression #28410.
Also, checking by `path_is_mount_point()` may trigger automount. From
statx(2),
> AT_NO_AUTOMOUNT
> Don't automount the terminal ("basename") component of pathname
> if it is a directory that is an automount point.
Similar statements can be found in fstatat(2), which is used in the
fallback call for statx() in glibc, and name_to_handle_at(2), which is
used as the fallback when statx() failed.
So, `path_is_mount_point()` may _do_ trigger automount for parent paths.
That should be avoided especially on shutdown.
The original issue #25527 that is 'fixed' by the commit is not serious,
and should be fixed by making umount command handle path gracefully:
https://github.com/util-linux/util-linux/issues/2132Fixes#28410.
received
RFC4191 – Section 2.3 Route Information Option's Prf field:
If the Reserved (10) value is received, the Route Information Option MUST be ignored.
Salsa is the Debian git forge. In the package build environment test-path
always fails as we cannot set up cgroups and so the path unit fails to
start. Skip the test in that environment.
Unfortunately meson doesn't allow to skip individual tests by name.