| 2020-09-30 16:05:21 |
Iain Lane |
bug |
|
|
added bug |
| 2020-09-30 16:05:31 |
Iain Lane |
summary |
systemd-repart not packages |
systemd-repart not packaged |
|
| 2020-10-01 13:45:38 |
Dan Streetman |
bug |
|
|
added subscriber Dan Streetman |
| 2021-04-07 00:04:53 |
Tianon Gravi |
bug watch added |
|
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976959 |
|
| 2021-04-07 00:04:53 |
Tianon Gravi |
bug task added |
|
systemd (Debian) |
|
| 2021-04-07 00:05:08 |
Launchpad Janitor |
systemd (Ubuntu): status |
New |
Confirmed |
|
| 2021-04-07 01:09:37 |
Bug Watch Updater |
systemd (Debian): status |
Unknown |
New |
|
| 2021-04-07 16:45:31 |
Tianon Gravi |
bug |
|
|
added subscriber Tianon Gravi |
| 2022-01-14 03:01:33 |
Bug Watch Updater |
systemd (Debian): status |
New |
Fix Released |
|
| 2022-03-16 11:44:55 |
Lukas Märdian |
systemd (Ubuntu): status |
Confirmed |
Triaged |
|
| 2022-03-16 11:44:57 |
Lukas Märdian |
systemd (Ubuntu): importance |
Undecided |
Medium |
|
| 2022-04-25 22:51:18 |
Dan Streetman |
removed subscriber Dan Streetman |
|
|
|
| 2022-07-28 14:09:10 |
Luca Boccassi |
description |
systemd-repart is not (as of 246.6-1ubuntu1) packaged in the Ubuntu/Debian packages of systemd - probably because it has an extra dependency?
I'd like to use it in our new raspberry pi images where we don't have cloud-init installed. We're already using systemd-growfs, but we are missing the nice partition resizing part (so are using cloud-initramfs-growroot).
Could you please consider enabling it? In another binary package - so it can have extra deps - would be just fine by me. |
[Impact]
systemd-repart is not (as of 246.6-1ubuntu1) packaged in the Ubuntu/Debian packages of systemd - probably because it has an extra dependency?
The bug reporter would like to use it in our new raspberry pi images where they don't have cloud-init installed. The reporter is already using systemd-growfs, but they are missing the nice partition resizing part (so are using cloud-initramfs-growroot).
Furthermore, in the mkosi image builder (https://github.com/systemd/mkosi), the systemd/mkosi developers would like to start using systemd-repart for partitioning. Unfortunately, they're currently blocked on this because 22.04 doesn't ship systemd-repart. The upstream CI uses Github Actions which runs on Ubuntu Jammy and will do so until the next Ubuntu LTS is released. If we have to wait for the next LTS to be released, we'll have to wait for a considerable amount of time before we're able to start using systemd-repart.
Being able to use systemd-repart will allow the systemd/mkosi developers to take advantage of its improved interface compared to sfdisk,
as well as its builtin protections against race conditions surrounding the use of loop devices. The systemd/mkosi developers expect to
be able to get rid of some nasty loop device failure in mkosi by using systemd-repart.
[Test Plan]
This is a missing extra executable. Once enabled it has self-tests in the build-time unit tests, and also a regression test in the autopkgtest 'upstream' suite.
[Where problems could occur]
Shipping systemd-repart will come with no additional risk. While there is a systemd-repart.service that runs on boot, it's configured to not do anything if no config files are shipped with the system or provided by the user. As such, the service, if enabled, will effectively be a noop. Aside from the service, there's the CLI tool systemd-repart and the accompanying man pages that will be shipped as part of the systemd package.
Given that there's no risk involved with enabling systemd-repart, and given the useful features it provides, the systemd/mkosi developers would like to request that systemd-repart be enabled in Ubuntu and backported to Jammy so that they can start adopting it in mkosi. |
|
| 2022-07-28 14:24:03 |
Christian Ehrhardt |
nominated for series |
|
Ubuntu Jammy |
|
| 2022-07-28 14:24:03 |
Christian Ehrhardt |
bug task added |
|
systemd (Ubuntu Jammy) |
|
| 2022-07-28 14:24:12 |
Luca Boccassi |
systemd (Ubuntu): status |
Triaged |
Fix Released |
|
| 2022-07-28 14:24:16 |
Luca Boccassi |
systemd (Ubuntu Jammy): status |
New |
Confirmed |
|
| 2022-07-28 15:02:57 |
Luca Boccassi |
attachment added |
|
systemd_repart.debdiff https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1897932/+attachment/5605761/+files/systemd_repart.debdiff |
|
| 2022-07-28 15:03:44 |
Luca Boccassi |
bug |
|
|
added subscriber Ubuntu Sponsors Team |
| 2022-07-28 15:27:43 |
Luca Boccassi |
bug |
|
|
added subscriber Luca Boccassi |
| 2022-07-28 15:28:16 |
Luca Boccassi |
description |
[Impact]
systemd-repart is not (as of 246.6-1ubuntu1) packaged in the Ubuntu/Debian packages of systemd - probably because it has an extra dependency?
The bug reporter would like to use it in our new raspberry pi images where they don't have cloud-init installed. The reporter is already using systemd-growfs, but they are missing the nice partition resizing part (so are using cloud-initramfs-growroot).
Furthermore, in the mkosi image builder (https://github.com/systemd/mkosi), the systemd/mkosi developers would like to start using systemd-repart for partitioning. Unfortunately, they're currently blocked on this because 22.04 doesn't ship systemd-repart. The upstream CI uses Github Actions which runs on Ubuntu Jammy and will do so until the next Ubuntu LTS is released. If we have to wait for the next LTS to be released, we'll have to wait for a considerable amount of time before we're able to start using systemd-repart.
Being able to use systemd-repart will allow the systemd/mkosi developers to take advantage of its improved interface compared to sfdisk,
as well as its builtin protections against race conditions surrounding the use of loop devices. The systemd/mkosi developers expect to
be able to get rid of some nasty loop device failure in mkosi by using systemd-repart.
[Test Plan]
This is a missing extra executable. Once enabled it has self-tests in the build-time unit tests, and also a regression test in the autopkgtest 'upstream' suite.
[Where problems could occur]
Shipping systemd-repart will come with no additional risk. While there is a systemd-repart.service that runs on boot, it's configured to not do anything if no config files are shipped with the system or provided by the user. As such, the service, if enabled, will effectively be a noop. Aside from the service, there's the CLI tool systemd-repart and the accompanying man pages that will be shipped as part of the systemd package.
Given that there's no risk involved with enabling systemd-repart, and given the useful features it provides, the systemd/mkosi developers would like to request that systemd-repart be enabled in Ubuntu and backported to Jammy so that they can start adopting it in mkosi. |
[Impact]
systemd-repart is not (as of 246.6-1ubuntu1) packaged in the Ubuntu/Debian packages of systemd - probably because it has an extra dependency?
The bug reporter would like to use it in their new raspberry pi images where they don't have cloud-init installed. The reporter is already using systemd-growfs, but they are missing the nice partition resizing part (so are using cloud-initramfs-growroot).
Furthermore, in the mkosi image builder (https://github.com/systemd/mkosi), the systemd/mkosi developers would like to start using systemd-repart for partitioning. Unfortunately, they're currently blocked on this because 22.04 doesn't ship systemd-repart. The upstream CI uses Github Actions which runs on Ubuntu Jammy and will do so until the next Ubuntu LTS is released. If we have to wait for the next LTS to be released, we'll have to wait for a considerable amount of time before we're able to start using systemd-repart.
Being able to use systemd-repart will allow the systemd/mkosi developers to take advantage of its improved interface compared to sfdisk,
as well as its builtin protections against race conditions surrounding the use of loop devices. The systemd/mkosi developers expect to
be able to get rid of some nasty loop device failure in mkosi by using systemd-repart.
[Test Plan]
This is a missing extra executable. Once enabled it has self-tests in the build-time unit tests, and also a regression test in the autopkgtest 'upstream' suite.
[Where problems could occur]
Shipping systemd-repart will come with no additional risk. While there is a systemd-repart.service that runs on boot, it's configured to not do anything if no config files are shipped with the system or provided by the user. As such, the service, if enabled, will effectively be a noop. Aside from the service, there's the CLI tool systemd-repart and the accompanying man pages that will be shipped as part of the systemd package.
Given that there's no risk involved with enabling systemd-repart, and given the useful features it provides, the systemd/mkosi developers would like to request that systemd-repart be enabled in Ubuntu and backported to Jammy so that they can start adopting it in mkosi. |
|
| 2022-07-28 15:30:03 |
Lukas Märdian |
tags |
|
rls-jj-incoming |
|
| 2022-07-28 15:45:26 |
Luca Boccassi |
description |
[Impact]
systemd-repart is not (as of 246.6-1ubuntu1) packaged in the Ubuntu/Debian packages of systemd - probably because it has an extra dependency?
The bug reporter would like to use it in their new raspberry pi images where they don't have cloud-init installed. The reporter is already using systemd-growfs, but they are missing the nice partition resizing part (so are using cloud-initramfs-growroot).
Furthermore, in the mkosi image builder (https://github.com/systemd/mkosi), the systemd/mkosi developers would like to start using systemd-repart for partitioning. Unfortunately, they're currently blocked on this because 22.04 doesn't ship systemd-repart. The upstream CI uses Github Actions which runs on Ubuntu Jammy and will do so until the next Ubuntu LTS is released. If we have to wait for the next LTS to be released, we'll have to wait for a considerable amount of time before we're able to start using systemd-repart.
Being able to use systemd-repart will allow the systemd/mkosi developers to take advantage of its improved interface compared to sfdisk,
as well as its builtin protections against race conditions surrounding the use of loop devices. The systemd/mkosi developers expect to
be able to get rid of some nasty loop device failure in mkosi by using systemd-repart.
[Test Plan]
This is a missing extra executable. Once enabled it has self-tests in the build-time unit tests, and also a regression test in the autopkgtest 'upstream' suite.
[Where problems could occur]
Shipping systemd-repart will come with no additional risk. While there is a systemd-repart.service that runs on boot, it's configured to not do anything if no config files are shipped with the system or provided by the user. As such, the service, if enabled, will effectively be a noop. Aside from the service, there's the CLI tool systemd-repart and the accompanying man pages that will be shipped as part of the systemd package.
Given that there's no risk involved with enabling systemd-repart, and given the useful features it provides, the systemd/mkosi developers would like to request that systemd-repart be enabled in Ubuntu and backported to Jammy so that they can start adopting it in mkosi. |
[Impact]
systemd-repart is not (as of 246.6-1ubuntu1) packaged in the Ubuntu/Debian packages of systemd - probably because it has an extra dependency?
The bug reporter would like to use it in their new raspberry pi images where they don't have cloud-init installed. The reporter is already using systemd-growfs, but they are missing the nice partition resizing part (so are using cloud-initramfs-growroot).
Furthermore, in the mkosi image builder (https://github.com/systemd/mkosi), the systemd/mkosi developers would like to start using systemd-repart for partitioning. Unfortunately, they're currently blocked on this because 22.04 doesn't ship systemd-repart. The upstream CI uses Github Actions which runs on Ubuntu Jammy and will do so until the next Ubuntu LTS is released. If we have to wait for the next LTS to be released, we'll have to wait for a considerable amount of time before we're able to start using systemd-repart.
Being able to use systemd-repart will allow the systemd/mkosi developers to take advantage of its improved interface compared to sfdisk,
as well as its builtin protections against race conditions surrounding the use of loop devices. The systemd/mkosi developers expect to
be able to get rid of some nasty loop device failure in mkosi by using systemd-repart.
[Test Plan]
This is a missing extra executable. Once enabled it has self-tests in the build-time unit tests, and also a regression test in the autopkgtest 'upstream' suite.
[Where problems could occur]
Shipping systemd-repart will come with no additional risk. While there is a systemd-repart.service that runs on boot, it's configured to not do anything if no config files are shipped with the system or provided by the user. As such, the service, if enabled, will effectively be a noop. Aside from the service, there's the CLI tool systemd-repart and the accompanying man pages that will be shipped as part of the systemd package.
Given that there's no risk involved with enabling systemd-repart, and given the useful features it provides, the systemd/mkosi developers would like to request that systemd-repart be enabled in Ubuntu and backported to Jammy so that they can start adopting it in mkosi.
Runtime behavior of existing components is not affected by the build config change. |
|
| 2022-08-01 10:47:57 |
Lukas Märdian |
merge proposal linked |
|
https://code.launchpad.net/~bluca/ubuntu/+source/systemd/+git/systemd/+merge/427557 |
|
| 2022-08-17 13:48:19 |
Robie Basak |
bug |
|
|
added subscriber Robie Basak |
| 2022-08-30 08:10:03 |
Lukas Märdian |
description |
[Impact]
systemd-repart is not (as of 246.6-1ubuntu1) packaged in the Ubuntu/Debian packages of systemd - probably because it has an extra dependency?
The bug reporter would like to use it in their new raspberry pi images where they don't have cloud-init installed. The reporter is already using systemd-growfs, but they are missing the nice partition resizing part (so are using cloud-initramfs-growroot).
Furthermore, in the mkosi image builder (https://github.com/systemd/mkosi), the systemd/mkosi developers would like to start using systemd-repart for partitioning. Unfortunately, they're currently blocked on this because 22.04 doesn't ship systemd-repart. The upstream CI uses Github Actions which runs on Ubuntu Jammy and will do so until the next Ubuntu LTS is released. If we have to wait for the next LTS to be released, we'll have to wait for a considerable amount of time before we're able to start using systemd-repart.
Being able to use systemd-repart will allow the systemd/mkosi developers to take advantage of its improved interface compared to sfdisk,
as well as its builtin protections against race conditions surrounding the use of loop devices. The systemd/mkosi developers expect to
be able to get rid of some nasty loop device failure in mkosi by using systemd-repart.
[Test Plan]
This is a missing extra executable. Once enabled it has self-tests in the build-time unit tests, and also a regression test in the autopkgtest 'upstream' suite.
[Where problems could occur]
Shipping systemd-repart will come with no additional risk. While there is a systemd-repart.service that runs on boot, it's configured to not do anything if no config files are shipped with the system or provided by the user. As such, the service, if enabled, will effectively be a noop. Aside from the service, there's the CLI tool systemd-repart and the accompanying man pages that will be shipped as part of the systemd package.
Given that there's no risk involved with enabling systemd-repart, and given the useful features it provides, the systemd/mkosi developers would like to request that systemd-repart be enabled in Ubuntu and backported to Jammy so that they can start adopting it in mkosi.
Runtime behavior of existing components is not affected by the build config change. |
[Impact]
systemd-repart is not (as of 246.6-1ubuntu1) packaged in the Ubuntu/Debian packages of systemd - probably because it has an extra dependency?
The bug reporter would like to use it in their new raspberry pi images where they don't have cloud-init installed. The reporter is already using systemd-growfs, but they are missing the nice partition resizing part (so are using cloud-initramfs-growroot).
Furthermore, in the mkosi image builder (https://github.com/systemd/mkosi), the systemd/mkosi developers would like to start using systemd-repart for partitioning. Unfortunately, they're currently blocked on this because 22.04 doesn't ship systemd-repart. The upstream CI uses Github Actions which runs on Ubuntu Jammy and will do so until the next Ubuntu LTS is released. If we have to wait for the next LTS to be released, we'll have to wait for a considerable amount of time before we're able to start using systemd-repart.
Being able to use systemd-repart will allow the systemd/mkosi developers to take advantage of its improved interface compared to sfdisk,
as well as its builtin protections against race conditions surrounding the use of loop devices. The systemd/mkosi developers expect to
be able to get rid of some nasty loop device failure in mkosi by using systemd-repart.
[Test Plan]
This is a missing extra executable. Once enabled it has self-tests in the build-time unit tests, and also a regression test in the autopkgtest 'upstream' suite.
* Attach build-logs showing the systemd-repart self-tests passing
* Attach autopkgtest logs showing the systemd-repart regression test passing
* Test upgrade-path Jammy->Kinetic to make sure systemd-repart is properly replaced by Kinetic's "systemd" binary package
[Where problems could occur]
Shipping systemd-repart will come with no additional risk. While there is a systemd-repart.service that runs on boot, it's configured to not do anything if no config files are shipped with the system or provided by the user. As such, the service, if enabled, will effectively be a noop. Aside from the service, there's the CLI tool systemd-repart and the accompanying man pages that will be shipped as part of the systemd package.
Given that there's no risk involved with enabling systemd-repart, and given the useful features it provides, the systemd/mkosi developers would like to request that systemd-repart be enabled in Ubuntu and backported to Jammy so that they can start adopting it in mkosi.
Runtime behavior of existing components is not affected by the build config change. |
|
| 2022-08-30 08:37:31 |
Lukas Märdian |
description |
[Impact]
systemd-repart is not (as of 246.6-1ubuntu1) packaged in the Ubuntu/Debian packages of systemd - probably because it has an extra dependency?
The bug reporter would like to use it in their new raspberry pi images where they don't have cloud-init installed. The reporter is already using systemd-growfs, but they are missing the nice partition resizing part (so are using cloud-initramfs-growroot).
Furthermore, in the mkosi image builder (https://github.com/systemd/mkosi), the systemd/mkosi developers would like to start using systemd-repart for partitioning. Unfortunately, they're currently blocked on this because 22.04 doesn't ship systemd-repart. The upstream CI uses Github Actions which runs on Ubuntu Jammy and will do so until the next Ubuntu LTS is released. If we have to wait for the next LTS to be released, we'll have to wait for a considerable amount of time before we're able to start using systemd-repart.
Being able to use systemd-repart will allow the systemd/mkosi developers to take advantage of its improved interface compared to sfdisk,
as well as its builtin protections against race conditions surrounding the use of loop devices. The systemd/mkosi developers expect to
be able to get rid of some nasty loop device failure in mkosi by using systemd-repart.
[Test Plan]
This is a missing extra executable. Once enabled it has self-tests in the build-time unit tests, and also a regression test in the autopkgtest 'upstream' suite.
* Attach build-logs showing the systemd-repart self-tests passing
* Attach autopkgtest logs showing the systemd-repart regression test passing
* Test upgrade-path Jammy->Kinetic to make sure systemd-repart is properly replaced by Kinetic's "systemd" binary package
[Where problems could occur]
Shipping systemd-repart will come with no additional risk. While there is a systemd-repart.service that runs on boot, it's configured to not do anything if no config files are shipped with the system or provided by the user. As such, the service, if enabled, will effectively be a noop. Aside from the service, there's the CLI tool systemd-repart and the accompanying man pages that will be shipped as part of the systemd package.
Given that there's no risk involved with enabling systemd-repart, and given the useful features it provides, the systemd/mkosi developers would like to request that systemd-repart be enabled in Ubuntu and backported to Jammy so that they can start adopting it in mkosi.
Runtime behavior of existing components is not affected by the build config change. |
[Impact]
systemd-repart is not (as of 246.6-1ubuntu1) packaged in the Ubuntu/Debian packages of systemd - probably because it has an extra dependency?
The bug reporter would like to use it in their new raspberry pi images where they don't have cloud-init installed. The reporter is already using systemd-growfs, but they are missing the nice partition resizing part (so are using cloud-initramfs-growroot).
Furthermore, in the mkosi image builder (https://github.com/systemd/mkosi), the systemd/mkosi developers would like to start using systemd-repart for partitioning. Unfortunately, they're currently blocked on this because 22.04 doesn't ship systemd-repart. The upstream CI uses Github Actions which runs on Ubuntu Jammy and will do so until the next Ubuntu LTS is released. If we have to wait for the next LTS to be released, we'll have to wait for a considerable amount of time before we're able to start using systemd-repart.
Being able to use systemd-repart will allow the systemd/mkosi developers to take advantage of its improved interface compared to sfdisk,
as well as its builtin protections against race conditions surrounding the use of loop devices. The systemd/mkosi developers expect to
be able to get rid of some nasty loop device failure in mkosi by using systemd-repart.
[Test Plan]
This is a missing extra executable. Once enabled it has self-tests in the build-time unit tests, and also a regression test in the autopkgtest 'upstream' suite.
* Attach (local) build-log showing the systemd-repart self-tests passing
* Attach autopkgtest logs showing the regression tests passing (especially TEST-58-REPART)
* Test upgrade-path Jammy->Kinetic to make sure systemd-repart is properly replaced by Kinetic's "systemd" binary package
[Where problems could occur]
Shipping systemd-repart will come with no additional risk. While there is a systemd-repart.service that runs on boot, it's configured to not do anything if no config files are shipped with the system or provided by the user. As such, the service, if enabled, will effectively be a noop. Aside from the service, there's the CLI tool systemd-repart and the accompanying man pages that will be shipped as part of the systemd package.
Given that there's no risk involved with enabling systemd-repart, and given the useful features it provides, the systemd/mkosi developers would like to request that systemd-repart be enabled in Ubuntu and backported to Jammy so that they can start adopting it in mkosi.
Runtime behavior of existing components is not affected by the build config change. |
|
| 2022-08-30 10:20:31 |
Lukas Märdian |
description |
[Impact]
systemd-repart is not (as of 246.6-1ubuntu1) packaged in the Ubuntu/Debian packages of systemd - probably because it has an extra dependency?
The bug reporter would like to use it in their new raspberry pi images where they don't have cloud-init installed. The reporter is already using systemd-growfs, but they are missing the nice partition resizing part (so are using cloud-initramfs-growroot).
Furthermore, in the mkosi image builder (https://github.com/systemd/mkosi), the systemd/mkosi developers would like to start using systemd-repart for partitioning. Unfortunately, they're currently blocked on this because 22.04 doesn't ship systemd-repart. The upstream CI uses Github Actions which runs on Ubuntu Jammy and will do so until the next Ubuntu LTS is released. If we have to wait for the next LTS to be released, we'll have to wait for a considerable amount of time before we're able to start using systemd-repart.
Being able to use systemd-repart will allow the systemd/mkosi developers to take advantage of its improved interface compared to sfdisk,
as well as its builtin protections against race conditions surrounding the use of loop devices. The systemd/mkosi developers expect to
be able to get rid of some nasty loop device failure in mkosi by using systemd-repart.
[Test Plan]
This is a missing extra executable. Once enabled it has self-tests in the build-time unit tests, and also a regression test in the autopkgtest 'upstream' suite.
* Attach (local) build-log showing the systemd-repart self-tests passing
* Attach autopkgtest logs showing the regression tests passing (especially TEST-58-REPART)
* Test upgrade-path Jammy->Kinetic to make sure systemd-repart is properly replaced by Kinetic's "systemd" binary package
[Where problems could occur]
Shipping systemd-repart will come with no additional risk. While there is a systemd-repart.service that runs on boot, it's configured to not do anything if no config files are shipped with the system or provided by the user. As such, the service, if enabled, will effectively be a noop. Aside from the service, there's the CLI tool systemd-repart and the accompanying man pages that will be shipped as part of the systemd package.
Given that there's no risk involved with enabling systemd-repart, and given the useful features it provides, the systemd/mkosi developers would like to request that systemd-repart be enabled in Ubuntu and backported to Jammy so that they can start adopting it in mkosi.
Runtime behavior of existing components is not affected by the build config change. |
[Impact]
systemd-repart is not (as of 246.6-1ubuntu1) packaged in the Ubuntu/Debian packages of systemd - probably because it has an extra dependency?
The bug reporter would like to use it in their new raspberry pi images where they don't have cloud-init installed. The reporter is already using systemd-growfs, but they are missing the nice partition resizing part (so are using cloud-initramfs-growroot).
Furthermore, in the mkosi image builder (https://github.com/systemd/mkosi), the systemd/mkosi developers would like to start using systemd-repart for partitioning. Unfortunately, they're currently blocked on this because 22.04 doesn't ship systemd-repart. The upstream CI uses Github Actions which runs on Ubuntu Jammy and will do so until the next Ubuntu LTS is released. If we have to wait for the next LTS to be released, we'll have to wait for a considerable amount of time before we're able to start using systemd-repart.
Being able to use systemd-repart will allow the systemd/mkosi developers to take advantage of its improved interface compared to sfdisk,
as well as its builtin protections against race conditions surrounding the use of loop devices. The systemd/mkosi developers expect to
be able to get rid of some nasty loop device failure in mkosi by using systemd-repart.
[Test Plan]
This is a missing extra executable. Once enabled it has self-tests in the build-time unit tests, and also a regression test in the autopkgtest 'upstream' suite.
* Attach (local) build-log showing the systemd-repart self-tests passing, as found in build-deb/meson-logs/testlog.txt
* Attach autopkgtest logs showing the regression tests passing (especially TEST-58-REPART from "upstream-2" testsuite)
* Test upgrade-path Jammy->Kinetic to make sure systemd-repart is properly replaced by Kinetic's "systemd" binary package
[Where problems could occur]
Shipping systemd-repart will come with no additional risk. While there is a systemd-repart.service that runs on boot, it's configured to not do anything if no config files are shipped with the system or provided by the user. As such, the service, if enabled, will effectively be a noop. Aside from the service, there's the CLI tool systemd-repart and the accompanying man pages that will be shipped as part of the systemd package.
Given that there's no risk involved with enabling systemd-repart, and given the useful features it provides, the systemd/mkosi developers would like to request that systemd-repart be enabled in Ubuntu and backported to Jammy so that they can start adopting it in mkosi.
Runtime behavior of existing components is not affected by the build config change. |
|
| 2022-09-05 08:56:43 |
Łukasz Zemczak |
systemd (Ubuntu Jammy): status |
Confirmed |
Fix Committed |
|
| 2022-09-05 08:56:45 |
Łukasz Zemczak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2022-09-05 08:56:46 |
Łukasz Zemczak |
bug |
|
|
added subscriber SRU Verification |
| 2022-09-05 08:56:48 |
Łukasz Zemczak |
tags |
rls-jj-incoming |
rls-jj-incoming verification-needed verification-needed-jammy |
|
| 2022-09-05 08:59:27 |
Łukasz Zemczak |
removed subscriber Ubuntu Sponsors Team |
|
|
|
| 2022-09-14 14:57:12 |
Nick Rosbrook |
tags |
rls-jj-incoming verification-needed verification-needed-jammy |
verification-done verification-done-jammy |
|
| 2022-09-22 09:08:57 |
Launchpad Janitor |
systemd (Ubuntu Jammy): status |
Fix Committed |
Fix Released |
|
| 2022-09-22 09:09:15 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
