mkosi has switched to systemd-repart

[behrmann]

Not an issue, but as a heads up to users of the main branch. mkosi has switched to systemd-repart in #1276.

Please have a look at the news file how to adapt your configs and mind that for now you will need a current version of repart built from the systemd sources, using

ExtraSearchPaths=/path/to/the/systemd/builddir

[benschlueter]

The quickfix is not working if you specify partitions on your own with mkosi.repart

[DaanDeMeyer]

The quickfix is not working if you specify partitions on your own with mkosi.repart

Please open a new issue with logs and a detailed description of the problem and I'll take a look

[rezib]

This is a great feature, I love it for sure and thank you for this. But do you plan to maintain bugfix releases of v14 for users not running bleeding edge version of systemd? I am encountering bugs in v14 that are fixed in main (eg. build of rocky9 images) but I cannot run the main branch and future v15 on my production servers anymore. Do you have any plan regarding this?

[behrmann]

I'm not sure we have the manpower to support a v14 branch. Personally, if you want to run the main branch, I'd go with having a local checkout of the systemd repo and building the needed tools from source as we do in CI, see action.yaml. This has the added benefit of users not having to wait for new systemd to arrive in their distro (and them having to put any work to switching the systemd they run to something like a backports version) und us being able to use newer things right away.

[rezib]

Thank you @behrmann for your answer. FWIW, I successfully tested this approach on Debian bullseye by building a custom systemd-mkosi package with the executables mentionned in action.yaml. As a side note, this requires backporting systemd's ukify to Python 3.9 as it expects Python >= 3.10. Anyone feel free to contact me if you are interested in this systemd-mkosi Debian bullseye binary (or source) package.

[Simon-L]

I'd like to second @rezib's request regarding support for v14. As the readme shows, every distribution is obviously still distributing it.
I'd like to make the point that as long as v15 is not out and stable (and that could reasonably happen only when the hard requirement of systemd 253 is met in all major distros, which will be in a while imo) and this repo being the only source of information and way to reach the developers, it will continue to receive these requests.

I'm on amd64 Debian Testing trying to build bootable aarch64 debian/ubuntu images. v14 in the repos is broken for that usage and it's been a hell of a ride to track down commits in main that brought fixes without incompatibilities. So far, I have been unsuccessful.

@behrmann @DaanDeMeyer Will you please reconsider this?
Thank you for your time and effort!

[DaanDeMeyer]

@Simon-L We're planning to release v15 with a strict requirement on v254 (since we'll be relying on new features from kernel-install very soon). We're not going to delay that release until systemd 254 is available everywhere.

We simply don't have the manpower to maintain support for v14. It's only me writing most of the code with support from @behrmann and I'm stretched thin as it is getting mkosi in a good state for the next release.

I am going to try and add a backwards compatible guarantee from v15 onwards to make sure we don't get into a situation like this again.

[pbjhelmert]

Is the v15 release blocked on anything in particular? It seems that Rocky >=9 builds with v14 are broken due to the PowerTools -> CRB change:

‣     Mounting API VFS…
/usr/lib/python3/dist-packages/dnf/const.py:22: DeprecationWarning: The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives
  import distutils.sysconfig
/usr/lib/python3/dist-packages/dnf/const.py:22: DeprecationWarning: The distutils.sysconfig module is deprecated, use sysconfig instead
  import distutils.sysconfig
AppStream                                                                                                                                                                         540 kB/s | 7.1 MB     00:13
BaseOS                                                                                                                                                                            2.8 MB/s | 1.9 MB     00:00
extras                                                                                                                                                                             23 kB/s |  10 kB     00:00
PowerTools                                                                                                                                                                         19 kB/s |  20 kB     00:01
Errors during downloading metadata for repository 'PowerTools':
  - Status code: 404 for https://mirrors.rockylinux.org/mirrorlist?arch=x86_64&repo=PowerTools-9 (IP: 199.232.194.132)
  - Status code: 404 for https://mirrors.rockylinux.org/mirrorlist?arch=x86_64&repo=PowerTools-9 (IP: 199.232.198.132)
Error: Failed to download metadata for repo 'PowerTools': Cannot prepare internal mirrorlist: Status code: 404 for https://mirrors.rockylinux.org/mirrorlist?arch=x86_64&repo=PowerTools-9 (IP: 199.232.198.132)
Traceback (most recent call last):

This was fixed in fee9cdf.

[keszybz]

We could have a v14-stable branch with some point releases. Even if v15 is released, it wouldn't be suitable for updates in stable releases, so it'd make sense to keep both versions updated in parallel for a bit. But as Daan said, the people currently working on this don't have the resources to provide this. Somebody else would need to volunteer. (If there's a e.g. specific list of commits that could be backported, that'd be a good start.)

[pbjhelmert]

That sounds great, thanks!
For me, the primary fix is fee9cdf which I semi-manually backported here: pbjhelmert@1f51216

[septatrix]

@Simon-L We're planning to release v15 with a strict requirement on v254 (since we'll be relying on new features from kernel-install very soon). We're not going to delay that release until systemd 254 is available everywhere.

Is v254 now required for v15? There is no mention of it in the release notes...

[behrmann]

It's not in the news - where it probably should be, too - but in the requirements section of the docs

mkosi currently requires systemd 254 to build bootable disk images.

[septatrix]

What is the equivalent of RootSize=... now? When I try to add partition config files I always get either empty partitions or permission errors for not being able to mount loopback devices (or does that still require root against the statement that mkosi now doesn't require root)?

It's certainly nice having the whole arsenal of repart options available and I will definitely try to use it to configure A/B and a split rw /var partition down the line though I am quite new to repart and do not understand what I might do wrong after reading the man pages

[DaanDeMeyer]

You can use the source code as a starting point. I'll add the definitions from the mkosi source to the docs to make this easier.

[DaanDeMeyer]

@septatrix PR documenting the defaults: #1817

[septatrix]

The documentation still says:

ImageId=, --image-id=
[...]. If this option is used the root, /usr/ and Verity partitions in the image will have their labels set to this (possibly suffixed by the image version).

This seems to no longer be the case after this switch. Can someone else confirm this?

Sadly I do not think there is a way to get this behaviour back with the current repart capabilities (at least not automatically from within mkosi). As a workaround I have now added Label=%M_%A{,_verity,_verity_sig} to most of my repart files.

[DaanDeMeyer]

Yeah this seems out of date, will fix the docs.