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.
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
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 Anaconda-devel-list@redhat.com https://urldefense.proofpoint.com/v2/url?u=https-3A__www.redhat.com_mailman_...
----- Original Message -----
From: "Chris Murphy" lists@colorremedies.com To: "Discussion of Development and Customization of the Red Hat Linux Installer" anaconda-devel-list@redhat.com 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 Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
On Tue, Jun 2, 2020 at 9:47 AM Martin Kolman mkolman@redhat.com 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!
On Tue, Jun 2, 2020 at 10:13 AM Chris Murphy lists@colorremedies.com 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.
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
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
On Sun, Jun 28, 2020 at 10:10 PM Chris Murphy lists@colorremedies.com 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 Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
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
On Thu, Jul 9, 2020 at 4:26 AM Chris Murphy lists@colorremedies.com 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 Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
On Thu, Jul 9, 2020 at 7:33 AM Vendula Poncova vponcova@redhat.com wrote:
On Thu, Jul 9, 2020 at 4:26 AM Chris Murphy lists@colorremedies.com 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!
On Thu, Jul 9, 2020 at 1:36 PM Neal Gompa ngompa13@gmail.com wrote:
On Thu, Jul 9, 2020 at 7:33 AM Vendula Poncova vponcova@redhat.com wrote:
On Thu, Jul 9, 2020 at 4:26 AM Chris Murphy lists@colorremedies.com
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 Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
On Thu, Jul 9, 2020 at 5:33 AM Vendula Poncova vponcova@redhat.com wrote:
On Thu, Jul 9, 2020 at 4:26 AM Chris Murphy lists@colorremedies.com 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 swap-create@zram0.service' 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.
On Thu, Jul 9, 2020 at 7:27 AM Chris Murphy lists@colorremedies.com 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 swap-create@zram0.service' 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
On Thu, Jul 9, 2020 at 5:22 PM Chris Murphy lists@colorremedies.com wrote:
On Thu, Jul 9, 2020 at 7:27 AM Chris Murphy lists@colorremedies.com 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 swap-create@zram0.service' 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 Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
On Thu, Jul 09, 2020 at 09:21:31AM -0600, Chris Murphy wrote:
On Thu, Jul 9, 2020 at 7:27 AM Chris Murphy lists@colorremedies.com 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.
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
On Thu, Jul 9, 2020 at 11:20 AM Brian C. Lane bcl@redhat.com 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 lists@colorremedies.com 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.
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.
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
On Thu, Jul 9, 2020, 12:58 PM Chris Murphy lists@colorremedies.com 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
On Fri, Jul 10, 2020 at 6:14 PM Chris Murphy lists@colorremedies.com wrote:
On Thu, Jul 9, 2020, 12:58 PM Chris Murphy lists@colorremedies.com 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 Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
On Mon, Jul 13, 2020 at 5:38 AM Vendula Poncova vponcova@redhat.com wrote:
On Fri, Jul 10, 2020 at 6:14 PM Chris Murphy lists@colorremedies.com wrote:
On Thu, Jul 9, 2020, 12:58 PM Chris Murphy lists@colorremedies.com 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!
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
On Thu, Jul 16, 2020 at 7:13 AM Chris Murphy lists@colorremedies.com 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
On Thu, Jul 16, 2020 at 6:41 AM Vendula Poncova vponcova@redhat.com wrote:
On Thu, Jul 16, 2020 at 7:13 AM Chris Murphy lists@colorremedies.com 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
anaconda-devel@lists.stg.fedoraproject.org