@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.
Regardless, thanks for posting this out!
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:
https://wiki.xen.org/wiki/Xen_Project_Best_Practices
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.
Cheers!
hey, not working for me please someone help
Just to chime in:
I had the same problem:
SOLUTION:
SUGGESTION TO THE PURISM TEAM:
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.
I agree that this info should be more easily viewable from the ordering page, but here is a post which explains why it’s currently 3.2 and not 4.0.
https://puri.sm/posts/qubes4-fully-working-on-librem-laptops/
TLDR: 3.2 used to work, 4.0 was/is being tested for compatibility.
But if 3.2 isn’t working now, it seems like they should make the switch to 4.0 pretty soon.
Thanks for the valuable link! I probably was one of the last customers to receive a USB with qubes R3 because now I understand you are shipping it with R4.
I understand that things in terms of up-to-date versions/compatibility issues change very quickly in the computer industry meaning that it is almost impossible to be constantly ahead of the game. Great job guys!
BTW: Purism support rocks! This really sets purism apart from today’s anonymous corporate world!
Could I kindly ask for anyone to lend me a hand installing the Qubes 4.0 on my librem 13, V2? I looked on the Qubes site but I don’t see any .deb file anywhere. As it may of course be totally obvious to you, I am new to Linux, so please have pity.
First of all, a lot of people new to linux get frustrated quickly when it’s not exactly what they’re used to with windows, so thank you for asking politely 
You won’t find a Qubes .deb package. Qubes is a totally different “distribution” from PureOS. In windows there are only a few “distributions”, like windows 8, windows 10, windows mobile, etc…
Since linux is open-source, there are thousands of distributions, and any teenager could make a new one in their basement over the weekend. They all share the linux kernel - the fundamental “core” of linux - but different distributions can be wildly different.
Since Qubes is a different distribution, you will need to get the Qubes .iso file and burn it to a USB stick. Then, boot from the USB stick, and install Qubes as your new OS.
.deb files are software packages that you can only install on distros that use the debian package management system. Ubuntu, PureOS and Linux Mint are examples of linux distros that would accept .deb files.
.iso files are full disk images, that you have to copy to a USB drive or DVD, and then you can tell your computer to boot off the disk image
You can’t just drag and drop the Qubes .iso file to the usb stick though. You will need to use a program, like unetbootin, to make the usb stick bootable.
P.S. Since Qubes is based on Red Hat, their package files will end in .rpm
P.P.S I haven’t used Qubes or the Librem yet myself (in the mail yay) so I can’t help too much with specifics
Adding to what @gnulligan said:
It may help to understand the basic priciple of Qubes and its purpose before you start playing around with it, as it is a bit more complicated than your average OS.
Qubes main architecture is based on a hypervisor (Xen), which works like a backbone from which the “real” OS are run as virtual machines. You can have several OS templates in Qubes. It is shipped with Fedora (Red Hat) and Whonix (Debian). So strictly speaking there are no software packages for Qubes itself, only for the respective OS templates you decide to have it run. It is theoretically possible to even run a Windows template in Qubes (and it has been explored in Qubes 3.2), but that is very difficult to set up.
Qubes can do a lot for you in terms of security and it runs quite fine on a Librem I must say, but changing to Qubes from Windows is taking a significantly larger step than changing to, say, PureOS. On the bright side that means you will definitely be forced to understand a lot about how Linux works if you decide to give it a serious try. 
We didn’t ship QubesOS 4.0 (on USB drives) until it was officially released.
Solution is to download QubesOS 4 from their website, burn it to the USB drive and reinstall.
It is shipped with Fedora (Red Hat) and Whonix (Debian).
I haven’t used Qubes yet personally, but isn’t the base install just Fedora (for the GUI etc) + Xen? AFAIK Whonix is just one of the possible guests for Xen, but is not a necessary component of Qubes. If they include Whonix now by default, that just means it’s a built-in client, but it could still be uninstalled if you wanted and you’d still have the full Qubes OS.
Fedora, meanwhile, is necessary for hardware support, GUI, etc…
Correct me if I’m wrong though
It’s true that Fedora is the base for dom0, as you describe it. Afaik developers are still working on splitting dom0 into separate GUI and admin domains and then supposedly also switching the base OS used for these to something more minimal.
Thing is you do not install software packages in dom0 (if you’re a “normal” user at least), since it is only supposed to be coordinating and administrating the VMs. There are occasional updates from the Qubes repo of course, but there is no productive work supposed to be happening in dom0 whatsoever. You won’t be handling .rpm packages there.
That is why for understanding how Qubes works, in my opinion it is better to not think of it as a Fedora running client VMs, although technically it might be somewhat true. I’m not an expert Qubes user nor any kind of expert though, so I might as well be wrong.
Yeah honestly I always thought it was a terrible decision to use Fedora for that purpose. Aside from the silliness of using an entire Linux distro as a glorified GUI, t’s not even a particularly light distro. Glad to hear they’re working on a replacement.
I think they choose to use Fedora for driver support reasons, since Qubes needs more up-to-date hardware to run fluently. Whether that decision was sensible has been disputed, but I do not know enough to judge - I’m sure happy it runs on my Librem though.
Allowing for other distros at GUI level has been on the roadmap for at least 3 years now. It’s hard to estimate for me how those plans might change with the more recent idea of cloudifiying Qubes, but it would seem even more logical to minimize the (future) GUI qube if you want to be able to potentially run it as master on another machine.
But all that has little to do with the original topic of managing to install it in the first place I notice, so I’ll stop going OT now.