Which Linux distro are you using? Secureblue (based on atomic Fedora)
Which release version?
(if rolling release without a release version, skip this question)
(If rolling release, last date updated?) today
Which kernel are you using? 7.0.12
Which BIOS version are you using? Not sure
Which Framework Laptop 13 model are you using? AMD Ryzen™ AI 300 Series
Hi,
I tested Secureblue on a super old Dell laptop and it ran lit a charm – wasn’t using it much, but it did not have any issues.
Recently, I got a Framework 13 AMD with 8Gb of RAM, which may not be huge but should be enough for my use (my old macbook air had the same, and the Dell had less).
Despite this, every now and then, the computer runs out of RAM, says that an app is using too much and has to stop it. Mostly, it’s Firefox, but it might just be because that’s the most memory-consuming app I use (the rest is the terminal, libreoffice or things like this, no games, no videos, etc.). And sometimes the system itself crashes and has to reboot.
Since the Secureblue community doesn’t seem to experience this and I was not experiencing this with the Dell laptop, I am wondering whether this comes from the laptop itself.
Did you use the same config and dot files in the new install? OOM can be solved by adding more swap or better yet for your use case, configuring zram would likely resolve it.
Those immutable distros should just port over to another hardware config, no? Same settings and everything? You sure that the dell didn’t have a swap partition or file (or zram) configured that the FW for some reason doesn’t have yet?
Thanks for the suggestions, @cmemory ! I checked with the secureblue people and they say the distro actually already uses zram. They also advise against adding swap, as it should not be needed and could have counter-productive effect – so, not a hard no, just not necessarily recommended.
In the meantime, though, I did update to the latest firmware that just came out and, dunno if it’s related to that, but the situation got a bit better. I am still very careful (more than I would ideally like to be), but crashes have not resumed since the firmware update, so hopefully that fixed something. If they come back, I will try booting from regular Fedora on usb and see how that works.
“counter productive” that’s amusing. There’s nothing counter productive about adding swap when you are OOM’ing, if the configuration is correct. Windows generates massive swap files by default. There’s no security risks or anything counter productive going on there.
What you could also try first though, if the crashes return, is increasing the size of zram allocation. You can safely go up to 1.5x your physical RAM size. I believe Fedora defaults to 1x. Given this is a spin off Fedora, they’re likely at the same size. If the OOM crashes pick up again after that, you should switch to zswap+a swapfile. It’s a superior algorithm for systems whose usage patterns get pushed into swapping to disk.
You shouldn’t have to “be careful”. I also would be surprised if a firmware update eliminated OOM kills, but if works, it works! It’s odd that it seems like your configurations didn’t transfer over to the new machine identically. There’s no reason to expect to see more crashes with more physical RAM.
Of course the real solution here is buy more RAM, but we all know what that’s like these days…
Unencrypted swap to disk certainly had security implications but those can be almost entirely mitigated by using disk encryption which is pretty painless these days.
Equating “Windows does it” with “no security risks” is a wild statement
Agreed, also comes with the bonus of allowing hibernating which is a pretty killer feature for a computer.
Equating unencrypted swap to a security risk is wild. It’s one of those fun fear-factor concepts that is only an actual problem if you’ve been poking the NSA in the right way and have black vans showing up on your doorstep.
Or in other words, there’s no risk. If someone is that paranoid, they should also be using QubesOS.
Nor is it “counter productive” (which is the other half of my comparison, and is a phrase that sounds more like a distro dev desperately trying to find ways to sell their config decision). Microslop would have disabled this capability long ago if it really was a wild concept.
The Secureblue folks directed you to that article? It’s a good writeup indeed and he very clearly praises zswap over zram. Yes zswap+swapfile replaces zram.
I haven’t a clue how to configure Secureblue but you could at least first make sure the kernel they’re shipping has it as an option.
You should see stuff in this folder: /sys/module/zswap/parameters
You can enable it temporarily with
echo 1 > /sys/module/zswap/parameters/enabled
You’ll also want to turn on the shrinker_enabled (same folder) and set max_pool_percent to something like 50. Certainly more than the default of 20.
and turn off zram with:
swapoff /dev/zram0
All of those commands with sudo/root permissions. None of that will survive reboot though. Only way I am aware to make it permanent is to set kernel boot parameters. Here’s what I set for grub:
From a security perspective of encrypted swap vs not encrypted.
The threat most people consider is, if my laptop is stolen, do I need to protect any of the data-at-rest on it.
The general answer is to therefore encrypt the whole disk. You can encrypt the OS partition, but if a separate swap partition is used, and swap is not encrypted, all the plain text that is in RAM will be copied to the swap partition during use, and not erased when you power off the laptop. Thus leaving data unencrypted on the disk on the swap partition.
So, in order to get that full protection, encrypting the swap partition is also needed.
Pretty sure the swapping algorithms have become significantly smarter since then. Even back in 2020 when I was stuck on a 2Gb chrome-book for a couple weeks it wasn’t dumb enough to swap out actively running applications.
I would hope things have evolved in a decade. The examples in that older writeup involve very large monolithic files. Not exactly a web-browsing use case but the fundamentals are well demonstrated and that hasn’t changed. Between algorithm evolution, ssd, and compression, it may only be food for thought though ram usage is hardly one-size-fits-all. “Pretty sure” is good for a game of horseshoes. The only way to know with certainty is experimentation.
But exactly that has changed since that 2007 blogpost was written, the kernel gained awareness of how “used” a page is since then which stops it evicting in use ones for buffering file io.
I do count my experience on the 2Gb chromebook as a form of experimentation XD.
This chrisdown guy is a treasure trove of information, also pretty good at speaking, the talks are quite entertaining to watch.
If the crashes are caused by running out of memory, check your zRAM configuration first and consider increasing its size. If that isn’t enough, adding an encrypted swap file with zswap can improve stability and enable hibernation. If the issue persists even after firmware updates, test with a standard Fedora install to rule out distro-specific problems.
It wasn’t very scientific. Honestly the worst part was the display not the 2Gb of ram, that 720p tn panel was so bad they probably had to pay extra for it.
Pretty sure I was running zram on that one though since the ssd was incredibly slow and low endurance.
!