Guix System is currently incompatible with Heads, for the following reasons:
Kernel files must be stored in /boot
/boot must not be encrypted, when using full disk encryption
What would fixing these issues require? Or are there any possible workarounds?
Other way around perspective not included?
To be clear, I meant that Heads is unable to boot into Guix System, both are ultimately incompatible with each other.
Any thoughts?
Obviously the logic is upside down. In order to start running you need FEET. Which is why computers need their BOOT program to put their shoes on.
(Funny 55 years ago we called it a BOOTSTRAP program. Apparently over the years it got shorted to the verb BOOT.)
Okay, that was actually mildly funny, kudos. Has anyone got any helpful feedback though?
I’ll try to do better than @tracy then 
I didn’t think that /boot was ordinarily encrypted. That is, I thought that ordinarily, /boot is unencrypted while the root partition is (LUKS-) encrypted i.e. not usually full disk encryption but full partition encryption and applied selectively to a partition.
So I take it that you have looked into this in sufficient detail to confirm that /boot is actually encrypted?
Are you getting some kind of error message that you can post here?
For historical reference, my first boot device was a 5 level Baudot encoded paper tape about 10 feet long. To start load the tape from the paper tape reader, the operator had to load about a dozen Octal codes on binary push button lights. The codes were read from a cheat sheet of paper. The system apps existed on a drum, not disc.
A PDP-8s that I used in grad school was the same. The s was for the serial bus version, but I think it should have been for slow. It was slower than any other computer I had used before.
Fair suck of the sav. Maybe further computer history musings would be better taken to Round Table.
And rightly so. Mine was probably a PDP of some sort. I was never told the computer model, only for the government code-word it was used for. It controlled about a half a dozen screens with keyboards each tied to a reel-to-reel tape drive. Tapes were interesting too, mounted on aluminum O-rings that stayed together because they were tightly packed. No plastic or metal side guards on the reels. If they ever flew apart you’d have tape all over. Never happened though. Some sandcrab gave it thought.
I can confirm /boot is indeed encrypted when encryption is selected using the “graphical” installer.
After powering on, I get the PUREBOOT ASCII art, followed by the following:
Loading /.gnupg/pubring.kbx from CBFS
Loading /.gnupg/trustdb.gpg from CBFS
Loading /etc/config.user from CBFS
***** Normal boot: /bin/gui-init
Unable to locate /boot files on any mounted disk
cat: can't open '/boot/kexec_hotp_counter': No such file or directory
Unable to read HOTP counter
HOTP code verification application, version 1.3
Connected device status:
Card serial: 0xXXXX
Firmware: v0.10
Card counters: Admin 3, User 3
Operation success
HOTP code verification application, version 1.3
Also, enabling PureBoot’s Basic Mode doesn’t seem to help, despite the features it disables seeming to be the culprit of the issue. Any ideas?
@irvinewade @joao.azevedo Any ideas? Or are there any additional steps I should go through to troubleshoot?
Not from me. Sorry.
This will seemingly not be a trivial task 
I’d gladly contribute what I can, but I’m having a hard time figuring out exactly where to go from here.
Those issues do appear to describe most of the complexity. I haven’t worked with Guix myself, but at an extremely high level Heads/PB needs to know how to:
Normally the answers to these are pretty straightforward - there’s an unencrypted /boot partition and all those files are signed. This covers the kernel/initrd since they are on that partition. Then kexec is handled by a simplified scan of the GRUB menus and loading that kernel/initrd, which are on /boot.
It looks much more complicated on Guix. I would start by ensuring that Heads/PB can mount /boot, one of the issues mentions that unencrypted /boot is possible so that would be easiest. Mounting an encrypted boot should be possible but there is no tooling for it currently. At that point it could probably find the GRUB menus (but not understand the boot options) and sign /boot (which would not sign the kernel/initrd, but should sign whatever else is there).
Then we need to know how to kexec Guix’s kernel/initrd, which means understanding enough of the GRUB menus to mount / and find those files. Heads/PB doesn’t fully parse GRUB menus, it does a simplified scan looking for menu items right now. I’m not sure what Guix’s menus look like to know how complex this would be, but another option would be to add extra config to tell Heads/PB how to mount / and how it is represented in a menu option. This will include unlocking / with cryptsetup.
At that point you’d probably be able to boot Guix, but Heads/PB will not know that it is not actually signing the kernels. You’d probably need to expand the signing/verifying logic to understand the GRUB menu options and additionally sign the referenced kernel/initrd if they are not on /boot.
Hi,
Sorry for my lack of response, I completely forgot about this thread, despite this issue still being very relevant to me.
Thank you @jonathon.hall for your extensive insight into this issue. Unfortunately, if I recall correctly, an encrypted /root with an unencrypted /boot is not currently possible, because of the need to access /gnu/store for the kernel and the initrd on boot.
After further online investigation, I have come to the conclusion that the simplest solution to this problem would be for Guix System to duplicate the kernel and initrd from /gnu/store to /boot, thus allowing an unencrypted /boot. I will file this issue on the Guix issue tracker.
If you have any further insight as to workarounds I could achieve right now, please let me know. I’d be glad to contribute.
Thanks again!
When do Purism support guix like it supports qubes os?