I started off as a 4.0.3 user on my Dell Inspiron 5593 until I (foolishly? foolhardily?) decided to upgrade my Dell BIOS and was essentially locked out of the stable version–the BIOS upgrade killed all displays, including that of the installer. I managed to get my hands on a 4.1 alpha, found it worked, and had stuck with it ever since–until 4.0.4 was released last week.
The vast majority of my time with Qubes was spent on 4.1 for that reason, so 4.0 is somewhat alien to me. Here are some observations for those who might be interested. I’ll add more as I continue using R4.0.4:
Smooth installation process
For laptops with Nvidia, you no longer have to tinker with EFI/BOOT/BOOTX64.cfg on the boot media for installation to work. This is a massive quality-of-life improvement for newbies.
Faster VM boot
VM boot times on 4.0.4 are nearly half that of 4.1. I’m not sure whether this is attributable to the alpha status of 4.1, but there’s something that’s massively slowing down VM boot times.
Sudo prompts are a blessing
I’m not a fan of passwordless root, so I replace it whenever I can. Unfortunately, sudo prompts installed manually or using Tasket’s script simply don’t work in R4.1, so for an R4.1 user who has disabled passwordless root, qvm-run -u root ... is a familiar incantation to get stuff done. It wasn’t fun, especially since the ‘n’, ‘v’, ‘space’, ‘/’, and other keys on the lower row of my laptop keyboard don’t work (don’t buy an Inspiron 5593). Please get sudo prompts working on R4.1 before it’s released.
Being able to edit Qubes-RPC is nice
I remember getting so lost when first opening /etc/qubes-rpc/policy/qubes.UpdatesProxy and finding it completely empty on R4.1. That experience repeated itself as I continued finding these mysteriously blank files where there should be configuration files. For example, /boot/efi/EFI/qubes/xen.cfg, needed to edit the dom0 kernel options (i.e. important) is also missing without an easily findable alternative.
I think this may be related to the qrexec overhaul mentioned elsewhere, but it’s disorienting especially since there’s no documentation. Not that I’m complaining, since R4.1 is an alpha, but its rollout will have to be accompanied by a not-insignificant overhaul of the documentation.
Less noise with icons
The new icons (pictured below) are neat, but get confusing when using things like disposable sys-VMs (I imagine a large portion of Qubes users use these). Icons for disposable VMs and templates are easy to confuse. As it stands, I don’t think the R4.1 icons are flexible and distinct enough. The padlocks icons of R4.0 don’t make sense, but since it’s the only icon, there’s less noise. Just a minor nitpick.
Increased instability
In the three days since installing and configuring R4.0.4, Qubes has frozen at least three times. This was something I never encountered on R4.1, despite using a virtually-identical configuration and doing the same tasks. This suggests that, ironically, R4.0.4 is more unstable than R4.1, despite all the improvements I mentioned above–at least on this laptop.
What happens is that the screen would freeze but everything else seems to work (according to the fan sounds and laptop temperature). The mouse cursor would be free, but no input and seemingly no amount of waiting would unfreeze the rest of the screen, so it’s doomed to wander the frozen landscape until the end of the universe, like the Biblical Wandering Jew, waiting for me to hard shut-down the universe.
Probably something related to graphics? Probably my dom0 seizing up as it’s getting penetrated? I have no idea.
Edit: I suddenly remembered that, unlike all my previous installations, the dom0 kernel doesn’t have the nouveau.modeset=0 option in its /boot/efi/EFI/qubes/xen.cfg (something I just remembered is also missing in R4.1) since it wasn’t added into the installer. That might have prevented crashes in the past by making the Nvidia GPU play nice with dom0. I added that and will report back after a week. Another potential cause I’m looking at is the kernel being too new (5.10.8-1), but one thing at a time.
Suspension still doesn’t work
As the title says, suspending the system (e.g. by closing the laptop lid) on both R4.1 and R4.0.4 leads to unrecoverable system issues on dom0 kernel 5.10.8-1. This means I have to be very careful not to accidentally close the lid if I don’t want to hard shut-down Qubes. It goes without saying that hibernation still doesn’t work.
