Bug 2141140
Summary: | Services fail on startup, service enablement does not work correctly, and gnome-initial-setup disappears on UEFI boots - all Rawhide Silverblue with systemd 252 | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Adam Williamson <awilliam> |
Component: | systemd | Assignee: | systemd-maint |
Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | rawhide | CC: | fedoraproject, filbranden, flepied, lnykryn, msekleta, ryncsn, ssahani, s, systemd-maint, walters, yaneti, yuwatana, zbyszek |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | openqa | ||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2022-12-09 20:28:27 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Adam Williamson
2022-11-08 22:47:19 UTC
CCing Colin for the rpm-ostree angle here. There is a likely-related problem in another test. In that test, we test service manipulation - starting, stopping, enabling, and disabling services. One test is to do `systemctl disable chronyd.service` , verify that it seems to be disabled, reboot, and check whether it started. That test also fails - see e.g. https://openqa.fedoraproject.org/tests/1577076 . Running `systemd disable chronyd.service` produces the expected output saying /etc/systemd/system/multi-user-target.wants/chronyd.service was removed, and running `systemctl is-enabled chronyd.service` says it's disabled, but on reboot, it gets started. Again, I can reproduce this locally, and it's not happening on non-ostree-based editions, only on Silverblue. Another problem that appeared at exactly the same time, and also only seems to affect Silverblue, is that the install-on-UEFI test started failing: https://openqa.fedoraproject.org/tests/1579101# . The install process runs perfectly normally, but the installed system boots to a black screen. If you watch the video - https://openqa.fedoraproject.org/tests/1579101/video?filename=video.ogv - it seems there's a very brief flash of the desktop background before it black screens. ctrl-alt-f6 does not get to a tty (or else the test would be able to upload logs at the end). Not 100% sure these are all the same problem, but at least the timing and the specific impact only on Silverblue seems to suggest it's likely... > So, I suspect something off in systemd 252's interaction with rpm-ostree-based installs here. Hm, probably related to this from 252: > * Systemd can optionally do a full preset in the "first boot" condition (instead of just enable-only). This behaviour is controlled by the compile-time option -Dfirst-boot-full-preset. Right now it defaults to 'false', but the plan is to switch it to 'true' for the subsequent release. And see https://src.fedoraproject.org/rpms/systemd/blob/rawhide/f/systemd.spec#_504 The UEFI bug I can also reproduce locally. I see the first-run wizard for a few seconds, then a black screen with flashing cursor. I *can* get a console on tty3, but of course I can't log into it - at this point in a Silverblue install there's no root password or user account. `systemd.debug-shell=1`, which should start a root shell on tty9, doesn't seem to work - don't know if that's another element of this bug, or if it just never works on Silverblue, or what. enforcing=0 does not seem to help with the UEFI bug (as it doesn't with dbus-daemon.service). Ping? any progress here? It's rather a significant bug, and it's still affecting Rawhide. I want to enable a test on updates that builds an ostree installer image and tests it, but it's going to fail for UEFI on every Rawhide update if we don't fix this, which would be a shame. I also see the failed services on my personal Silverblue laptop after rebasing it to Rawhide. The system boots to a login screen, but the first attempt to log in often immediately cycles back to GDM, and a second often hangs. If I do reach a working desktop I've seen it hang after that too. If nobody replies to this bug soon, I'm going to build systemd with the new feature disabled and see what happens. Sorry for the slow response. I don't know enough about silverblue to diagnose this.
> Hm, probably related to this from 252:
>> * Systemd can optionally do a full preset in the "first boot" condition
That change was done exactly because it was requested by ostree folks. Maybe it is related,
but I'm not sure. There were many other changes in v252…
Some real debug logs would be useful. Adam: can you post the full log, not just the avcs?
Please also check with v252.3 that should build later today. I suspect #2136916. Thanks. I'll check with 252.3 and if that doesn't fix it, get some more logs. I did notice that after rebasing my Silverblue install to Rawhide, then rebasing back to F37 after running into this bug, I'm pretty sure the state of some services (like sshd) changed - I had it enabled, it went to disabled. It does indeed look like 252.3 fixed this - all the related tests passed on Rawhide today, they were consistently failing before. Thanks. *** This bug has been marked as a duplicate of bug 2136916 *** |