By Bertel King - Published Apr 22, 2026
From the moment GNOME 3 launched back in 2011, I felt like it was perfect for a touchscreen, and I’m happy to say that it absolutely is. I’d even go so far as to say that the GNOME interface is a better way to navigate a touchscreen than that of Android or iOS. I’ve said before that I would love to see an official GNOME-only OS, and this experience has only strengthened that desire.
Every aspect of GNOME is easy to tap with a finger. Opening the app drawer and swiping between workspaces feels completely natural with three-finger gestures. Windows are easy to drag around, maximize, or pin to the side. The virtual keyboard that pops up when I tap an input field is the only visual distinction from desktop GNOME. (…)
This is an issue I run into running a headless Linux computer as well. On macOS I’m never running headless, so never ran into this issue. But needing to enter a password before the OS boots is a decision that makes Linux kind of awkward to use disk encryption with.
And I’m almost certainly doing it wrong, so would appreciate being nudged in the right direction.
I’ve seen a post about storing the encryption keys in TPM, but others say then you can lose your keys if the mobo dies. I’ve heard you can use ssh keys, but I’m not sure how — and here that would require a second device to unlock your tablet.
macOS uses a read only OS partition to boot and then encrypts your user data partition, can I do that with Linux?
That doesn’t mean you can’t decrypt your drive. It is just that it won’t be automatically decrypted at boot.
Yes, the dual partition approach is what I usually do with LUKS
Okay, on the weekend I’ll see if that can work with NixOS (so far my favourite distro).
You can write a luks key to a usb stick and use that to automatically decrypt at boot. https://wiki.nixos.org/wiki/Full_Disk_Encryption#Unattended_Boot_via_USB
What’s the general concept for setting up a dual partition for this purpose? I’m thinking of making a Linux server myself pretty soon.
It’s been a while, but I think I used this: https://wiki.archlinux.org/title/Dm-crypt/Encrypting_an_entire_system#LUKS_on_a_partition
If you want the OS to boot before it decrypts your drive, why encrypt it in the first place? Honest question, not an attack. For OS to boot without any password it needs to be booting from unencrypted drive. So the attacker could just put their keyloggers on that drive
Yes. Just encrypt /home partition only
This is dangerous. As some data like cache and logs are stored in the root partition. So some of your data from home partition might trickle up the root partition in that form.
My threat model doesn’t include someone gaining direct access to my home desktop. I have Arch Linux with Secure Boot and TPM 2.0 enabled on fully encrypted drive and this chain’s existence makes it easier to know that no one has tampered with my system. On my laptop I am one step further with requirement of BIOS password.
Hence my point about why bother at all. Without full encryption one gets leaks. With full encryption some kind of secret is required. Either password (hence that need of keyboard in earlier comment) or a key, etc
In order to not need a secret during boot, critical parts have to be exposed
Theoretically one could also put logs and cache on encrypted volumes. Maybe that could be some solution. I have in the past had
/var/logson separate partition, so it didn’t make/run out of space. Linux had no issue with that. But that still leaves kernel and OS exposedThe comment I responded to mentioned:
I don’t think you are talking about the same setup and vectors. Their point was to not have fully encrypted drive, so it boots without a prompt
You can achieve this even with full disk encryption with Secure Boot and TPM. That’s how Bitlocker does it. I have this setup on my Desktop — One single root partition with LUKS, Secure Boot on with sbctl and cryptenroll for tpm unlocking. Takes less than 5 mins to setup.
I’ve run into a few reasons:
Generally though I think OS encryption isn’t that important (verification is) vs protecting user data.
I don’t think I’ve heard about some boot-time checksum verification of root partition. Doesn’t mean it does not exist, just that I can’t help here
My point is: if OS is not encrypted, it can be modified. And that verification idea, if is not stored under some encryption, could also be changed. Which means that by the time you put in your password to decrypt your home, you might be already running system that will nullify the protection. Encrypting only your data will only protect you in scenarios when someone snatches your device turned off
TPM2 + Secure Boot via
systemd-cryptenrollis the closest to the “just works” FileVault/Android experience. Keep a recovery passphrase in your password manager. You don’t lose your data if the motherboard dies, you just use the recovery key.I use this on my daily drive laptop. Only real hiccup is that I still keep the dual boot because fwupd does not cover my laptop BIOS firmware updates but in a Linux tablet this a no issue.