On Fri, 2024-04-26 at 18:59 +0200, Lennart Poettering wrote: > eOn Fr, 26.04.24 09:05, Adam Williamson (adamwill@xxxxxxxxxxxxxxxxx) wrote: > > > On Fri, 2024-04-26 at 07:36 +0000, Zbigniew Jędrzejewski-Szmek wrote: > > > Hi, > > > > > > systemd-256~rc1 is building in rawhide. This is a major update, > > > in development for 5 months. We've been doing continuous builds > > > and testing of the development versions in rawhide, but bugs > > > are possible (even likely). Plese report issues in bugzilla or > > > here. > > > > It doesn't boot. That seems like an issue. :D > > https://bodhi.fedoraproject.org/updates/FEDORA-2024-54b3646daf#comment-3506797 > > I guess this is triggered by the new ProtectSystem= feature that you > can configure in /etc/systemd/system.conf. See NEWS file. > > It ensures that /usr/ is marked ready-only during earliest > initialization in PID 1. It defaults to off on the final system, but > to on in initrds, and that appears to trip off dracut. > > I don't know why dracut wants to write around in /usr/, but it seems > very wrong it tries to do that. > > Anyway, a quick work-around is to set the knob to false in the > initrd. But a proper fix is to make dracut not patch around in /usr/ > during runtime. Writing to /usr/ should be off limits for anything > that isn't really a package manager (and maybe very few other > exceptions). Well, it really wants to write to /lib , not to /usr. But of course, on Fedora, /lib is /usr/lib . The specific error I can see in the openQA output is triggered here: https://github.com/dracutdevs/dracut/blob/master/modules.d/98dracut-systemd/parse-root.sh#L28 $hookdir , there, is /lib/dracut/hooks . This is a mechanism used all through dracut - it writes hooks into that directory under all sorts of circumstances. I don't know how disruptive it would be to make it a different directory. CCing pvalena. Another thing I discovered testing this locally: the bug only shows up once the initramfs is regenerated. If you just update systemd alone and reboot, system boots fine. As it happens, all the openQA tests run into the bug because there is a kernel update available since their base disk images were last regenerated, so in the same update transaction as the systemd update being tested, they get a kernel update, and the initramfs gets regenerated. But even if that weren't the case, we would have caught the bug with the advisory_boot test, which rebuilds the initramfs after installing the update and tests that the system still boots, specifically to catch cases like this. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw@xxxxxxxxxxxxx https://www.happyassassin.net -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
