Bug 1872068 - zram-swap.service: Failed to load configuration: No such file or directory
Summary: zram-swap.service: Failed to load configuration: No such file or directory
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 33
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker AcceptedFreezeException
: 1871986 (view as bug list)
Depends On:
Blocks: BetaFreezeException, F33BetaFreezeException
TreeView+ depends on / blocked
 
Reported: 2020-08-24 23:45 UTC by Artem
Modified: 2020-09-08 17:04 UTC (History)
16 users (show)

Fixed In Version: systemd-246.4-1.fc33
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-09-08 17:04:26 UTC
Type: Bug


Attachments (Terms of Use)
journal (34.76 KB, application/x-xz)
2020-08-24 23:45 UTC, Artem
no flags Details

Description Artem 2020-08-24 23:45:37 UTC
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'.

Comment 1 Adam Williamson 2020-08-25 00:17:26 UTC
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?

Comment 2 Artem 2020-08-25 00:32:29 UTC
> 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

Comment 3 Adam Williamson 2020-08-25 05:07:10 UTC
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?

Comment 4 Artem 2020-08-25 06:52:33 UTC
> 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.

Comment 5 Adam Williamson 2020-08-25 15:41:14 UTC
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.

Comment 6 Zbigniew Jędrzejewski-Szmek 2020-08-25 16:02:40 UTC
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.

Comment 7 Adam Williamson 2020-08-25 17:08:42 UTC
*** Bug 1871986 has been marked as a duplicate of this bug. ***

Comment 8 Adam Williamson 2020-08-25 17:12:40 UTC
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.

Comment 9 Kamil Páral 2020-08-26 11:32:00 UTC
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.

Comment 10 Zbigniew Jędrzejewski-Szmek 2020-08-26 13:43:48 UTC
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.)

Comment 11 Zbigniew Jędrzejewski-Szmek 2020-08-26 15:42:05 UTC
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/.

Comment 12 Geoffrey Marr 2020-08-31 17:20:25 UTC
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

Comment 13 Fedora Update System 2020-09-02 11:07:24 UTC
FEDORA-2020-2255b438a2 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-2255b438a2

Comment 14 Fedora Update System 2020-09-02 16:20:24 UTC
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.

Comment 15 Fedora Update System 2020-09-08 17:04:26 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.