Re: Heads-up / for discussion: dnf not working with 1G of RAM or less

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On 29-08-2022 10:49, Hans de Goede wrote:


I guess if folks can chime in with thoughts here and/or in the bug
report, maybe a consensus will emerge on just how big of an issue this
is (and how likely it is to get fixed). There will presumably be a
FESCo ticket related to prioritized bug status too.

I still have quite a few x86_64 tablets with only 1G RAM, so I personally
definitely care about this.

With that said I do regularly run dnf on them without issues,
although I think most of the 1G models I have are still at F35...

Still I wonder why this is an issue in some cases:

1. ZRAM helps a lot here, but I guess with containers when limiting them
to 1G you really only get 1G since ZRAM works on the system level not
the container level. In the VM case though ZRAM should help, is ZRAM
enabled ?  ZRAM is enabled by default for Workstation installs, but
maybe not in other installs ?

I ran into this on a RaspberryPi 3 with 1G of RAM and 1G of zram. That's the default configuration of F35 (Server Edition). I since added a 512M swapfile to the setup and my last 'dnf upgrade', yesterday was not killed by systemd.

When dnf was killed by systemd-oomd, I was able to switch to microdnf, which allowed me to continue.

2. Maybe there are some other processes also taking up more RAM
then expected causing extra memory pressure ?

That's possible. But the main issue appears to be with dnf. For ARM it's currently recommended to turn off dnf-makecache [1], which I actually intended to use to check for security related updates.

But there's PackageKit also running on the system, triggered by Cockpit update checks. PackageKit is keeping its own cache, iirc, and it's equally resource hungry.

Maybe settling for one package backend would be an option at least for the Server Edition? Personally, I could do without cockpit-packagekit, but others might want a replacement using (lib)dnf.

Bottom line: I care about this getting solved. But, if documented, there's no need for it to block F37 (Beta).


-- Sandro
arm mailing list -- arm@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to arm-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct:
List Guidelines:
List Archives:
Do not reply to spam, report it:

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux ARM (Vger)]     [Linux ARM]     [ARM Kernel]     [Fedora User Discussion]     [Older Fedora Users Discussion]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Maintainers]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Announce]     [Fedora Package Review]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Coolkey]     [Yum Users]     [Tux]     [Yosemite News]     [Linux Apps]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]

Powered by Linux