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.
and installed this new qubes version on my librem.
Now it boots. If everything works as expected in qubes I still have to find out.
SUGGESTION TO THE PURISM TEAM:
Since the librem community is highly focused on security and privacy they are well aware of the fact that qubes is probably one of the os that optimally hits the tradeoff-sweetspot between sec&priv and user friendliness. Therefore, many will want to use it, possibly including Whonix.
Delivering a qubes version that is known not to work with librem laptops - or at least not without jumping through major hoops (changing coreboot options, etc. by using terminal in the qubes installer - see the earlier comments of users) is not helpful.
I would suggest 3 alternative solutions: 1) Exchange the qubes R3 version on USB sticks for R4 OR 2) put a notification on the purism Q&A website about this problem OR 3) make this information at least more easily findable in the forum. This page is well hidden in the purism forum. It took many search queries on the forum site to get to this page - naturally, no way of finding it through conventional search engines e.g. DuckDuck, searx.
I have also written an e-mail with those suggestions to the purism team.
FYI:
I am not a Linux geek. I would consider myself a normal computer user but with fair knowledge about privacy and security. I just know the very basics in Linux and I am happy if I achieve to use basic commands in the terminal. So maybe exactly the kind of customer Purism would like to address (high privacy concerns/medium computer skills) …?
E.g. I would have had quite some hesitations to get qubes R3 running by following the comments by other users, because I would have feared to completely mess up my machine.
