systemd-repart not packaged

Status changed to 'Confirmed' because the bug affects multiple users.

This was enabled in Debian's systemd v250.1-2
https://salsa.debian.org/systemd-team/systemd/-/commit/4a93ec2f56969e11c73ef346a342e7e552faae75

We're shipping the more stable systemd v249 in Ubuntu Jammy LTS, and are already post feature freeze, so we cannot enable new features anymore.

This will most probably land in Ubuntu 22.10 once we merge systemd v250+.

Any chance it could be enabled now that Jammy shipped? It's really fine to enable it in 249 for 20.10, there's really no reason to wait for a new version

I was asked to add a Jammy task, I did so - the details and if that will be done is up to your consideration/discussion/decision.

The upstream systemd developers team would like to request to enable systemd-repart in Jammy in the next proposed-updates. MR: https://code.launchpad.net/~bluca/ubuntu/+source/systemd/+git/systemd/+merge/427557

debdiff enabling systemd repart in the jammy/devel branch

We got some response from the SRU team (@racb):

https://lists.ubuntu.com/archives/ubuntu-devel/2022-August/042250.html

Basically he suggests doing this change in a PPA/jammy-backports, or as a entirely new package:

* "what if you were to put systemd-repart as a new package into a PPA, or into jammy-backports?"
* "In general, adding new entirely new packages is considered OK from a regression risk perspective."

Would this work for you @bluca?

There's further discussion in the ubuntu-devel ML thread.

In addition to that though, I notice that mkosi in Jammy does refer to /usr/bin/systemd-repart. Will the Jammy packaged mkosi therefore change behaviour if you start shipping it in Ubuntu?

> In addition to that though, I notice that mkosi in Jammy does refer to /usr/bin/systemd-repart. Will the Jammy packaged mkosi therefore change behaviour if you start shipping it in Ubuntu?

Those references are for the dracut configuration, i.e. to get those files from the target image to the target image's initrd. What is available on the host is independent of that.

After the discussion on the mailing list (ubuntu-devel@) has settled, and @bluca provided an updated MP#427557 to ship systemd-repart as an additional binary package in Jammy (universe, not installed by default), I've moved ahead and staged the changes to provide an upgrade path (removal of systemd-repart in Kinetic++, now provided by the "systemd" binary itself):
https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?h=ubuntu-kinetic&id=2281670aa8007179170d5cc485bb94e3bbc3b63c

I've tested that Jammy's systemd-repart binary is removed/replaced by Kinetic's "systemd" binary on "apt full-upgrade".

Also, I've verified that the systemd-repart build-time test is executed when running the build locally (dpkg-buildpackage) and full test logs can be found in "build-deb/meson-logs/testlog.txt". The systemd-repart test is being skipped when ran in sbuild, due to missing the /dev/loop-control device.

The new TEST-58-REPART autopkgtest is executed as part of the "upstream-2" test suite.

Hello Iain, or anyone else affected,

Accepted systemd into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/249.11-0ubuntu3.5 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-jammy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

All autopkgtests for the newly accepted systemd (249.11-0ubuntu3.5) for jammy have finished running.
The following regressions have been reported in tests triggered by the package:

gvfs/1.48.2-0ubuntu1 (ppc64el)
systemd/249.11-0ubuntu3.5 (ppc64el)
udisks2/2.9.4-1ubuntu2 (arm64)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/jammy/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

Hello Iain, or anyone else affected,

Accepted systemd into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/systemd/249.11-0ubuntu3.6 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-jammy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

All autopkgtests for the newly accepted systemd (249.11-0ubuntu3.6) for jammy have finished running.
The following regressions have been reported in tests triggered by the package:

stunnel4/3:5.63-1build1 (amd64)
munin/2.0.57-1ubuntu2 (amd64)
corosync/unknown (s390x)
conntrack-tools/unknown (s390x)
exim4/4.95-4ubuntu2.1 (ppc64el)
umockdev/0.17.7-1 (armhf)
netplan.io/0.104-0ubuntu2.1 (amd64)
initramfs-tools/0.140ubuntu13 (amd64)
dovecot/unknown (s390x)
network-manager/1.36.6-0ubuntu2 (amd64)
cups/unknown (s390x)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/jammy/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

I have verified that systemd-repart is available in jammy-proposed, and that the upgrade path to kinetic works as expected:

root@jammy:~# apt-cache policy systemd-repart
systemd-repart:
  Installed: 249.11-0ubuntu3.6
  Candidate: 249.11-0ubuntu3.6
  Version table:
 *** 249.11-0ubuntu3.6 500
        500 http://archive.ubuntu.com/ubuntu jammy-proposed/main amd64 Packages
        100 /var/lib/dpkg/status
root@jammy:~# do-release-upgrade -d
[ upgrade... ]
[ reboot... ]

root@jammy:~# lsb_release -cs
kinetic
root@jammy:~# apt-cache policy systemd-repart
systemd-repart:
  Installed: (none)
  Candidate: (none)
  Version table:
root@jammy:~# apt-cache policy systemd
systemd:
  Installed: 251.4-1ubuntu4
  Candidate: 251.4-1ubuntu4
  Version table:
 *** 251.4-1ubuntu4 500
        500 http://archive.ubuntu.com/ubuntu kinetic/main amd64 Packages
        100 /var/lib/dpkg/status
root@jammy:~# dpkg -S /bin/systemd-repart
systemd: /bin/systemd-repart

The autopkgtest regressions for systemd 249.11-0ubuntu3.6 in jammy-proposed were all resolved with retries.

This bug was fixed in the package systemd - 249.11-0ubuntu3.6

---------------
systemd (249.11-0ubuntu3.6) jammy; urgency=medium

  * Deny-list TEST-58-REPART on ppc64el (LP: #1988994)
    File: debian/patches/lp1988994-Deny-list-TEST-58-REPART-on-ppc64el.patch
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=d2ed3cc1d223bf35015b15ff83b50156b58f0f38

systemd (249.11-0ubuntu3.5) jammy; urgency=medium

  [ Nick Rosbrook ]
  * Ensure dns_search_domain_unlink_marked removes all marked domains (LP: #1975667)
    File: debian/patches/lp1975667-Ensure-dns_search_domain_unlink_marked-removes-all-marked.patch
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=919d5ddedd5bb8b45ab9437bf42d66c2821bb074
  * core,firstboot: workaround timezone issues on Ubuntu Core (LP: #1981042)
    Thanks to Robert Ancell for preparing the patch.
    File: debian/patches/lp1981042-core-firstboot-workaround-timezone-issues-caused-by-Ubunt.patch
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=b15546361b549217908fb6ca5d473be23d7fa757
  * network: do not remove localhost address (LP: #1979951)
    File: debian/patches/lp1979951-network-do-not-remove-localhost-address.patch
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=2cd88391cce9fe95a486ae6dd214c12f236f3881
  * units: remove the restart limit on the modprobe@.service (LP: #1982462)
    File: debian/patches/lp1982462-units-remove-the-restart-limit-on-the-modprobe-.service.patch
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=8f0acd1b2fbb8eed1259c34963e5e9b201bef900
  * pstore: do not try to load mtdpstore (LP: #1981622)
    File: debian/patches/lp1978079-efi-pstore-not-cleared-on-boot.patch
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=15225032c3657f5906ee49d48929f9295a8664a0
  * core/mount: downgrade log level about several mkdir failures (LP: #1979952)
    Files:
    - debian/patches/lp1979952-Revert-core-mount-fail-early-if-directory-cannot-be-creat.patch
    - debian/patches/lp1979952-core-mount-downgrade-log-level-about-several-mkdir-failur.patch
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=ee8cfcf500698fab2e990de291ecf4c3ab87a4ae
  * debian/control: add Recommends: systemd-hwe-hwdb to udev.
    The systemd-hwe-hwdb brings in additional hwdb rules for HWE, so we want
    those installed with udev by default.
    File: debian/control
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=4a7a3258c33201cca305956820fcc6bcd6052d76
  * hwdb: implement --root option for systemd-hwdb query (LP: #1988078)
    Files:
    - debian/libsystemd0.symbols
    - debian/patches/lp1988078-hwdb-implement-root-option-for-systemd-hwdb-query.patch
    - debian/patches/lp1988078-sd-hwdb-add-sd_hwdb_new_from_path.patch
    - debian/patches/lp1988078-sd-hwdb-include-sys-stat.h-in-hwdb-internal.h.patch
    https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=937fef96c858f2f2042bf71032f315647c14add0

  [ Luca Boccassi ]
  * Enable systemd-repart and ship it in a new s...

The verification of the Stable Release Update for systemd has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.