On 2026-02-06, Christine Lemmer-Webber wrote: > one of the things that has been clearest was the clustering of people > running MNT Pocket Reform devices, gathered at the Guix on Weird > Computers session at Guix Days. Five of us! And one Steam Deck person!
Yeah, wild! > But a universally agreed upon issue at that group was: booting on a > non-x86 system isn't great. ... > Things get less great from there: > > - The "boot choice" only works on x86 devices, because that's where we > have GRUB. There is grub-efi for aarch64-linux. U-boot has an EFI implementation. The only problem (for reform specifically) is that U-boot does not have display/keyboard support for most of the rk3588 platforms. Does barebox have an EFI implementation? That has video support for at least some of the rk3588 reforms... There also may be native EFI (EDK2?) implementation for the rk3588 platforms that might be worth trying... > - It's painful with full disk encryption even then, because you have to > type your passphrase twice. Never quite understand how that is such an awful thing... I mean, it is suboptimal, sure, but many people treat this like a total deal breaker, which baffles me. Most people probably have a user passphrase, wifi passphrases, a sudo or root passphrase, passphrases to log into various online services they use... Entering a password twice is very low on my list of frustrations with guix... on slow platforms the speed of "guix pull" is probably the main one, closely followed by rough periods of low substitute availability! > And the first time you type it you're > stuck waiting for what feels like ages to find out if you entered it > right or not, and if you haven't, you have to start all over. And if > you have, you have to enter it *again*, with a "three strikes till a > rescue REPL" situation, which if you hit that it's the absolute worst > because then you have to start all over again. But this part, yeah, awful! A prompt to try again would be really nice there... > - On non-x86, we don't have GRUB, so you can't choose a system > generation. (Mostly kind of sort of) not true on both counts (grub-efi exists for aarch64-linux), u-boot with guix's extlinux.conf menu it allows to select a boot generation. What you are missing is one of two things: - a display and keyboard interface from u-boot/barebox/EFI - serial console to access either of those menus, which is admittedly a challenging user interface out of the box at the moment. :) I did pick up a couple "TermDriver 2" adapters which provides a tiny screen on a serial console... a bit too tiny at 40x20(?) columns/lines, and still need to write drivers for a keyboard... so not a real solution yet, but frustratingly close! > Notably, this last problem doesn't exist on Debian, and partly for this > very reason, I'm no longer running Guix as my distro! ... > I don't know the answers myself, I can speculate on a few: > > - Have an unencrypted /boot which gets "splatted" to, but then we switch > the kernel or something with kexec (somewhat suboptimal and kinda > risky feeling) Yeah, you basically have all the same risks as my following proposal, with extra technical complexity (and flexibility, but works is better than flexible): Just an unencrypted /boot with the kernel/initrd/dtb, which is almost certainly what your Debian installation is doing. I would be very happy and curious to be proven wrong! :) On Guix, a separate /boot currently requires copying the right stuff (kernel/initrd/dtb) from the store to a separate /boot partition, possibly implemented as a customized extlinux.conf/grub.cfg as some sort of "guix system reconfigure" hook (do those exist?) ... or just always remember to do it manually!! What could go wrong? At any rate, that sort of setup still requires a quite sophisticated evil maid attack to compromise, and if you're really worried about evil maid attacks at that level, the bootloader is also loaded off an unencrypted media, and could be just as evil... You could do some sort of verified boot thing, to at least be able to detect if such an attack is occurring... PureOS has some integration for verified (or measured?) boot with security tokens, if I recall correctly (though not specifically for mnt/reform). Implementing something like that might be feasible... > - Maybe use the barebox bootloader on ARM: > https://mastodon.social/@mntmn/115986965428592424 > (but what about the full disk encryption thing?) Yeah, barebox looks promising! Personally have too little experience to know what it is missing, if anything. Lack of experience is eminently fixable... So, there are options to explore, with varying degrees of hackiness. Solving the split /boot problem on guix properly I think might give the best effort to benefit ratio: https://issues.guix.gnu.org/48172 :) live well, vagrant
signature.asc
Description: PGP signature
