F33: preview swap-on-ZRAM using zram-generator feature change

[Chris Murphy]

Hi,

I'm following-up now that there's a preview of the change proposal ready:
https://fedoraproject.org/wiki/Changes/SwapOnZRAM

Highlights:

- This is a system-wide change, for all editions and spins. And if
Anaconda folks are still agreeable, it would be included on all
install media where Anaconda is found: DVD/Live/netinstall.

- Fedora Workstation edition will no longer create swap-on-disk by
default. Instead swap-on-zram will be used. I expect to get buy-in
from other editions/spins to do the same. This applies only to the
default/automatic partitioning path, as previously discussed.

- Tentative (proposed) defaults similar to what's used by IoT: ZRAM
device is 50% RAM, with a 4GiB cap.

The max size, which is configurable, is to help scale ZRAM device size
for more uses cases and hopefully settle on a single default Fedora
wide. This is a bit different than Anaconda's implementation, which
doesn't activate above 2GiB, and uses a 1:1 ZRAM to RAM ratio. Based
on my testing, even VM's with 3GiB RAM still prefer to use quite a
decent amount of swap ~200MiB. If it's available. I think this
adjustment is neutral to slightly better for Anaconda. And in any case
the installer and installed environments will have the same
configuration and implementation as a result of the change.

- Disable or somehow deprecate the Anaconda specific implementation,
to avoid conflict and user confusion among the implementations.

- Test day will be planned

Critical feedback welcome.

[Chris Murphy]

Found this:
https://github.com/rhinstaller/anaconda/blob/master/scripts/zramswapon#L52

I'm not sure where that should live, if this script is removed.

--
Chris Murphy

[Patrick Riehecky]

Could we have lorax enable the systemd unit 'tmp.mount' or have the
anaconda service require it?

Pat

On Mon, 2020-06-01 at 09:43 -0600, Chris Murphy wrote:
> Found this:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_rhinstaller_...
>
> I'm not sure where that should live, if this script is removed.
>
> --
> Chris Murphy
>
> Anaconda-devel-list mailing list
> [e-mail]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.redhat.com_mailman_...

[Martin Kolman]

----- Original Message -----
> From: "Chris Murphy" 
> To: "Discussion of Development and Customization of the Red Hat Linux Installer" 
> Sent: Sunday, May 31, 2020 2:45:37 AM
> Subject: F33: preview swap-on-ZRAM using zram-generator feature change
>
> Hi,
>
> I'm following-up now that there's a preview of the change proposal ready:
> https://fedoraproject.org/wiki/Changes/SwapOnZRAM
>
> Highlights:
> This is a system-wide change, for all editions and spins. And if
>
> Anaconda folks are still agreeable, it would be included on all
> install media where Anaconda is found: DVD/Live/netinstall.
> Fedora Workstation edition will no longer create swap-on-disk by
>
> default. Instead swap-on-zram will be used. I expect to get buy-in
> from other editions/spins to do the same. This applies only to the
> default/automatic partitioning path, as previously discussed.
> Tentative (proposed) defaults similar to what's used by IoT: ZRAM
>
> device is 50% RAM, with a 4GiB cap.
>
> The max size, which is configurable, is to help scale ZRAM device size
> for more uses cases and hopefully settle on a single default Fedora
> wide. This is a bit different than Anaconda's implementation, which
> doesn't activate above 2GiB, and uses a 1:1 ZRAM to RAM ratio. Based
> on my testing, even VM's with 3GiB RAM still prefer to use quite a
> decent amount of swap ~200MiB. If it's available. I think this
> adjustment is neutral to slightly better for Anaconda. And in any case
> the installer and installed environments will have the same
> configuration and implementation as a result of the change.

Back when ZRAM support was introduced in the installation environment the
aim was to enable installations and specially the more memory hungry graphical
installations on devices and VMs with less RAM. For devices with enough RAM
the installation could run just fine & ZRAM would be just extra overhead, so
we decided not to enable it here.

This was quite some time ago (6/7 years ago) and things certainly changed,
making the ZRAM overhead very likely totally negligible on current systems.

So I think dropping the conditions we have at the moment and simply always enabling ZRAM
with sensible configuration (like the IoT one mentioned above) should be fine.
> Disable or somehow deprecate the Anaconda specific implementation,
>
> to avoid conflict and user confusion among the implementations.

IIRC we discussed using one of the scripts packaged in Fedora 
(I think it was provided by systemd ?), ideally the one used by the other
tools that are part of this system wide change. We just have not did that
just yet.

So I wonder if the image wide defaults change I guess it should be enough
if we coordinate dropping of our zram setup script at the same time the image 
wide change is done ?
> Test day will be planned
>
> Critical feedback welcome.
>
> --
> Chris Murphy
>
> Anaconda-devel-list mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list

[Chris Murphy]

On Tue, Jun 2, 2020 at 9:47 AM Martin Kolman  wrote:
> Back when ZRAM support was introduced in the installation environment the
> aim was to enable installations and specially the more memory hungry graphical
> installations on devices and VMs with less RAM. For devices with enough RAM
> the installation could run just fine & ZRAM would be just extra overhead, so
> we decided not to enable it here.
>
> This was quite some time ago (6/7 years ago) and things certainly changed,
> making the ZRAM overhead very likely totally negligible on current systems.

Upstream zram doc claims the overhead is 0.1% of the /dev/zram0 device
size. e.g. ~64M/64G. In practice I haven't seen it use more than
0.04%, but perhaps it has some float as the /dev/zram0 device is
actually being used, for tracking. In any case it's not much. I don't
want the /dev/zram0 device to be too big by default, just in case some
workloads have unexpectedly low compressibility, and I'd like to be
conservative in order to ideally make it possible to apply it to
upgrades. And perhaps in F34 with new clean installs, get a bit more
aggressive if actual usage with F33 suggests it's a good idea.
> So I think dropping the conditions we have at the moment and simply always enabling ZRAM
> with sensible configuration (like the IoT one mentioned above) should be fine.

OK cool.
> > Disable or somehow deprecate the Anaconda specific implementation,
> >
> > to avoid conflict and user confusion among the implementations.
>
> IIRC we discussed using one of the scripts packaged in Fedora
> (I think it was provided by systemd ?), ideally the one used by the other
> tools that are part of this system wide change. We just have not did that
> just yet.

Yeah it's hard to find. In koji it's rust-zram-generator metapackage;
but the actual command to try it out is 'dnf install zram-generator'.

https://github.com/systemd/zram-generator
> So I wonder if the image wide defaults change I guess it should be enough
> if we coordinate dropping of our zram setup script at the same time the image
> wide change is done ?

Yes, I can help coordinate. I'll be doing the kickstart change to
bring zram-generator and configuration file into the ISOs.

Prior testing suggests two zram devices being created isn't a big
deal, in practice they get different swap priorities, so only one will
be used, there's just that 0.1% (or 0.04%) overhead for the unneeded
extra /dev/zram device. Also it's not a preallocation. So if that
scenario were to happen, it wouldn't cause openQA tests to face plant.
The openQA tests I think are the most likely impacted, if there are
two zram devices, since most of those VMs use 2G RAM and thus will
trigger the anaconda implementation to also create a zram device.

For most everyone else doing testing, they'll have more than 2G RAM
for their VM or baremetal and are unlikely to run into this.

Thanks!

[Chris Murphy]

On Tue, Jun 2, 2020 at 10:13 AM Chris Murphy  wrote:
> Yeah it's hard to find. In koji it's rust-zram-generator metapackage;
> but the actual command to try it out is 'dnf install zram-generator'.

I should have just pointed to this:
https://fedoraproject.org/wiki/Changes/SwapOnZRAM#How_To_Test

Right now there's a few steps, since the default is to not install a
configuration file.

[Chris Murphy]

Also, just to underscore the scope of this feature. It does propose
dropping the swap partition by default for all Fedora editions and
spins. It would still be possible for users to create a (regular)
swap-on-disk partition, and Anaconda would still add the appropriate
resume=UUID= kernel parameter.

This is item #3 in the summary.
https://fedoraproject.org/wiki/Changes/SwapOnZRAM

Vendula Poncova explains some things in this comment that relate to
the installer UI and dropping the swap-on-disk partition by default.
https://pagure.io/fedora-workstation/issue/121#comment-655592

Also related, and referenced in the feature, and posted to devel@
list: "Supporting hibernation in Workstation ed., draft 2"
https://pagure.io/fedora-workstation/blob/master/f/hibernationstatus.md

It's short, maybe two pages with references. Idea is to summarize the
most central issues and the way forward. The references lead to quite
a lot of  conversations and additional references. Also it's likely
permanently a draft because, well things are always changing, the
story doesn't yet have a conclusion. But in the meantime we need to
move forward the best we can.

---
Chris Murphy

[Chris Murphy]

Hi,

This change has been approved. There are still some details to work
out. What do Anaconda folks think for the custom partitioning use case
where the use manually creates disk-based swap? Should and could the
installer then also do:

'touch /etc/systemd/zram-generator.conf'

post install? The effect is to disable the zram-generator and there'd
be only disk-based swap. The alternative outcome without this is
they'll have both swap-on-zram with a higher priority than the
swap-on-disk they created.

I'm open to suggestions. I think it's mainly a question about what you
think the user expects in this situation. That's hard to answer
because the user expects disk based swap as a long standing
convention. And there is no convention for either swap-on-zram yet, or
two swap devices, even though the kernel has supported up to 32 swap
devices since forever.

The best experience performance wise would be to have the two swaps.
They gain from swap-on-zram at first, and perhaps mostly. Followed by
the secondary use of disk based swap. But I'm not opposed to disabling
zram-generator in this case. It is a more conservative option and
might better square with expectations.

Thanks,

Chris Murphy

[Vendula Poncova]

On Sun, Jun 28, 2020 at 10:10 PM Chris Murphy 
wrote:
> Hi,
>
> This change has been approved. There are still some details to work
> out. What do Anaconda folks think for the custom partitioning use case
> where the use manually creates disk-based swap? Should and could the
> installer then also do:
>
> 'touch /etc/systemd/zram-generator.conf'
>
> post install? The effect is to disable the zram-generator and there'd
> be only disk-based swap. The alternative outcome without this is
> they'll have both swap-on-zram with a higher priority than the
> swap-on-disk they created.
>
> I'm open to suggestions. I think it's mainly a question about what you
> think the user expects in this situation. That's hard to answer
> because the user expects disk based swap as a long standing
> convention. And there is no convention for either swap-on-zram yet, or
> two swap devices, even though the kernel has supported up to 32 swap
> devices since forever.
>
> The best experience performance wise would be to have the two swaps.
> They gain from swap-on-zram at first, and perhaps mostly. Followed by
> the secondary use of disk based swap. But I'm not opposed to disabling
> zram-generator in this case. It is a more conservative option and
> might better square with expectations.

Hi Chris,

we have discussed it and we don't really have a strong preference. Enabling
both seems like a slightly better choice, because the installed systems
won't be so different. As far as I know, the hibernation will still work
and, as you said, the performance should be better. The generator can be
always disabled in a %post script of a kickstart file or after booting into
the installed system.

Vendy
> Thanks,
>
> Chris Murphy
>
> Anaconda-devel-list mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list

[Chris Murphy]

Hi,

I am confused. For default partitioning, the idea is to no longr
create a swap partition, instead there will be both zram-generator and
zram-generator-defaults packages, which will cause a swap on
/dev/zram0 to be created during early boot.

When I look in https://pagure.io/fedora-kickstarts all of the ks files
that contain 'autopart' also contain '--noswap'. Yet Workstation
edition and others, do have a swap partition created. Suggestions?

Thanks,

Chris Murphy

[Vendula Poncova]

On Thu, Jul 9, 2020 at 4:26 AM Chris Murphy  wrote:
> Hi,
>
> I am confused. For default partitioning, the idea is to no longr
> create a swap partition, instead there will be both zram-generator and
> zram-generator-defaults packages, which will cause a swap on
> /dev/zram0 to be created during early boot.
>
> When I look in https://pagure.io/fedora-kickstarts all of the ks files
> that contain 'autopart' also contain '--noswap'. Yet Workstation
> edition and others, do have a swap partition created. Suggestions?

Hi,

the kickstart files from fedora-kickstarts
https://pagure.io/fedora-kickstarts are used for Fedora release images.
They don't define the default partitioning of new installations. Is there a
problem with the partitioning on these images?

Default partitioning of new installations is defined in Anaconda:
https://github.com/rhinstaller/anaconda/blob/master/data/anaconda.conf#L16

The change seems to be approved. Can I open a pull request for the changes
in the Anaconda configuration files?

Vendy
> Thanks,
>
> Chris Murphy
>
> Anaconda-devel-list mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list

[Neal Gompa]

On Thu, Jul 9, 2020 at 7:33 AM Vendula Poncova  wrote:
> On Thu, Jul 9, 2020 at 4:26 AM Chris Murphy  wrote:
> > Hi,
> >
> > I am confused. For default partitioning, the idea is to no longr
> > create a swap partition, instead there will be both zram-generator and
> > zram-generator-defaults packages, which will cause a swap on
> > /dev/zram0 to be created during early boot.
> >
> > When I look in https://pagure.io/fedora-kickstarts all of the ks files
> > that contain 'autopart' also contain '--noswap'. Yet Workstation
> > edition and others, do have a swap partition created. Suggestions?
>
> Hi,
>
> the kickstart files from fedora-kickstarts are used for Fedora release images. They don't define the default partitioning of new installations. Is there a problem with the partitioning on these images?
>
> Default partitioning of new installations is defined in Anaconda:
> https://github.com/rhinstaller/anaconda/blob/master/data/anaconda.conf#L16
>
> The change seems to be approved. Can I open a pull request for the changes in the Anaconda configuration files?

That would be very helpful, thanks!

[Vendula Poncova]

On Thu, Jul 9, 2020 at 1:36 PM Neal Gompa  wrote:
> On Thu, Jul 9, 2020 at 7:33 AM Vendula Poncova 
> wrote:
> > On Thu, Jul 9, 2020 at 4:26 AM Chris Murphy
>
> wrote:
> > > Hi,
> > >
> > > I am confused. For default partitioning, the idea is to no longr
> > > create a swap partition, instead there will be both zram-generator and
> > > zram-generator-defaults packages, which will cause a swap on
> > > /dev/zram0 to be created during early boot.
> > >
> > > When I look in https://pagure.io/fedora-kickstarts all of the ks files
> > > that contain 'autopart' also contain '--noswap'. Yet Workstation
> > > edition and others, do have a swap partition created. Suggestions?
> >
> > Hi,
> >
> > the kickstart files from fedora-kickstarts are used for Fedora release
>
> images. They don't define the default partitioning of new installations. Is
> there a problem with the partitioning on these images?
> > Default partitioning of new installations is defined in Anaconda:
>
> https://github.com/rhinstaller/anaconda/blob/master/data/anaconda.conf#L16
> > The change seems to be approved. Can I open a pull request for the
>
> changes in the Anaconda configuration files?
> >
>
> That would be very helpful, thanks!

https://github.com/rhinstaller/anaconda/pull/2723
> --
> 真実はいつも一つ！/ Always, there's only one truth!
>
> Anaconda-devel-list mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list

[Chris Murphy]

On Thu, Jul 9, 2020 at 5:33 AM Vendula Poncova  wrote:
> On Thu, Jul 9, 2020 at 4:26 AM Chris Murphy  wrote:
> > Hi,
> >
> > I am confused. For default partitioning, the idea is to no longr
> > create a swap partition, instead there will be both zram-generator and
> > zram-generator-defaults packages, which will cause a swap on
> > /dev/zram0 to be created during early boot.
> >
> > When I look in https://pagure.io/fedora-kickstarts all of the ks files
> > that contain 'autopart' also contain '--noswap'. Yet Workstation
> > edition and others, do have a swap partition created. Suggestions?
>
> Hi,
>
> the kickstart files from fedora-kickstarts are used for Fedora release images. They don't define the default partitioning of new installations. Is there a problem with the partitioning on these images?
>
> Default partitioning of new installations is defined in Anaconda:
> https://github.com/rhinstaller/anaconda/blob/master/data/anaconda.conf#L16

OK, that about sums up my confusion. :)
> The change seems to be approved. Can I open a pull request for the changes in the Anaconda configuration files?

Yes please, that will certainly save me more embarrassment.

One item I haven't worked through yet is how 'inst.zram' should
inhibit the zram-generator. The generator runs during early boot.

My current thinking is 'inst.zram' can just 'systemctl stop
[e-mail]' since it will exist already. In that case
it could optionally be renamed to 'inst.nozram'. What do you think?

I think the timing of the changes isn't very critical. If the release
images have zram-generator first, it will run sooner and the Anaconda
implementation will fail (error messages in logs, but otherwise
non-fatal). Whereas if the Anaconda implementations go away first, the
lack of swap on zram in low memory situations might cause problems.

[Chris Murphy]

On Thu, Jul 9, 2020 at 7:27 AM Chris Murphy  wrote:
> One item I haven't worked through yet is how 'inst.zram' should
> inhibit the zram-generator. The generator runs during early boot.
>
> My current thinking is 'inst.zram' can just 'systemctl stop
> [e-mail]' since it will exist already. In that case
> it could optionally be renamed to 'inst.nozram'. What do you think?
>
> I think the timing of the changes isn't very critical. If the release
> images have zram-generator first, it will run sooner and the Anaconda
> implementation will fail (error messages in logs, but otherwise
> non-fatal). Whereas if the Anaconda implementations go away first, the
> lack of swap on zram in low memory situations might cause problems.

I've opened an issue with upstream zram-generator folks. Igor suggests
they could parse for 'inst.zram' or 'inst.nozram' and inhibit the
creation of swap-on-zram.

https://github.com/systemd/zram-generator/issues/42

[Vendula Poncova]

On Thu, Jul 9, 2020 at 5:22 PM Chris Murphy  wrote:
> On Thu, Jul 9, 2020 at 7:27 AM Chris Murphy 
> wrote:
> > One item I haven't worked through yet is how 'inst.zram' should
> > inhibit the zram-generator. The generator runs during early boot.
> >
> > My current thinking is 'inst.zram' can just 'systemctl stop
> > [e-mail]' since it will exist already. In that case
> > it could optionally be renamed to 'inst.nozram'. What do you think?
> >
> > I think the timing of the changes isn't very critical. If the release
> > images have zram-generator first, it will run sooner and the Anaconda
> > implementation will fail (error messages in logs, but otherwise
> > non-fatal). Whereas if the Anaconda implementations go away first, the
> > lack of swap on zram in low memory situations might cause problems.

I have opened a draft for the Anaconda zram service. It will be marked as
blocked until it is safe to merge it:
https://github.com/rhinstaller/anaconda/pull/2727
> I've opened an issue with upstream zram-generator folks. Igor suggests
> they could parse for 'inst.zram' or 'inst.nozram' and inhibit the
> creation of swap-on-zram.
>
> https://github.com/systemd/zram-generator/issues/42
>
> --
> Chris Murphy
>
> Anaconda-devel-list mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list

[Brian C. Lane]

On Thu, Jul 09, 2020 at 09:21:31AM -0600, Chris Murphy wrote:
> On Thu, Jul 9, 2020 at 7:27 AM Chris Murphy  wrote:
>
> I've opened an issue with upstream zram-generator folks. Igor suggests
> they could parse for 'inst.zram' or 'inst.nozram' and inhibit the
> creation of swap-on-zram.
>
> https://github.com/systemd/zram-generator/issues/42

In general I don't think it's a good idea to parse the cmdline for
parameters they don't control. Anaconda has a dracut module that does
various things during early boot which seems like a better place to deal
with inst.* options.

Brian

[Chris Murphy]

On Thu, Jul 9, 2020 at 11:20 AM Brian C. Lane  wrote:
> On Thu, Jul 09, 2020 at 09:21:31AM -0600, Chris Murphy wrote:
> > On Thu, Jul 9, 2020 at 7:27 AM Chris Murphy  wrote:
> >
> > I've opened an issue with upstream zram-generator folks. Igor suggests
> > they could parse for 'inst.zram' or 'inst.nozram' and inhibit the
> > creation of swap-on-zram.
> >
> > https://github.com/systemd/zram-generator/issues/42
>
> In general I don't think it's a good idea to parse the cmdline for
> parameters they don't control. Anaconda has a dracut module that does
> various things during early boot which seems like a better place to deal
> with inst.* options.

OK. Is it possible for the dracut module to 'touch
/etc/systemd/zram-generator.conf' if it sees 'inst.nozram' ? The
presence of an empty file there will inhibit. Since this is early
boot, it might be more appropriate to have this inhibit file in /run -
I think that's also possible.

[Chris Murphy]

Use zram-generator instead of zram
https://pagure.io/fedora-comps/pull-request/513

Replace 'zram' with 'zram-generator', and exclude Cloud edition
https://pagure.io/fedora-kickstarts/pull-request/658

Obsolete zram package from zram-generator-defaults
https://src.fedoraproject.org/rpms/rust-zram-generator/pull-request/3#

I'll report back when these have been accepted, and then this can happen:

Replace the zram service
https://github.com/rhinstaller/anaconda/pull/2727

Thanks,

--
Chris Murphy

[Chris Murphy]

On Thu, Jul 9, 2020, 12:58 PM Chris Murphy  wrote:
> Use zram-generator instead of zram
> https://pagure.io/fedora-comps/pull-request/513
>
> Replace 'zram' with 'zram-generator', and exclude Cloud edition
> https://pagure.io/fedora-kickstarts/pull-request/658

Those have been accepted. Anaconda PR #2723 and #2727 can happen anytime.

About inst.zram
https://github.com/systemd/zram-generator/issues/42

Another possibility is to just deprecate it. If swap is really not needed,
zram device won't be used. There's no RAM preallocated for the zram device.
If it is needed, it gets used on demand, and prevents reclaim. Pretty much
win win.

---
Chris Murphy

[Vendula Poncova]

On Fri, Jul 10, 2020 at 6:14 PM Chris Murphy 
wrote:
> On Thu, Jul 9, 2020, 12:58 PM Chris Murphy 
> wrote:
> > Use zram-generator instead of zram
> > https://pagure.io/fedora-comps/pull-request/513
> >
> > Replace 'zram' with 'zram-generator', and exclude Cloud edition
> > https://pagure.io/fedora-kickstarts/pull-request/658
>
> Those have been accepted. Anaconda PR #2723 and #2727 can happen anytime.

Ok.
> About inst.zram
> https://github.com/systemd/zram-generator/issues/42
>
> Another possibility is to just deprecate it. If swap is really not needed,
> zram device won't be used. There's no RAM preallocated for the zram device.
> If it is needed, it gets used on demand, and prevents reclaim. Pretty much
> win win.

I have talked about it with the team and we prefer the deprecation of the
inst.zram option. The zram-generator can always introduce its own option if
there is a demand for it.

Vendy

---
> Chris Murphy
>
> Anaconda-devel-list mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list

[Chris Murphy]

On Mon, Jul 13, 2020 at 5:38 AM Vendula Poncova  wrote:
> On Fri, Jul 10, 2020 at 6:14 PM Chris Murphy  wrote:
> > On Thu, Jul 9, 2020, 12:58 PM Chris Murphy  wrote:
> > > Use zram-generator instead of zram
> > > https://pagure.io/fedora-comps/pull-request/513
> > >
> > > Replace 'zram' with 'zram-generator', and exclude Cloud edition
> > > https://pagure.io/fedora-kickstarts/pull-request/658
> >
> > Those have been accepted. Anaconda PR #2723 and #2727 can happen anytime.
>
> Ok.

I've tested Fedora-Workstation-Live-x86_64-Rawhide-20200712.n.0.iso
and swaponzram is activated during early boot, for both the
installation environment and in the installed system. When I reduce
memory to trigger activation of anaconda's implementation, it
consistently fails safely.

This will get quite a lot of testing in openQA, since most of their
VM's are provisioned with 2GiB RAM, and there is a moderate need for
swap in this configuration.
> > About inst.zram
> > https://github.com/systemd/zram-generator/issues/42
> >
> > Another possibility is to just deprecate it. If swap is really not needed, zram device won't be used. There's no RAM preallocated for the zram device. If it is needed, it gets used on demand, and prevents reclaim. Pretty much win win.
>
> I have talked about it with the team and we prefer the deprecation of the inst.zram option. The zram-generator can always introduce its own option if there is a demand for it.

OK I'll let the upstream zram-generator folks know. Thanks!

[Chris Murphy]

I've tested some images and this is going OK for the Live ISOs, but
the boot.iso based images like netinstallers and dvds (silverblue,
Server DVD) for some reason do not have zram-generator-defaults on
them. Therefore those installation environments don't have a
swap-on-zram setup.

I see the 'Recommends: zram-generator-defaults'
https://src.fedoraproject.org/rpms/anaconda/blob/master/f/anaconda.spec#_187

Yet that's somehow not enough? Nor is it enough that
zram-generator-defaults is in @standard, to get it onto all the
install media?

Related PRs
https://pagure.io/fedora-comps/pull-request/513
https://pagure.io/fedora-kickstarts/pull-request/658

So far the installed OS's from these do have zram-generator-defaults
installed, and the swap-on-zram device is up and running OK. The one
installation that doesn't have it is the 'Custom Fedora' (I think this
is also known as minimal package set) installation I used when doing
an Everything netinstall installation.

---
Chris Murphy

[Vendula Poncova]

On Thu, Jul 16, 2020 at 7:13 AM Chris Murphy 
wrote:
> I've tested some images and this is going OK for the Live ISOs, but
> the boot.iso based images like netinstallers and dvds (silverblue,
> Server DVD) for some reason do not have zram-generator-defaults on
> them. Therefore those installation environments don't have a
> swap-on-zram setup.
>
> I see the 'Recommends: zram-generator-defaults'
>
> https://src.fedoraproject.org/rpms/anaconda/blob/master/f/anaconda.spec#_187
>
> Yet that's somehow not enough? Nor is it enough that
> zram-generator-defaults is in @standard, to get it onto all the
> install media?

It looks like lorax doesn't install weak dependencies. I have opened a new
pull request to fix the boot.iso:
https://github.com/weldr/lorax/pull/1048
> Related PRs
> https://pagure.io/fedora-comps/pull-request/513
> https://pagure.io/fedora-kickstarts/pull-request/658
>
> So far the installed OS's from these do have zram-generator-defaults
> installed, and the swap-on-zram device is up and running OK. The one
> installation that doesn't have it is the 'Custom Fedora' (I think this
> is also known as minimal package set) installation I used when doing
> an Everything netinstall installation.
>
> Chris Murphy

[Chris Murphy]

On Thu, Jul 16, 2020 at 6:41 AM Vendula Poncova  wrote:
> On Thu, Jul 16, 2020 at 7:13 AM Chris Murphy  wrote:
> > I've tested some images and this is going OK for the Live ISOs, but
> > the boot.iso based images like netinstallers and dvds (silverblue,
> > Server DVD) for some reason do not have zram-generator-defaults on
> > them. Therefore those installation environments don't have a
> > swap-on-zram setup.
> >
> > I see the 'Recommends: zram-generator-defaults'
> > https://src.fedoraproject.org/rpms/anaconda/blob/master/f/anaconda.spec#_187
> >
> > Yet that's somehow not enough? Nor is it enough that
> > zram-generator-defaults is in @standard, to get it onto all the
> > install media?
>
> It looks like lorax doesn't install weak dependencies. I have opened a new pull request to fix the boot.iso:
> https://github.com/weldr/lorax/pull/1048

Maybe I should add it to the anaconda-tools group?
https://pagure.io/fedora-comps/blob/master/f/comps-f33.xml.in#_38