2:36 a.m.
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.
Zbyszek
11:05 a.m.
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-35...
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org
https://www.happyassassin.net
11:59 a.m.
eOn Fr, 26.04.24 09:05, Adam Williamson (adamwill(a)fedoraproject.org) 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-35...
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).
Lennart
--
Lennart Poettering, Berlin
2:57 p.m.
On Fri, 2024-04-26 at 18:59 +0200, Lennart Poettering wrote:
eOn Fr, 26.04.24 09:05, Adam Williamson (adamwill(a)fedoraproject.org)
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-35...
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-syste...
$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(a)fosstodon.org
https://www.happyassassin.net
36
days inactive
38
days old
4 comments
4 participants
participants (4)
-
Adam Williamson -
Kevin Kofler -
Lennart Poettering -
Zbigniew Jędrzejewski-Szmek