It seems that the Librems are shipped with coreboot with a SeaBIOS payload. Unfortunately, the Qubes OS installer doesn’t play too nicely with this configuration and installs properly but does not boot. On my Librem 13v2, I get
SeaBIOS (version rel-1.10.0-51-g7759d3a)
Booting from Hard Disk...
_
This is apparently a known issue: https://github.com/QubesOS/qubes-issues/issues/2553. It looks like it’s been fixed for Qubes 4.0 (by simply disabling coreboot detection), but for now we’re stuck with the 3.2 installer (which still skips installing GRUB if coreboot is present).
I have tried the first workaround ("switch to a terminal in the installer and effectively disable coreboot detection: ln -sf /bin/true /usr/sbin/dmidecode && systemctl restart anaconda"), but that just results in a black screen that all combinations of Ctrl+Alt+F? or Fn+F5-8 (they look like the brightness and screen on/off buttons) do not fix.
What ended up working for me was to install GRUB manually via the instructions they provided (summarized below because it’s split across comments in the link):
Boot Qubes installer into recovery: Troubleshooting -> Rescue a Qubes system
After booting to anaconda installer choose 1) Continue (and enter your Qubes partition password if you chose to encrypt it during install)
In the prompt:
chroot /mnt/sysimage
grub2-install /dev/sda (or where your Qubes installation lives)
This sequence doesn’t seem to work for me. I continue to receive the following (on the first step):
grub2-install: warning: Attempting to install GRUB to a disk with multiple partition labels. This is not supported yet…
grub2-install: error: embedding is not possible, but this is required for cross-disk install
After I receive the errors, I still ran steps 3 and 4…the grub2-mkconfig doesn’t seem to fail…but it doesn’t seem to do anything. The computer still hangs at “Booting from Hard Disk”.
Hmmm. I just got my 13v2 today, factory without an OS. It looked like Qubes wiped the partitions…I’ll see if I need to do something else to make it seem like there isn’t two partitions.
[EDIT 1]
Good news! The grub2-install command now succeeds without error!
The bad news, it still hangs at “Booting from Hard Disk…”
Do I need to give “grub2-mkconfig” some kind of target / output file? It seems to just dump it all to the screen. Apologies for my ignorance…this is the first time I’ve been this deep into boot components.
[EDIT 2]
After that last boot attempt, I went back into the troubleshoot…this time it brought up a gui. Will see what happens after this.
[EDIT 3]
It seems that perhaps it somehow unpacked it onto the USB drive. I no longer have access to the install screen of qubes from the USB drive. And that is how it boots.
From what I understand about this work-around, I suspect the issue is that the grub program installed its data to the wrong device. We must double-check the device corresponding to the boot disk. In my case it was /dev/sda, but in your case I could be a different device. If /dev/sda was your USB stick, then it will have installed grub data to the wrong place.
After you get a shell in recovery, you can run ‘lsblk’ to get a tree of devices. You should be able to see the name of the device in that tree. Depending on the technology of your drive, it may show up as ‘sda’ or ‘sdb’, etc., or it may have a different name.
Hello! Yesterday I got my 13v2 with a 250GB SSD, have installed Qubes os 3.2 on it but I have the same problem. I tried many times to fix it with all your precious informations:
It seems to work correctly in the troobleshooting, but here is the result when I reboot:
Booting from Hard Disk...
.
error: no such device: 626f3abe-d6eb-423a-a751-b4ffbc450e08
Entering rescue mode...
grub rescue>
Here (with lsblk) we can see that the installation target is sda and not sdb:
But I don’t know yet how I can see what device it is configured to boot from.
I need to make further research and experiences.
Maybe you are willing to show me how I can proceed to find the device?
Before I check further, are you certain you followed step 1) chroot /mnt/sysimage above before executing the grub commands?
If you did not, then that could lead to the symptom that you are seeing on boot. The disk may have tried to boot to the usb device instead of the hard disk.
I just wanted to hop in this conversation, I have tried the R4-rc1 version of Qubes (see this blog post if you missed the news), and I did not encountered this issue on my 13v2.
So depending of your need, and patience, you can wait for the final version of R4 (or already hop in the RC? Keeping in mind, that it is an RC, so things could go wrong…).
@d2r Yes I followed step 1) before executing the grub commands. Now my plan is to test Qubes 4.0-rc1 and wait for the stable release. However I’m grateful for the advices you gave me cause I needed support.
@Mayeu thanks for the information, now I’m feeling hopeful! I’ll test the R4-rc1 asap.
Ok @tde. Good luck. I tried a pre-rc1 version of Qubes 4 and it did not have the installer issue (it did not skip the grub install), and it did not have any trouble resuming from suspend, however several qubes features were not working for me. Hopefully you will have better luck.
How is the battery life with the R4-rc1? That wasn’t easily available when I was going through this (I have since been using Linux Mint). Tempted to try this out.
Hi @jguluarte, I can’t honestly comment on that. Mostly I was trying things out and not really using the laptop as I normally would on battery power. I did not notice any excessive power consumption though.
Using aarmea’s workaround, augmented with d2r’s lsblk piece worked perfectly for me on a fresh Librem v2 with just one encrypted NVMe SSD. Thanks, guys!
Thanks, this worked for me as well. Was able to boot, which is fantastic!
Curious as to the XEN_DEFAULT command line, though. Why is it beneficial to have “console=none”? Also, I’ve read that dom0_mem should be set to a fixed size, like “dom0_mem=min:1024M dom0_mem=max:1024M” but I can’t find good recommendations for what that value should be for machines of different sizes.
This may be a very simplistic solution, but I was able to get qubes to install properly with Coreboot detection disabled so thought I’d share. I encountered the same issue where after submitting the command ln -sf /bin/true /usr/sbin/dmidecode && systemctl restart anaconda the screen appeared black. As mentioned, you can still see the background but it is extremely dim… Too dark to navigate the install.
The solution was simply to go through the installation (without disabling coreboot detection – just the normal way) using only the keyboard. Write down the keystrokes used to configure all of the settings (install location, disk encryption password, etc.) the way you want it, all the way through to install completion and rebooting the computer. (e.g. Tab, down down enter, tab tab space, tab space… you get the picture) Then go back through the install again, run the shell command above to disable coreboot detection and follow your recorded keystores despite the barely visible screen. When the installation finishes and you reboot your librem laptop, the backlight goes back to working fine and you get the standard qubes boot up you’re looking for.
