| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Fixes: #27260
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
option
If we discover the root or /usr/ fs via roothash=/usrhash= we know the
file system mounted on it will be read-only, since Verity volumes are by
definition immutable. Hence, let's imply the "ro" mount option for them.
This way the "kernel: /dev/mapper/usr: Can't open blockdev" boot-time
log message goes away, reported here:
https://github.com/systemd/systemd/issues/27682
(I do wonder though why erofs even tries to open the block device as
writable, that sounds utterly pointless for a file system that carries
the fact it is read-only even in the name...)
|
|
|
|
| |
Follow-up to 9445623363.
|
|
|
|
|
|
|
|
| |
Now, the following kernel command line options are supported:
systemd.mount-extra=what:where:fstype:options
systemd.swap-extra=what:options
Closes #27260.
|
|
|
|
| |
Previously, some errors might be ignored.
|
| |
|
|
|
|
| |
No functional change, preparation for later commits.
|
|
|
|
| |
As 'where' field will be ignored for swap entry.
|
|
|
|
|
| |
No functional changes, just refactoring and preparation for later
commits.
|
| |
|
| |
|
|
|
|
| |
Disable verity logic if systemd.verity= switch is disabled.
|
| |
|
|
|
|
|
|
| |
With certain fstabs we may propagate ENXIO from the $SYSTEMD_SYSFS_CHECK
check all the way up, making fstab-generator exit with a non-zero EC and
without any helpful message, which is really confusing.
|
|
|
|
|
|
|
|
|
| |
Chasing symlinks is a core function that's used in a lot of places
so it deservers a less verbose names so let's rename it to chase()
and chaseat().
We also slightly change the pattern used for the chaseat() helpers
so we get chase_and_openat() and similar.
|
|
|
| |
* src: changed instances of sd_bus_call_method() to bus_call_method()
|
|\
| |
| |
| |
| | |
lilyinstarlight/fix/fstab-generator-sysroot-without-cmdline
fstab-generator: use correct targets when /sysroot is specificied in fstab only
|
| |
| |
| |
| |
| | |
This forces processing of /dev entries in fstab when running in a
container is detected (checked as the existence of read-only /sys).
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
| |
When compiled without ENABLE_EFI, efi_stub_measured() was not defined, so
compilation would fail. But it's not enough to add a stub that returns
-EOPNOTSUPP. We call this function in various places and usually print the error
at warning or error level, so we'd print a confusing message. We also can't add
a stub that always returns 0, because then we'd print a message like "Kernel
stub did not measure", which would be confusing too. Adding special handling for
-EOPNOTSUPP in every caller is also unattractive. So instead efi_stub_measured()
is reworked to log the warning or error internally, and such logging is removed
from the callers, and a stub is added that logs a custom message.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
measurements
Let's introduce a common implementation of a function that checks
whether we are booted on a kernel with systemd-stub that has TPM PCR
measurements enabled. Do our own userspace measurements only if we
detect that.
PCRs are scarce and most likely there are projects which already make
use of them in other ways. Hence, instead of blindly stepping into their
territory let's conditionalize things so that people have to explicitly
buy into our PCR assignments before we start measuring things into them.
Specifically bind everything to an UKI that reported measurements.
This was previously already implemented in systemd-pcrphase, but with
this change we expand this to all tools that process PCR measurement
settings.
The env var to override the check is renamed to SYSTEMD_FORCE_MEASURE,
to make it more generic (since we'll use it at multiple places now).
This is not a compat break, since the original env var for that was not
included in any stable release yet.
|
|
|
|
|
|
| |
If we use gpt-auto-generator, automatically measure root fs and /var.
Otherwise, add x-systemd.measure option to request this.
|
|
|
|
|
|
|
|
|
|
|
| |
We *assume* that when /sys is read-only, we're running in a container. But
there can other reasons, for example root is mount ro and nobody has mounted
/sys yet, or somebody forgot to add /sys to the list of filesystem not to
remount ro in a sandbox. So let's actually say what we know instead of assuming.
systemd-fstab-generator was reporting that it's running in a container and I
spent a good few minutes trying to figure out why 'systemd-detect-virt -c'
disagrees, before noticing that it's just checking a different condition.
|
| |
|
|
|
|
|
|
|
|
|
| |
I changed imports of util.h to initrd-util.h, or added an import of
initrd-util.h, to keep compilation working. It turns out that many files didn't
import util.h directly.
When viewing the patch, don't be confused by git rename detection logic:
a new .c file is added and two functions moved into it.
|
|
|
|
|
|
|
|
|
|
|
| |
The idea is that we can peek into /sysroot/etc/fstab and figure out if there's
anything interesting there. We could use a separate binary for this, but we'd
need to duplicate most of the logic that in systemd-fstab-generator. Thus I
think it's nicer to make systemd-fstab-generator work as a multi-call binary.
If called as systemd-sysroot-fstab-check, we look for units that we'd mount and
call daemon-reload and initrd-fs.target/restart, similarly to what we did
before, but in the process itself.
|
|
|
|
|
|
|
|
|
| |
When chase_symlinks() is called on something on a doesn't exist, it immediately
returns an error. But we were relying on it to prepend "/sysroot/". If it
fails, we need to do that ourselves.
For example, with /sysroot/etc/fstab containing a line for /foo, if /sysroot/foo
doesn't exist, we'd generate a mount point for /foo.
|
|
|
|
|
|
|
| |
Originally (6b1dc2bd3cdb3bd932b0692be636ddd2879edb92) we had 'pre' and 'post'
to refer to remote-fs-pre.target and remote-fs.target or local-fs-pre.target
and local-fs.target. But 'pre' is long gone, and 'post' by itself doesn't
make much sense. Rename it for clarity.
|
| |
|
|
|
|
| |
This adds $SYSTEMD_SYSROOT_FSTAB analoguous to $SYSTEMD_FSTAB.
|
|
|
|
|
|
|
|
| |
Mount information can come from /etc/fstab, /sysroot/etc/fstab, and
/proc/cmdline. Even when we had the path to the right source handy, we would
often write something inaccurate. In particular, in the initrd, we would
generally write "/etc/fstab" instead of "/sysroot/etc/fstab" for no good
reason.
|
|
|
|
|
| |
In the initrd we would treat e.g. "/usr/" as different from "/usr", which
doesn't seem right.
|
|
|
|
| |
This also avoids multiple evaluations in STRV_FOREACH_BACKWARDS()
|
| |
|
| |
|
|
|
|
| |
Fixes RHBZ#2037233 (https://bugzilla.redhat.com/show_bug.cgi?id=2037233).
|
|
|
|
| |
Closes #21744.
|
|\
| |
| | |
fstab-generator, core/mount: Avoid special fs target before dependency only if nofail is used
|
| |
| |
| |
| |
| |
| |
| |
| | |
target units
The ordering should not prevent noauto or automount from working
as expected, and we do not want them to be stopped too early if
they are active.
|
| |
| |
| |
| |
| | |
If 'usrhash' is present as a kernel command line parameter, use the usr
mapper device for usr mount
|
|/ |
|
| |
|
|
|
|
|
|
|
|
| |
All units in units/ follow this pattern, as do all other generators that we
provide. The question of the order was raised in
https://github.com/systemd/zram-generator/pull/90#discussion_r684965984,
and I think it's nice to make it consistent everywhere
(What= before Where= matches mount(8) and fstab(5)).
|
| |
|
| |
|
|
|
|
|
|
|
| |
The naming of variables is very inconsistent. I tried to use more
modern style naming (UNDERSCORED_TITLE_CASE), but I didn't change existing
names too much. Only SYSTEM_DATA_UNIT_PATH is renamed to SYSTEM_DATA_UNIT_DIR
to match SYSTEM_CONFIG_UNIT_DIR.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Let's rename MountpointsFlags → MountPointFlags. In most of our codebase
we name things mount_point/MountPoint rather than mountpoint/Mountpoint,
do so here too.
Also, prefix the enum values with "MOUNT_". The fact the enum values
weren#t prefixed was pretty unique in our codebase, and pretty
surprising. Let's fix that.
This is just refactoring, no actual change in behaviour
|
|
|
|
|
|
| |
Let's make sure, that our mount unit are properly ordered before the
"post" target unit even if DefaultDependencies= is used on the target
unit.
|
| |
|