I think at most we should revert the specific patch that’s at fault. It’s far too close to release to do an entire systemd rollback; we actually probably can’t ship a different systemd with the final release at all since we’re already far into the last staging-next cycle before release (though we might be able to get a patch in within the first few weeks after release). As far as I know the issue has only been observed on platforms with 16K pages, which we don’t really officially support (since none of our shipped kernels do), though if the incorrectness is observable on any 4K platforms then that would certainly make it more serious.

Yea, we absolutely are not going to rollback the entire systemd version when it's only been observed as an issue on one platform. I'd be fine with shipping a revert of the offending patch (we already do that for one other issue), but rolling back systemd entirely is way too extreme of a solution.

Besides my Macbook (which cannot run stock NixOS) I only have a common x86 machine available to test, where the release works fine.

Besides the page size problem, from the discussion in the issue the release should be broken on any platform without physical memory available below the 4G physical address--this is uncommon, but is allowed by the x86-64 spec. @mzyngier mentioned that his Opteron A1100 from 2014 would be broken, but I do not have one on hand to verify (I replied asking him to confirm whether he can reproduce the issue).

The specific problematic commit would be this one; reverting it has been verified by @andre4ik3 to fix the problem.

Ultimately whatever we do is going to have to land within the first few weeks post‐release, unless we decide to significantly delay the release for this, which seems unlikely when the main issue is on unsupported platforms and supported hardware that may be susceptible to the issue is very rare. systemd changes have to go through staging and the current staging-next cycle is already a few days late relative to the release schedule, so our only option to address this is throwing a revert of the patch into staging and waiting for the first post‐24.11 cycle to run.

#355290

I think at most we should revert the specific patch that’s at fault. It’s far too close to release to do an entire systemd rollback; we actually probably can’t ship a different systemd with the final release at all

Agreed, if this was earlier then I wouldn't reject this but at this point, we probably should only revert the specific commit in systemd. There's already a revert patch from the issue thread (systemd/systemd#35026 (comment)). We probably could get that into staging-next and revert it after 24.11 branch off.

Edit: didn't see Alyssa's comment appear until after I made this comment.

We cannot put it into staging-next, it’s way too far into the cycle. It can go into the first backport cycle after release.

Oh ok, I didn't know that. Also didn't see that comment you posted after Alyssa made the PR until I posted my comment.

Closing in favor of #355290