Previously, we first assign alternative names to a network interface,
then later change its main name if requested. So, we could not assign
the name that currently assigned as the main name of an interface as an
alternative name. So, we retry to assign the previous main name as an
alternative name on later move uevent.
However, that causes some confusing situation. E.g. if a .link file has
```
Name=foo
AlternativeNames=foo baz
```
then even if the interface is renamed by a user e.g. by invoking 'ip link'
command manually, the interface can be still referenced as 'foo', as the
name is now assigned as an alternative name.
This makes the order of name assignment inverse: the main name is first
changed, and then the requested alternative names are assigned. And
udevd do not assign alternative names on move uevent.
Replaces #27506.
We provide the same stability for all the headers that are public.
Also, mark id128 as portable to other systems. There is really nothing in the
code that would make it hard. It would probably work out-of-the-box.
Before libsystemd-daemon, libsystemd-journal, libsystemd-id128, etc., were
merged into libsystemd, it was enough to have individual man pages for them.
But they have been delivered as one thing for many years, so it's better to
have a landing page for libsystemd. It mostly directs to individual pages
anyway.
If we change the watchdog device we should disarm the old one first.
Similar, if we open the watchdog, but then fail setting it up, disarm it
before closing it again.
This accidentally got pulled into a commit even though it was only
for local testing, let's drop it again so we correctly use erofs
when building local images.
Build option "link-portabled-shared" to build a statically linked
systemd-portabled by using
-Dlink-portabled-shared=false
on systems with full systemd stack except systemd-portabled, such
as CentOS/RHEL 9.
We currently have to resort to SSH to get more than one interactive
terminal in a mkosi qemu VM. Let's increase our options by installing
tmux in the final image, which can multiplex the serial console into
many unique terminal sessions.
When we're building OS images, we never want /etc/machine-id to contain
anything other than "uninitialized" until we actually boot the image. So
let's allow image builders to write "uninitialized" to /etc/machine-id
and if systemd-machine-id-setup is called after, make sure we don't
overwrite it.
From RFC 2131 section 4.3.1 (https://www.rfc-editor.org/rfc/rfc2131#section-4.3.1):
----
The server MUST return to the client:
- Parameters requested by the client, according to the following rules:
-- IF the server has been explicitly configured with a default
value for the parameter, the server MUST include that value
in an appropriate option in the 'option' field,
----
The sentence is not only for ACK, but for all (positive) responses, that
is DHCPOFFER and DHCPACK.
Fixes#27471.
Let's start moving towards a more involved partitioning setup to
test our stuff more when using mkosi.
The root partition is generated on boot with systemd-repart.
CentOS supports neither erofs nor btrfs so we use squashfs and xfs
instead.
We also enable SecureBoot= locally for additional coverage. This
and the use of verity means users need to run `mkosi genkey` once
to generate the keys necessary to do secure boot and verity.
If we're making a /usr only image, we still want to populate /etc
fully on first boot. To make that possible, let's copy /etc to
/usr/share/factory/mkosi in a finalize script, which runs after
all changes to the image have been made. Let's also add a tmpfiles
snippet that merges /usr/share/factory/mkosi with /etc on boot to
populate /etc.
This is only useful to be able to remove generated files using rm -rf
instead of mkosi clean and has some implications for the generated
rootfs so let's not enable it by default.
This allows setting it on the kernel cmdline and having it work
automatically without having to write any dropins or such.
Also enable the option in mkosi so that we can debug the initrd
properly with a locked root account.
These are all services that valid to be run in the initrd, so let's
make sure they have the appropriate dependencies on
initrd-switch-root.target so that they are stopped when we're about
to switch root.
