Bug 1731598 - systemd presets request - zram-swap.service
Summary: systemd presets request - zram-swap.service
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: fedora-release
Version: 31
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Mohan Boddu
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2019-07-19 22:57 UTC by Bastien Nocera
Modified: 2020-01-04 10:24 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2019-07-22 10:32:08 UTC
Type: ---

Attachments (Terms of Use)

Description Bastien Nocera 2019-07-19 22:57:50 UTC
* Does the service require post-rpm-installation configuration in order to be useful (for example, does it need manual edits to a configuration file)?


* Does the service listen on a network socket for connections originating on a separate physical or virtual machine?


* Is the service non-persistent (i.e. run once at startup and exit)?


* What is the exact name (or names) of the systemd unit files to be enabled?


* Is this request for all Fedora deliverables or only for some Editions (list them)?


Comment 1 Bastien Nocera 2019-07-19 22:58:56 UTC
(In reply to Bastien Nocera from comment #0)
> * Is the service non-persistent (i.e. run once at startup and exit)?
> No

It is non-persistent, sorry

Comment 2 Stephen Gallagher 2019-07-19 23:03:29 UTC
Ok, thanks. That meets the requirements to skip FESCo, so I will go ahead and merge it.

Comment 3 Bastien Nocera 2019-07-22 16:56:46 UTC
Note: I might need to get this reopened and reverted, if the patches in:
get merged.

Comment 4 Bastien Nocera 2019-07-29 14:10:23 UTC
This needs to be reverted as it conflicts with https://github.com/rhinstaller/anaconda/pull/2039

Comment 5 Chris Murphy 2019-07-29 16:21:13 UTC
Short version:
There might be another way to solve this without reverting. I'll ask probinson what he thinks of this:

Longer explanation of the conflict:

This commit causes zram package's zram-swap.service to be enabled, and therefore creates swap on /dev/zram0 during early startup, including on LiveOS.

It hasn't landed in Rawhide yet, and even if it did the result is non-fatal.

What happens on LiveOS boots, is just some complaints from anaconda's own swap on zram (zram.service) trying to step on the zram0 device that this change creates during early boot (zram-swap.service).

If I simulate this commit by booting Fedora-Workstation-Live-x86_64-Rawhide-20190728.n.1.iso in a VM with `systemd.wants=zram-swap.service` and then launch Anaconda:

[root@localhost-live liveuser]# journalctl -b -o short-monotonic | grep zram
[   91.209105] localhost-live zramswapon[2218]: + MAX_RAM_ON=2097152
[   91.214632] localhost-live zramswapon[2218]: ++ grep MemTotal /proc/meminfo
[   91.215386] localhost-live zramswapon[2218]: ++ grep -E --only-matching '[[:digit:]]+'
[   91.224294] localhost-live zramswapon[2218]: + mem_total_kb=2008244
[   91.224490] localhost-live zramswapon[2218]: + grep -E 'inst\.zram=(on|1)' /proc/cmdline
[   91.229702] localhost-live zramswapon[2218]: + force=1
[   91.230093] localhost-live zramswapon[2218]: + '[' '(' 2008244 -gt 2097152 ')' -a '(' 1 '!=' 0 ')' ']'
[   91.231738] localhost-live zramswapon[2218]: ++ getconf _NPROCESSORS_ONLN
[   91.244345] localhost-live zramswapon[2218]: + num_cpus=4
[   91.244682] localhost-live zramswapon[2218]: + modprobe zram
[   91.254963] localhost-live zramswapon[2218]: + echo 4
[   91.256318] localhost-live zramswapon[2218]: + echo 2008244K
[   91.264951] localhost-live kernel: zram: Cannot change disksize for initialized device
[   91.257465] localhost-live zramswapon[2218]: /usr/libexec/anaconda/zramswapon: line 46: echo: write error: Device or resource busy
[   91.257716] localhost-live zramswapon[2218]: + mkswap /dev/zram0
[   91.280812] localhost-live zramswapon[2218]: mkswap: error: /dev/zram0 is mounted; will not make swapspace
[   91.281568] localhost-live zramswapon[2218]: + swapon -p 100 /dev/zram0
[   91.310634] localhost-live zramswapon[2218]: swapon: /dev/zram0: swapon failed: Device or resource busy
[   91.312003] localhost-live zramswapon[2218]: + '[' 2008244 -le 1048576 ']'
[   91.312431] localhost-live zramswapon[2218]: + exit 0

Basically, anaconda starts its own zram.service at launch (since a few Fedora releases on netinstalls, and starting with F31 for LiveOS which change just landed so there's no way bnocera could have known of the conflict) and because it's super simple, it just assumes it can setup swap on /dev/zram0, but there is already a swap setup there.

When I coordinated the change with anaconda folks, they wanted anaconda to start zram, because it's better for small RAM devices to fail during startup of the graphical environment, than for installation to succeed with zram, but then fail on reboot following installation because there was no zram.

Thing is, if we run into the problem that https://pagure.io/fedora-workstation/issue/98 is trying to solve, eventually the kernel is just going to spill over abruptly into that legacy swap on a conventional drive because the Anaconda creatd swap volume still exists along with this new swap on zram device.

Comment 6 Ben Cotton 2019-08-13 16:49:20 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to '31'.

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