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.
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.
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 (6b1dc2bd3c) 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.
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.
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.
Since the general generator logic was established in the rewrite in
07719a21b6, 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
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.
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.
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.
This reverts commit f42d41cc5f.
DHCPv6 client does not require MAC address.
DHCPv4 client will be handled in a different way in a later commit.
Partially fixes#23546.
Newer binutils versions currently trigger the following warnings due to
a bug in gnu-efi
on arm64:
/usr/bin/ld.bfd: warning: src/boot/efi/systemd-bootaa64.elf has a LOAD segment with RWX permissions
on amd64:
/usr/bin/ld.bfd: warning: /usr/lib/crt0-efi-x86_64.o: missing .note.GNU-stack section implies executable stack
This results in a build failure due to --fatal-warnings.
Work around this issue by suppressing those warnings until gnu-efi has
been fixed.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013341
