initrd-parse-etc: override argv[0] to avoid dracut issue
Quoting https://github.com/systemd/systemd/pull/24054#issuecomment-1210501631:
> this would need a patch in dracut, specifically adding the
> systemd-sysroot-fstab-check to the list of installed stuff:
> https://github.com/dracutdevs/dracut/blob/fe8fa2b0cadbb33e27c8dd8b5851548dcd65835c/modules.d/00systemd/module-setup.sh#L47.
>
> I could do this manually in the CI (and I guess I'd have to do it anyway even
> if the patch lands in upstream, since it won't be available in C8S), but it
> should get there first before merging this PR, otherwise it's going to break
> Rawhide.
units/initrd-parse-etc.service: only start units that are required
This makes use of the option switch that was added in the previous commit.
We used a pretty big hammer on a relatively small nail: we would do daemon-reload
and (in principle) allow any configuration to be changed. But in fact we only
made use of this in systemd-fstab-generator. systemd-fstab-generator filters
out all mountpoints except /usr and those marked with x-initrd.mount, i.e. on
a big majority of systems it wouldn't do anything.
Also, since systemd-fstab-generator first parses /proc/cmdline, and then
initrd's /etc/fstab, and only then /sysroot/etc/fstab, configuration in the
host would only matter if it the same mountpoint wasn't configured "earlier".
So the config in the host could be used for new mountpoints, but it couldn't
be used to amend configuration for existing mountpoints. And we wouldn't actually
remount anything, so mountpoints that were already mounted wouldn't be affected,
even if did change some config.
In the new scheme, we will parse /sysroot/etc/fstab and explicitly start
sysroot-usr.mount and other units that we just wrote. In most cases (as written
above), this will actually result in no units being created or started.
If the generator is invoked on a system with /sysroot/etc/fstab present,
behaviour is not changed and we'll create units as before. This is needed so
that if daemon-reload is later at some points, we don't "lose" those units.
There's a minor bugfix here: we honour x-initrd.mount for swaps, but we
wouldn't restart swap.target, i.e. the new swaps wouldn't necessarilly be
pulled in immediately.
fstab-generator: add mode to check /sysroot/etc/fstab and maybe do daemon-reload
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.
docbook already indents diagrams, so there is no need to leave whitespace on
the left. Also, make the charts a bit narrower to fit better on a terminal.
booctl: do not say uuids differ if one of the uuids is unset
We allow ESP autodetection to fail, e.g. if it is not mounted, but then we'd
say that the detected one is different than the one reported by the bootloader,
which is rather confusing.
While at it, if we actually detect a mismatch, print the two uuids.
fstab-generator: do not skip /sysroot prefix if the mount point is missing
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.
fstab-generator: properly report the source of data
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.
generators: only redirect logging when invoked by systemd
We would always print output to the kmsg or journal, but that is only needed
and useful when invoked by systemd. So let's skip redirection unless we are
invoked by systemd. Otherwise, let's log normally. This makes test invocations
easier, and also helps when the generator is invoked by mistake. If redirection
is necessary, the generator can be invoked with SYSTEMD_LOG_TARGET=… even
during tests.
generators: accept one or three args, do not write to /tmp
Since the general generator logic was established in the rewrite in 07719a21b6425d378b36bb8d7f47ad5ec5296d28, generators would always write to /tmp
by default. I think this not a good default at all, because generators write a
bunch of files and would create a mess in /tmp. And for debugging, one
generally needs to remove all the files in the output directory, because
generators will complain in the output paths are already present. Thus the
approach of disabling console logging and writing many files to /tmp when
invoked with no arguments is not nice, so let's disallow operation with no
args.
But when debugging, one generally does not care about the separate output dirs
(most generators use only one). Thus the general pattern I use is something
like:
rm -rf /tmp/x && mkdir /tmp/x && build/some-generator /tmp/{x,x,x}
This commit allows only one directory to be specified and simplifies this to:
rm -rf /tmp/x && mkdir /tmp/x && build/some-generator /tmp/x
base-filesystem: pick more conservative access mode for /root/
Let's not allow anyone to look into /root/ if we create it via the
base-filesystem logic. i.e. change 0755 → 0750 as default access mode
for /root/, in case we create it if it happens to be missing.
growfs: Expand FS even if underlying block expansion fails
This allows growfs to expand the filesystem even when the underlying
block device cannot be expanded. This has been useful for example on
LUKS devices that have already been expanded using systemd-repart.
This works around the following error:
```
root@mobian:/home/mobian# /usr/lib/systemd/systemd-growfs /
crypt_resize() of /dev/block/179:2 failed: Operation not permitted
```
This causes systemd-growfs to exit before resizing the partition when
`--dry-run` is passed. Resizing during a dry run of a change breaks the
users expectations.
growfs: insist we open a directory when opening fs mount point
This is a simple safety check, since we shouldn't invoke ioctls on fds
without being reasonably sure they are of the right type since ioctls
are overloaded, and we might be tricked hence to execute an operation on
an fd which means something different than what we expect.
man: lift pam_systemd_homed description to Summary
Also change the title to describe the module more comprehensively.
Follow-up for 90bc309aa2c1430941f4c50f73e681ab3e488bd3. Suggested
in https://bugzilla.redhat.com/show_bug.cgi?id=2085485#c5.
David Tardon [Wed, 13 Jul 2022 09:29:20 +0000 (11:29 +0200)]
test: ensure cleanup functions return success
Otherwise the return value of the last command is propagated, which may
cause spurious test failures. E.g., pkill returns 1 if no process
matched, which may be a problem in cleanup session:
Several DHCP client tests change the system timezone.
Let's save the current timezone at the beginning, and restore it with
the saved value at the end.
logind: don't delay login for root even if systemd-user-sessions.service is not activated yet
If for any reason something goes wrong during the boot process (most likely due
to a network issue), system admins should be allowed to log in to the system to
debug the problem. However due to the login session barrier enforced by
systemd-user-sessions.service for all users, logins for root will be delayed
until a (dbus) timeout expires. Beside being confusing, it's not a nice user
experience to wait for an indefinite period of time (no message is shown) this
and also suggests that something went wrong in the background.
The reason of this delay is due to the fact that all units involved in the
creation of a user session are ordered after systemd-user-sessions.service,
which is subject to network issues. If root needs to log in at that time,
logind is requested to create a new session (via pam_systemd), which ultimately
ends up waiting for systemd-user-session.service to be activated. This has the
bad side effect to block login for root until the dbus call done by pam_systemd
times out and the PAM stack proceeds anyways.
To solve this problem, this patch orders the session scope units and the user
instances only after systemd-user-sessions.service for unprivileged users only.
smack: Add DefaultSmackProcessLabel to user.conf and system.conf
DefaultSmackProcessLabel tells systemd what label to assign to its child
process in case SmackProcessLabel is not set in the service file. By
default, when DefaultSmackProcessLabel is not set child processes inherit
label from systemd.
If DefaultSmackProcessLabel is set to "/" (which is an invalid character
for a SMACK label) the DEFAULT_SMACK_PROCESS_LABEL set during compilation
is ignored and systemd act as if the option was unset.
I don't quite understand this, but '{ ! true; }' is not the same as '( ! true )'.
In interactive mode, it seems to work as expected. But in a script, it doesn't.
This means that we'll fail hard if something goes wrong, e.g. reading
of a config file. I think this is appropriate. If errors should be ignored,
the caller should do that on their end.
kernel-install: return 0 for unknown verbs in plugins
In practice this makes little difference, because kernel-install will
only call the plugins for 'add' or 'remove', and if we were to add a
new verb to kernel-install, we'd just change the plugins at the same
time. But our plugins serve as documentation for external plugins too,
and there it's better to silently ignore unknown verbs so that we can
add new verbs in the future.
test-kernel-install: add a simple test that kernel-install copies the files
I opted to tweaking kernel-install to allow overriding config
(with $KERNEL_INSTALL_CONF_ROOT, $KERNEL_INSTALL_PLUGINS). An alternative
would be to build a test environment in test/. We can still do that,
but I think it's nice to have a simple test that is very quick and easy
to debug.
- introduce several helper functions
- do not list unit files, but remove the runtime unit directory in
tearDown().
- do not list used interfaces, but remove all interfaces previously not
exists in tearDown().
- save routes and routing policy rules before running tests, and flush
unnecessary routes and rules in each tearDown() calls.
- drop many time.sleep() calls.
- call tearDown() after each sub tests.
- shorten code.
- several coding style fixes.
- etc, etc...
projects / thirdparty / systemd.git / log
