31–40 of 45 posts
Fwiw I no longer use disk swap files for anything, but ZRAM swap instead. It's mature, it's in the linux kernel, it's faster, and less wearing on SSDs, and RAM is cheap. I don't have a linux laptop though, so don't know how it affects hibernation. Anyone know how/if hibernation works on a laptop using ZRAM swap instead of disk-based swap?
Earlier quoted context omitted.
ZRAM is amazing for cloud VMs which typically have strict disk IOPS limits which means any significant swap usage is going to destroy IO performance or even lock the system. ZRAM w/o swap completely prevents this IO condition and is much faster than disk swap anyway.
Shouldn't a cloud VM have swap disabled by default if it's using networked block storage? It is on AWS at least.
Earlier quoted context omitted.
ZRAM is amazing for cloud VMs which typically have strict disk IOPS limits which means any significant swap usage is going to destroy IO performance or even lock the system. ZRAM w/o swap completely prevents this IO condition and is much faster than disk swap anyway.
Shouldn't a cloud VM have swap disabled by default if it's using networked block storage? It is on AWS at least.
Interesting! I went on a similar journey recently with debian and FDE on luks2, which involved a fair amount of learning and messing around, but I got there. No Btrfs though, just plain old ext4+swap volumes using lvm on luks2, and a small uefi partition. My /boot is encrypted so I enter the LUKS2 passcode before grub can even access its config, and I've rolled an unlock key into the initramfs (which is loaded by gru…
https://build.opensuse.org/package/view_file/openSUSE:Factor...
Side note, you can use this same technique to add the LUKS password to the initrd just before doing kexec. This lets you reboot a remote system protected this way without having to pull up a VNC to enter the password.
My script for doing kexec with a preloaded LUKS password is here: https://gist.github.com/webstrand/381307348e24c28d5c4c9a5981...
I just did this last week and ran into an issue with LUKS: https://lore.kernel.org/cryptsetup/CAD-Ua_hPjBLHK0cyEz3k7KYB... LUKS wouldn't accept my password, no matter how simple it was. Turns out a BIOS update somehow messed up RAM settings which caused memory errors. And as LUKS needs a lot of memory for some of it's description operations bit flips can cause all of that to fail. That was frustrating!
I feel you. God I wish there was a company taking ownership in building, selling and supporting a batteries-included Desktop Linux distro where all these quality-of-life niceties that are working so well by default on Windows (and MacOS?), would be working out of the box on Linux without any user maintenance or need to read tutorials or wikis, and also be tested together on various hardware combos so that I have assu…
Which is fair. As an enthusiast that enjoys nitpicking my config files to make it all work perfectly, I've slowly come to understand people that don't want to do that. Sometimes you just want to get your work done, and it can definitely be frustrating when every utility has a different config file format, some don't even have config files but instead use gconf, some require a restart and some don't, some rely on new libraries that your distro doesn't have yet, every application has a different-looking UI... it can be a frustrating experience if you just want a MacOS or Windows-like experience. And unfortunately that level of simplicity isn't quite a thing yet in the Linux world.
Earlier quoted context omitted.
For secureboot you may want to took a look at this project [0]. Don't think it has ever gotten easier to sign UKIs than that though systemd should have a new project (systemd-ukify) that aims to make it more integrated. Hiberation is not supported in lockdown mode because I'm assuming the kernel (maintainers) expect most people to have an unencrypted swap partition. If you have secured your swap, you can patch [1] th…
It is not because of an unencrypted swap partition. It is because, even if it is encrypted, you know the key and can thus replace the image with an arbitrary modified one, or, in theory, with a hacked version of a Windows boot loader, which would break DRM. There were some movements to remove this restriction, on the condition that the encryption key is properly sealed in the TPM and is not extractable.
TPM has never been a pre-requisite for secureboot nor kernel_lockdown. Infact the proposal you are speaking of sounds very exclusionary since TPM hardware is still relatively new and not ubiqitous.
Earlier quoted context omitted.
Seems silly to set aside ram to use when your ram runs out. What am I missing here?
You don't set it aside, unused pages just get compressed to save space.
When there's no more ram, swap is used
or
When ram hasn't been used in a while, it is sent to swap
Or maybe a mix of both?
To be fair, I use a btrfs swapfile on an encrypted/compressed filesystem so I knew what to look for. But still, I find the wiki very reasonable to navigate and nearly always up to date.
https://wiki.archlinux.org/title/installation_guide
https://wiki.archlinux.org/title/Power_management#Suspend_an...
https://wiki.archlinux.org/title/Power_management/Suspend_an...
https://wiki.archlinux.org/title/btrfs#Swap_file
Added note, there is currently a bug in systemd's suspend-then-hibernate behavior (doesn't ever wake up and hibernate). To use it you'll have to downgrade to the arch-provided systemd version 251.7-4.
edit: formatting
Earlier quoted context omitted.
It is not because of an unencrypted swap partition. It is because, even if it is encrypted, you know the key and can thus replace the image with an arbitrary modified one, or, in theory, with a hacked version of a Windows boot loader, which would break DRM. There were some movements to remove this restriction, on the condition that the encryption key is properly sealed in the TPM and is not extractable.
Except you'd have to know the encryption passphrase to unlock the swap partition. Only after this step can you use the stolen key to manipulate the state of trusted images. TPM has never been a pre-requisite for secureboot nor kernel_lockdown. Infact the proposal you are speaking of sounds very exclusionary since TPM hardware is still relatively new and not ubiqitous.
As a daily arch user for over a decade I can't help but be that guy; why not just RTFM? Isn't that arch/gentoo's thing? good docs? about 15 seconds of searching turned up all the info. To be fair, I use a btrfs swapfile on an encrypted/compressed filesystem so I knew what to look for. But still, I find the wiki very reasonable to navigate and nearly always up to date. https://wiki.archlinux.org/title/installation_gui…