To continue to use Qubes-OS safely I should upgrade to the latest version 4.2 from the current versions 4.1, however this can be a complex and more importantly time consuming process that may not even work, so I would like to clarify some details and assess if it is even worth trying. Some of these question may be best handled in separate threads but I list them all here because they are all related to the one issue of successfully upgrading Qubes-OS.
Currently Qubes-OS 4.1 refuses to run on any 6.1… version kernel. It is running fine on a 5.15 version kernel.
As far as I can tell the Lenovo Thinkpad W540 meets the minimum specifications but there is no listing in the capability list that indicates it works with any 6.1… kernel. I note there are much newer kernels now and there may be new issues to navigate as a result.
Will this be an issue for the upgrade process?
If it upgrades successfully while running the older kernel will the older kernel still be available for boot after the upgrade?
How can I diagnose what the issue is with the newer kernel not booting? Apparently there is no logging at these early boot stages and the messages disappear quite quickly even when verbose mode is set.
Is there a hardware requirement my laptop does not meet with the 6.1. kernel? e.g. instruction set changes?
Is there some test software that can be run to check for compatibility before attempting an upgrade?
Is there a live boot CD/DVD/USB test or similar?
Also I would like to verify if it is normal to have 1035 packages installed in Dom0? (sudo dnf list). It seems an awful lot to me in a kernel / Dom0 which is supposed to be minimal to make security management easier.
I am sure some of you will suggest a better alternative is to try a fresh install to see if it works, however this also is quite a time and resource consuming process and I would like to know if there are more precise, analytical, direct practical, fast methods I can try.
Somebody may have already tried and proven that Qubes-OS 4.2 will not run on the Lenovo Thinkpad W540 and that would be handy to know.
I tried to boot off the Qubes Installation disk (Qubes-R4.2.3-x86_64.iso). It starts to boot, the screen goes blank and then the computer reboots, just like trying to boot off a 6.1… kernel.
I expect the answer may be that the Lenovo Thinkpad W540 stopped being supported some time back when they introduced the 6.1… kernel and that the current installer uses a 6.X… kernel. (see new thread Is the Lenovo Thinkpad W540 still supported?)
Is there a tweak that can be done to make this work? Is there any hope of getting this to work or has support for this hardware ceased?
So, maybe you can start by trying to get the installation ISO to work (in a new forum topic)? This will give you some ideas about how to get the 6.1 kernel to work on Qubes 4.1 before upgrading.
Do you have backups? Are you able to change the internal drive in order to test the upgrade process without too much risks?
I am not so sure about that. I think it is probably easier to modify GRUB boot options and etc in the running Qubes-OS, than it is to modify the installation ISO process.
I could open two new threads: e.g.
How to: resolve Qubes-R4.2.3-x86_64.iso reboot issues on W540?
How to: resolve Qubes 4.1 rebooting on 6.1… kernel on W540?
if that is really the best path forward.
These topics may be too narrow. Perhaps they could be:
How to: diagnose Qubes-R4.2.3-x86_64.iso rebooting issues?
How to: diagnose Qubes 4.1 rebooting on 6.1… kernel issues?
I have been doing some inspection / tinkering / changing drives without backups. I was consider getting a new SSD and also doing a backup if things looked promising but at this point I was starting to think (again) it might be time to cut my losses and use a different OS … .
I have mixed feeling about that. Qubes-OS has taken up a lot of my time, but has also served me well. I have to run two computers because qubes-os interferes with natural operation of Operating Systems of VMs unlike other virtualization systems.
I strongly suspect the issue is not directly with the 6.1 kernel but with the combination of Xen Hypervisor and the 6.1 kernel and probably more specifically a side effect of the reduced functionality on Xen Hypervisor imposed on it by the Qubes-OS security model / philosophy. You do make a good point however that I should try a 6.1 kernel on the bare metal of the machine to see if it works as part of the process of elimination … . I will have to research what Linux distributions are using version 6.1 kernels … . I may already have one but don’t know. What version of Fedora is Qubes_OS 4.1 Dom0 Qube based on? Fedora 32. (see 4.1 Release Notes, sudo dnf list, most of the installed packages end with .fc32). Fedora 32 may be the one to try … but the kernel version changed to 6.1… in an update. Trying the same OS as the Qubes_OS 4.2.3 Dom0 Qube uses (Fedora 37, 4.2 Release Notes) may be a good test also.
There are VMs successfully running the 6.1… kernel so I think that may be sufficient to indicate that the kernel should be able to run as the Dom0 kernel and on the bare metal without causing a crash. Since this is unlikely to be an issue I will put this idea aside for the moment. I am likely to test it next time I shut the computer down.
I have tried some live Linux ISOs (i.e. Live CD/DVD images) running linux kernel versions 6.8.0-40-generic and 6.8.0-41-generic and there was no issue. So it is not strictly the kernel that is the issue.
Further testing I believe indicates either hardware support, software configuration or software bug issues. I hope to post about this soon.
Would this remove the later versions of the kernel? I think the current 5.15 installation of the kernel remains because the update process never removes the currently running kernel, … which is a good thing. (I have verified that these 5.15 kernel packages remain.) The question is whether the process that upgrades to Qubes-OS 4.2.3 would also not remove it because it is the running kernel?
I think that @marmarek’s idea is to mark kernel-515 as manually installed in order to avoid automatic management (and deletion) by dnf. I’m not sure but maybe, the 5.15 version is kept because only the last 3 kernels are kept by default? See this line in /etc/dnf/dnf.conf:
installonly_limit=3
To avoid some unfortunate deletion, maybe you can temporarily edit this line too?
PS: I forgot to answer about this:
I don’t remember installing anything in dom0 but I still have 1100+ installed packages. dom0 is not supposed to be minimal right now, see:
I was very concerned I was going to loose this kernel version that actually worked some time ago after several new kernels would not boot so I did a manual backup of the kernel files just in case. The next time I braved an update I noted that it kept the running kernel and deleted the second kernel in the list instead. (i.e. sudo ls -l /boot # to reveal the kernel boot files that exist before and after an update.)
I am not sure what package I would have to install. There are at least four for each kernel. (sudo dnf list | grep 5.15)
The first part of each package name currently installed is kernel-, kernel-devel-, kernel-modules-, and kernel-qubes-vm- and the next part is “1000:< version number>.qubes.fc32”. I suspect there would a package for each version that would manage the other packages of the same version.
It will remain because it is a different package name - kernel vs kernel-515 (note no dot here). The installonly_limit=3 applies to each package separately, so you can have 3 of kernel (tracking most recent LTS kernel) and 3 of kernel-515 (tracking most recent 5.15.x kernel).
My issue is trying to work out the package name (or enable the repository ??): (Note: some data redacted for privacy)
$ sudo dnf install kernel
Qubes OS Repository for Dom0 2.9 MB/s | 3.0 kB 00:00
Package kernel-1000:5.15......qubes.fc32.x86_64 is already installed.
Package kernel-1000:6.1.62-1.qubes.fc32.x86_64 is already installed.
Package kernel-1000:6.1.75-1.qubes.fc32.x86_64 is already installed.
Dependencies resolved.
Nothing to do.
Complete!
$ sudo dnf install kernel-515
Qubes OS Repository for Dom0 2.9 MB/s | 3.0 kB 00:00
No match for argument: kernel-515
Error: Unable to find a match: kernel-515
Note currently dnf is unable to find “kernel-515”. What can I do so it can find it?
$ sudo qubes-dom0-update kernel-515
Using sys-firewall as UpdateVM to download updates for Dom0; this may take some time...
Qubes OS Repository for Dom0 2.9 MB/s | 3.0 kB 00:00
Qubes OS Repository for Dom0 7.6 MB/s | 57 kB 00:00
Dependencies resolved.
==================================================================================================================================
Package Architecture Version Repository Size
==================================================================================================================================
Installing:
kernel-515 x86_64 1000:5.15.161-1.qubes.fc32 qubes-dom0-cached 9.9 M
Installing dependencies:
kernel-515-modules x86_64 1000:5.15.161-1.qubes.fc32 qubes-dom0-cached 60 M
Transaction Summary
==================================================================================================================================
Install 2 Packages
Total size: 70 M
Installed size: 345 M
Is this ok [y/N]:
I note that current installation contains four packages:
kernel-1000:5.15…qubes.fc32
kernel-devel-1000:5.15…qubes.fc32
kernel-modules-1000:5.15…qubes.fc32
kernel-qubes-vm-1000:5.15…qubes.fc32
Is kernel-devel-1000:5.15…qubes.fc32 for software developers?
It seems these other packages would be installed separately if needed? What package name should be used for kernel-devel? kernel-devel-515? Is there a reference / database of these package names or is that information only found in the individual package files?
)