** Description changed: In Ubuntu Core 20, and Ubuntu Core 22, we are encountering an issue where if a service, started earlier than devices are processed by udev, does `systemctl daemon-reload`, the system shuts down. This is due to devices for mounted filesystem temporarily taken dead, which pulls most units down. This was fixed by upstream in https://github.com/systemd/systemd/pull/23218. But this was not backported to the versions used by Ubuntu packages for focal and jammy. The needed commit from that PR is the one with message `core/device: ignore DEVICE_FOUND_UDEV bit on switching root`. This patch applies to 245.4-4ubuntu3.22 (focal) without rebasing needed. And I suppose it does also for jammy. I have manually tested the fix with Ubuntu Core 20, and this fixes our issue. We would like this patch to be backported to focal-updates and jammy- updates. Thank you in advance. + + + [ Impact ] + * An explanation of the effects of the bug on users and + * justification for backporting the fix to the stable release. + * In addition, it is helpful, but not required, to include an + explanation of how the upload fixes this bug. + + [ Test Plan ] + * detailed instructions how to reproduce the bug + * these should allow someone who is not familiar with the affected + package to reproduce the bug and verify that the updated package fixes + the problem. + * if other testing is appropriate to perform before landing this update, + this should also be described here. + + [ Where problems could occur ] + * Think about what the upload changes in the software. Imagine the change is + wrong or breaks something else: how would this show up? + * It is assumed that any SRU candidate patch is well-tested before + upload and has a low overall risk of regression, but it's important + to make the effort to think about what ''could'' happen in the + event of a regression. + * This must '''never''' be "None" or "Low", or entirely an argument as to why + your upload is low risk. + * This both shows the SRU team that the risks have been considered, + and provides guidance to testers in regression-testing the SRU. + + [ Other Info ] + * Anything else you think is useful to include + * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board + * and address these questions in advance
-- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/2037281 Title: Shutdown when triggering daemon-reload eary in boot Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: New Status in systemd source package in Jammy: New Bug description: In Ubuntu Core 20, and Ubuntu Core 22, we are encountering an issue where if a service, started earlier than devices are processed by udev, does `systemctl daemon-reload`, the system shuts down. This is due to devices for mounted filesystem temporarily taken dead, which pulls most units down. This was fixed by upstream in https://github.com/systemd/systemd/pull/23218. But this was not backported to the versions used by Ubuntu packages for focal and jammy. The needed commit from that PR is the one with message `core/device: ignore DEVICE_FOUND_UDEV bit on switching root`. This patch applies to 245.4-4ubuntu3.22 (focal) without rebasing needed. And I suppose it does also for jammy. I have manually tested the fix with Ubuntu Core 20, and this fixes our issue. We would like this patch to be backported to focal-updates and jammy- updates. Thank you in advance. [ Impact ] * An explanation of the effects of the bug on users and * justification for backporting the fix to the stable release. * In addition, it is helpful, but not required, to include an explanation of how the upload fixes this bug. [ Test Plan ] * detailed instructions how to reproduce the bug * these should allow someone who is not familiar with the affected package to reproduce the bug and verify that the updated package fixes the problem. * if other testing is appropriate to perform before landing this update, this should also be described here. [ Where problems could occur ] * Think about what the upload changes in the software. Imagine the change is wrong or breaks something else: how would this show up? * It is assumed that any SRU candidate patch is well-tested before upload and has a low overall risk of regression, but it's important to make the effort to think about what ''could'' happen in the event of a regression. * This must '''never''' be "None" or "Low", or entirely an argument as to why your upload is low risk. * This both shows the SRU team that the risks have been considered, and provides guidance to testers in regression-testing the SRU. [ Other Info ] * Anything else you think is useful to include * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board * and address these questions in advance To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2037281/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
