OK, progress of sorts. We now get the graphical environment on the console, and the needles expect a text login. Hmm.

Hmm, so in the logs I see:

template line 19: symlink anaconda-shell@.service lib/systemd/system/autovt@.service

The symlink in /etc would have higher priority and it'll make that hack have no effect.

I'll undo the change in systemd for now.

And it seems that now all the logs from those tests have disappeared. I'll retrigger some of the tests to get an updated result.

I don't understand what is going on here. When I do dnf install --installroot=… with systemd-259-9.fc44, and then the same with systemd-259-14.fc44, the result is not identical, because of a few bugs (the enablement scripts were not called for some units, then in -14 the getty@tty1 symlink is dropped, etc). But in systemd-259-11.fc44, the symlink for getty@tty1 was present, and the result was the same. The other units that are systemd-pstore.service, systemd -oomd.socket, remote-veritysetup.taget, systemd-homed-activate.service, some dbus aliases; nothing that should cause any difference. On a "good VM", many of those units are active anyway, because they are pulled in through dependencies. In one case, we have /usr/lib/systemd/system/autovt@.service, in the other /etc/systemd/system/autovt@.service. Systemd should treat those as exactly equivalent.

I fixed the issue with getty@.service not being enabled. In local testing with 'dnf install' and 'rpm -i' the unit get preset and enabled properly. But the tests fail in the same way — a blank tty screen. I have one more idea what to test, so I'll do another build.

Yeah, it seems that the getty@.service unit does not get enabled. I was debugging this yesterday and ran out of time. This update is definitely borked.

The CI failed because: Could not execute build: 502 Server Error: Bad Gateway for url: https://koji.fedoraproject.org/kojihub

Ah, wait, this is for f43 not rawhide. Pfff.

@dustymabe: I'm confused about the coreos failure. The patch to suppress that error was added in v259-rc1 and the status there hasn't changed in the two updates after that. And I confirmed that the sources in v259-rc3 still have the patched code. So either that patch is somehow incomplete or the testing is pulling in an older version. Either way, I don't this is is a regression from -rc2. And there is nothing in the list of patches between -rc2 and -rc3 that would seem relevant.

kiwi is failing with some loopback device access errors. I'm fairly sure this is not related. OK to waive?

Arrgh, it's using the old version:add-determinism x86_64 0.7.2-1.fc44 testing-farm-tag-repository 2.3 MiB

Ah, no, it went stable 2 days ago. I got the notification but apparently it wasn't done yet. I'll rebuild it again. Thanks for catching this.

I don't understand this. It built against older blosc2, but the update with the new blosc2 is shown by bodhi as having gone stable a week ago. Hmm.

https://github.com/systemd/systemd/pull/38859 hopefully fixes the issue.

@nucleo: can you post the more details (full boot log, scenario, the kernel command line)?

This is being handled in dracut: https://github.com/dracut-ng/dracut-ng/commit/fa17b6fb0e5a226a83588c2d8fdec5ff285f5eab

We still have selinux-policy-targeted-42.3-1.fc43 in the tests. We need 42.5-1.fc43. FEDORA-2025-c44989ea5a went stable 14 h ago. I thought it'd be available already. Need to wait for a compose?

Ah, no, https://github.com/systemd/systemd/commit/ef7698f7aa is just about a spurious message. So it doesn't seem that we're setting the quota incorrectly.

podman run fails with "disk quota exceeded" :( I saw a commit to systemd git about something something not setting quota when not configured something, so maybe it's a bug on our side.

The selinux policy and coreos tests have been patched. Let's see if the tests pass now.