Created attachment 1712451 [details] journal Description of problem: After upgrade to f33 from f32 can't boot my system anymore because of this errors during boot: zram-swap.service: Failed to load configuration: No such file or directory Sent message type=signal sender=n/a destination=n/a path=/org/freedesktop/systemd1/unit/zram_2dswap_2eservice interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=1434189 reply_cookie=0 signature=sa{sv}as error-name=n/a error-message=n/a Version-Release number of selected component (if applicable): zram-0.4-1.fc32 How reproducible: Do system upgrade from f32 -> f33. Actual results: System won't boot anymore. Expected results: Successful boot and functional system. Additional info: Note #1: The issue is very similar to this one https://bugzilla.redhat.com/show_bug.cgi?id=1871986 Note #2: Could been fixed by manually removing 'etc/systemd/system/swap.target.wants/zram-swap.service' symlink which points to non-existent '/usr/lib/systemd/system/zram-swap.service' Note #3: Attached full journal log with 'debug'.
I'm not seeing either of your issues in openQA tests, which do a clean F32 install and upgrade to F33. Those are passing. Do you know how the offending units actually came to exist on your system?
> Do you know how the offending units actually came to exist on your system? 'zram' package was manually installed on this system for a long time ago and just recently, before upgrade to f33, i decided to remove it since it was superseded by 'zram-generator' package in f33. Even found my DNF transaction: Transaction ID : 3618 Begin time : Tue 18 Aug 2020 01:29:10 PM EEST Begin rpmdb : 2592:5a0cb97154bb38a746da85a0f7e3253898df03ea End time : Tue 18 Aug 2020 01:29:11 PM EEST (1 seconds) End rpmdb : 2591:ac3b33951af90363ee122ef1cb9fbde44023f0e6 User : Artem <tim> Return-Code : Success Releasever : 32 Command Line : remove zram -y Comment : Packages Altered: Removed zram-0.4-1.fc32.noarch @@System
hmm, okay. and you probably did 'systemctl enable zram-swap' or something at some point too? I wonder if this is systemd treating something - an 'enablement' link in /etc/systemd/system pointing to a service that longer exists - as fatal when previously it was only a warning? as this seems like the sort of thing that would happen fairly often, but I don't recall reading about it failing boot before... zbigniew, any thoughts?
> hmm, okay. and you probably did 'systemctl enable zram-swap' or something at some point too? Yep, many times did enable/disable, start/stop 'zram-swap' service, but never had any issue with and using it for a long time. This is first time happened right after update from f32 to f33. > but I don't recall reading about it failing boot before... +1. Never happened for me before. Could this something changed, behavior in new systemd itself? Also as for my similar issue with 'lvm2' service - only once i tried to disable after reading this devel thread https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/OW5YS443BGRO5E47SOPHDHM7FH2C2DLX/#25HDN5YGGF4ZXR2EI7PCW6G45FA3SBWZ and everything was OK on f32.
yeah, that's exactly what I meant, I'm wondering if it's a behaviour change in systemd. I CC'ed Zbigniew, the systemd maintainer, for input.
Failing to load the unit is not the problem. Apart from the warning, the effect depends on what depends on the unit. In this case, the unit is pulled in through a symlink in .wants/, so we'd just get a warning and nothing else. The problem instead is that systemd tries to load the unit in a tight loop. The underlying cause might be the same as #1867930. We are trying to figure that one out, and there are some ideas. But let's keep both open until it's clear that they share the same cause.
*** Bug 1871986 has been marked as a duplicate of this bug. ***
For the record, reporter also had a very similar issue with lvm2-lvmetad.socket , that's the dupe. Re-assigning to systemd for now as it seems more likely this is to do with systemd than the actual units.
I tried to replicate this. I enabled zram-swap.service on F32, uninstalled zram package, made sure the dangling symlink was present, and upgraded to F33. F33 booted several times without issue, I couldn't hit this.
Yeah, I cannot reproduce this either. Various people find it easy to hit, there's probably some additional condition which we're missing. After some upstream discussion we found one suspicious patch. In https://copr.fedorainfracloud.org/coprs/zbyszek/systemd/build/1635482/ there's build systemd-246.3-2 that reverts the patch. It is otherwise the same as systemd-246.3-1 in rawhide/f33 right now. It would be great if someone who can reproduce the issue checked whether it still occurs with systemd-246.3-2. (And if *not*, then whether it still occurs with systemd-246.3-1.)
The copr build failed. https://copr.fedorainfracloud.org/coprs/zbyszek/systemd/build/1635567/ is the replacement for https://copr.fedorainfracloud.org/coprs/zbyszek/systemd/build/1635482/.
Discussed during the 2020-08-31 blocker review meeting: [0] The decision to classify this bug as a "RejectedBlocker" and an "AcceptedFreezeException" was made on the grounds that it's not reproducible from a clean install/upgrade scenario, which is what the criteria cover. Accepted as an FE as this is a serious bug for folks who happen to be in whatever state triggers it (we're not sure yet). [0] https://meetbot.fedoraproject.org/fedora-blocker-review/2020-08-31/f33-blocker-review.2020-08-31-16.00.txt
FEDORA-2020-2255b438a2 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-2255b438a2
FEDORA-2020-2255b438a2 has been pushed to the Fedora 33 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-2255b438a2` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-2255b438a2 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-2255b438a2 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.
Bug fixed, commonbugs not needed.