After needing some time to understand how various configuration options interacted between the Heads config file and the needed setup in the Linux kernel, I present:
I have Heads working on the laptop, and Ubuntu 23.10 installed and working reasonably well.
The usual suspects are not working:
- USB-C needs the driver reloading hack to make them come alive.
- AUdio only has “Dummy Output”
As you can see, TPM2 is working. The CONFIG_CBFS_SIZE Coreboot setting needed to be enlarged to fit everything.
I have no idea what the state of the Intel ME is.
I am currently using MrChromeBox’s build of Coreboot. Not sure if I need that for the Linux boot target.
Qubes crashes during install on the UFS disk driver, which is unfortunate.
Not sure how to get F-key functionality.
I modified the flash-util script to flash a local file instead of downloading it to make sure it does the right thing with the VPD data etc…But I need to verify I didn’t mess up at some point too haha.
I’ll fork the relevant repos and submit PRs when they’re not awful. 
-Matt
1 Like
Indeed, I screwed up one of the flashes and had to re-integrate the VPD data and hwid values. But I got that done…after accidentally starting to write an ISO to the USB drive which had my firmware backup on it. 
I had to find the file, and reconstitute it enough to extract that data. Thank goodness it was written in contiguous blocks.
Qubes 4.2 seems to be a non-starter. It crashes during the install on the UFS drive (Release, latest kernel on release, latest kernel on testing build all crash). Installing to USB and then migrating it to the UFS produces a machine that boots, but has issues with the networking VM coming up, and thus it’s all broken.
Qubes 4.1 I had working with Kernel 6.6 on USB, attempting to see if the migrate-after-first-stage-reboot works with Kernel 6.6. Will report back if this works.
I found the F-key remap script, haven’t tried it yet.
I have a USB audio DAC and that’s just wonderful for now.
-Matt
1 Like
The underlying filesystem setup in Qubes is different than what I’m used to. I think that ends up being why I had so much trouble with it trying to get it to coexist with Ubuntu.
I ended up getting Qubes 4.2 working, albeit with ZFS as the backing store. Here’s what I did:
Install onto USB
Fully automatic partitioning, delete all the things.
This completes successfully.
Guides:
Followed ZFS guide - had issues with building, so downloaded packages.
Migrated everything, followed instructions, all worked well.
**** Machine kernel OOPSes on dracut running for some reason ( I think this is the root cause of the install error) ****
After install:
Installed audio fix script in dom0, had to hack up the script a little.
Installed USB4 systemd service fix.
- Video is OK
- Audio is OK on headphones, but speakers are overdriven
- USB Audio works fine
- Keyboard mapping haven’t tried fixing
- Performance is mediocre for sure (but still usable!)
- Power management does not seem to be working correctly under Qubes. Display turning off works fine, suspend does not. Both work fine under Ubuntu 23.10 live USB.
Performance:
Browserbench.org 14.3 in Ubuntu 23.10 live USB, 14.0 second run
Browserbench.org 5.18 in Qubes 4.2 with Firefox ESR, 4.71 on second run
So it’s definitely not too speedy lol.
1 Like
Heads config is here:
- Board configuration
- Coreboot configuration (currently using @MrChromebox Coreboot)
- Linux Kernel 6.5 (I tried 6.1 but I don’t think the UFS drive showed up)
Re: dracut crash.
“udevadm info -a /dev/block/8:3” is what’s causing the crash, in the 90kernel-modules/module-setup.sh@10(record_block_dev_drv)
If commenting out that section:
/usr/lib/dracut/modules.d/90kernel-modules/module-setup.sh
“for _mod in $(get_dev_module /dev/block…; do” (line 10 in record_block_dev_drv function as hinted above), that will stop the crash.
I’ve been using --add-drivers on the dracut commandline…
So I put the line:
add_drivers=“ufshcd_core ufshcd_pci”
into /etc/dracut.conf.d/ufshcd-workaround.conf
and that should leave things in an ok spot for now.
I’m going to see if I can use the stock version of Coreboot rather than the modified version, but I definitely need the 6.5 kernel series or newer, 6.1 doesn’t cut it if I remember from my initial tests…
-Matt
1 Like
Thanks a lot for your work! This is really really great!
Mind upstreaming your heads configs, after filing an issue with the project?
This combination sounds like it makes a ton of sense. ChromeOS has verified boot, but afaik mrchromebox firmware just uses Tianocore.
This would be a great enhancement.
I have a currently bricked BOTENFLEX (Lenovo Flex 3, Jasperlake) that I will try to debug. I would be really interested in running heads there too, as I now have a Thinkpad T430 with Heads, and a Clevo NV41MZ maybe soon also with Heads.
So after reading a bit into this, how would you summarize the steps you needed to take?
Did you build heads and mrchromebox coreboot separately? I am unsure as of what build script will build what, as afaik you would want to build the heads payload only, and then use that in a modified mrchromebox coreboot distribution build script
Cheers!
Sorry for the delay. Life’s been busy lol. I haven’t messed with this in a while.
The summary is:
- Do the normal UEFI full replacement via MrChromebox’s script
- Build heads for onmigul
- Flash using a modified version MrChromebox’s script that basically used a local firmware file instead of downloading it from his site.
After that, any updates can be flashed in Heads.
If you’re going for the fully monty, a WSON6 probe is needed to flash the chip externally on omnigul.
There’s a PR / branch which will build stuff - Add support for Acer Chromebook 515 Plus (CB515-2H) / Google Omnigul Platform by mdrobnak · Pull Request #1658 · linuxboot/heads · GitHub but I haven’t updated it in a while.
-Matt
Hey there’s a 6 in there! LOL
Thanks for the correction.
-Matt
