Librem 13v2: Qubes stuck at "Booting from Hard Disk" after install

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: 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):

  1. Boot Qubes installer into recovery: Troubleshooting -> Rescue a Qubes system
  2. After booting to anaconda installer choose 1) Continue (and enter your Qubes partition password if you chose to encrypt it during install)
  3. In the prompt:
  4. chroot /mnt/sysimage
  5. grub2-install /dev/sda (or where your Qubes installation lives)
  6. GRUB_CMDLINE_XEN_DEFAULT="console=none dom0_mem=min:1024M dom0_mem=max:4096M"
  7. grub2-mkconfig

While this works, it seems a little convoluted. Do we have a better workaround?


Thanks aarmea. I can confirm this fixed the issue for me as well.

1 Like

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”.

Any ideas?


This suggests there can be data on the drive that could confuse the grub program. I have not seen this before myself.

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.

1 Like

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.


I was up late that evening and eventually found out what I needed to target that command to. It is now booting successfully :slight_smile:

I do notice that I need to boot in advanced mode, otherwise it fails to startup the other VM’s. But that is an easy workaround.

1 Like

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:

Now I’m discouraged cause I really need to learn more about Qubes.
Are you willing to give me some ideas to solve the problem?

1 Like

@tde Yeah, /dev/sda seems to be where Qubes has been installed, and so that is the grub install target we want.

However, it seems grub is configured to search for the wrong device on boot.

If you ‘chroot /mnt/sysimage’, can you locate a grub.cfg file under the /boot directory and see what device it is configured to boot from?


@d2r Thank you very much for your feedback!

I have chroot /mnt/sysimage, and located the grub.cfg file under /boot directory with:
ls -R /mnt/sysimage/boot

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…).

1 Like

@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.

1 Like

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.

1 Like

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.

1 Like

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.

1 Like

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.

Regardless, thanks for posting this out!

1 Like

Recently received my librem. I notice the same issue.

I used the same steps above except with:
GRUB_CMDLINE_XEN_DEFAULT=“console=none dom0_mem=2048M,max:2048M”

Therefore have static mem as recommended here:

Also booting OK. . .

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.