I couldn't convince vmspawn to start a VM on a Fedora image I just
downloaded, and it was pretty light on any useful details:
$ build/systemd-vmspawn --image ~/Downloads/Fedora-Server-Guest-Generic-Rawhide-20260627.n.0.x86_64.qcow2 --image-format=qcow2 --bind-ro=/tmp/bar; echo $?
░ Spawning VM Fedora-Server-Guest-Generic-Rawhide-20260627.n.0.x8664.qcow2 on /home/mrc0mmand/Downloads/Fedora-Server-Guest-Generic-Rawhide-20260627.n.0.x86_64.qcow2.
░ Press Ctrl-] three times within 1s to kill VM.
1
Turns out that the unix socket path vmspawn generates for the virtiofsd
socket is too long. Let's relay this information to the user as well to
make debugging this a little less painful:
$ build/systemd-vmspawn --image ~/Downloads/Fedora-Server-Guest-Generic-Rawhide-20260627.n.0.x86_64.qcow2 --image-format=qcow2 --bind-ro=/tmp/bar
░ Spawning VM Fedora-Server-Guest-Generic-Rawhide-20260627.n.0.x8664.qcow2 on /home/mrc0mmand/Downloads/Fedora-Server-Guest-Generic-Rawhide-20260627.n.0.x86_64.qcow2.
░ Press Ctrl-] three times within 1s to kill VM.
Failed to prepare unix socket '/run/user/1000/systemd/vmspawn/Fedora-Server-Guest-Generic-Rawhide-20260627.n.0.x8664.qcow2/sock-9594581dcf598992': File name too long
With this change, gcrypt dependency is not mandatory. Hence, allow to build
systemd even when -D gcrypt=enabled but gcrypt devel package is not installed.
This introduce a vtable for journal tagging feature in sd-journal,
and makes libgcrypt dependent features loaded by users (journald,
journalctl, journal-remote, and unit tests) when necessary.
Then, move several components for journal tagging in JournalFile
to JournalAuthContext.
This also introduces wrapper functions that checks gcrypt support.
* 0b390d2683 One more fixup for d/copyright
* 91d3dadcb5 Update changelog for 261.1-1 release
* 3c287e1f86 d/copyright: update to add new licenses
* a82117f9a3 Install new files for upstream build
* 020caeb149 Override new Lintian false positive
* d55b67b66e d/control: demote libnss-{myhostname,resolve} to Suggests for systemd-resolved
* 1c537705ec Update changelog for 261-2 release
* 6235897bbc Note new package split in NEWS
* a440cb2c4a Install new files for upstream build
* 7eaa21ad05 Split tpm tools into new systemd-tpm package
* 52b28b74f3 Split metrics reporting tools into new systemd-report package
* de2f367f22 Split imds tools into new systemd-imds package
* 2d0a07f5ae d/t/control: do not install xserver-xorg-video-dummy on loong64
* c886c3efc8 Install new files for upstream build
* 0efa66b4af Update changelog for 261-1 release
* e36cf82a1d lintian-overrides: override error about derivative.ubuntu build profile
* fbd38c36ea d/control: do not build systemd-boot-efi-*-signed-template on ubuntu
Observerd on Ubuntu 24.04 with GCC 13 on arm64 architecture.
```
../src/shared/journal-importer.c: In function ‘journal_importer_process_data’:
../src/shared/journal-importer.c:344:30: error: ‘line’ may be used uninitialized [-Werror=maybe-uninitialized]
344 | if (!journal_field_valid(line, n - 1, true)) {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/shared/journal-importer.c:295:23: note: ‘line’ was declared here
295 | char *line, *sep;
| ^~~~
cc1: all warnings being treated as errors
```
There are already varlink methods for `ResolveHostname`,
`ResolveAddress`, and `ResolveRecord`. Use those in `resolvectl` instead
of the dbus equivalents.
Follow-up to #42422:
- Rename process_image() to context_process_image(), since it now
operates on a Context object.
- Use IN_SET() in image_type_can_sysupdate() instead of a switch.
- Name the return parameters of context_list_components() ret_xyz, per
our coding style.
- Drop a redundant "else" after a return in vl_method_check_new().
This puts the scaffolding in place for a varlink interface, but so far
it only adds a `io.systemd.Sysupdate.CheckNew()` method. Varlinkifying
the other verbs on `systemd-sysupdate` will happen in follow-up PRs, but
I thought I’d try and land this one early to:
* Get review of the overall varlinkification scaffolding
* Lower the chance of big merge conflicts with others’ work by getting
the more invasive changes out of the way
* Get the scaffolding in place so others can start to build on it if
they wish (although I am currently working on porting the other existing
verbs)
It rearranges how the `Context` struct is allocated so that it’ll be
easier to add per-method/verb context structs which contain it in
future. It also changes all the `sysupdate.c` code to use arguments from
`Context` rather than `arg_*` globals, allowing them to be specified as
varlink parameters in future.
It also moves the existing `systemd-sysupdate.{timer,service}` units
(which periodically run `systemd-sysupdate update`) to
`systemd-sysupdate-update.{timer,service}` to clear space for a
`systemd-sysupdate@.service` and `systemd-sysupdate.socket` to act as a
varlink entry point.
/cc @AdrianVovk
postmarketOS image can be built with for example the following mkosi.local.conf:
```
[Distribution]
Distribution=postmarketos
[Output]
Format=disk
[Build]
UseSubvolumes=yes
[Runtime]
Firmware=uefi
```
This is preparation for using varlink methods more in resolvectl. In
particular, this is helpful for proving more accurate error messages,
and maintaining compatibility with existing error messages from the
DBus API.
Frantisek Sumsal
Yu Watanabe
Luca Boccassi
Lennart Poettering
Nick Rosbrook
dirhamtriyadi