Qubes 4.3rc1: trouble with kernels at grub

I just upgraded 4.2 to 4.3rc1 and update it.
In grub: advanced options for qubes(R4.3)–> Hypervisor Xen, version 4.19.3, I have a whole series of kernels available:

  • 6.15.10-100.fc41x86_64
  • 6.15.10-1.qubes.fc41.x86_64
  • 6.15.10-1.qubes.fc37.x86_64
  • 6.15.9-101.fc41x86_64
  • 6.15.7-1.qubes.fc37.x86_64
  • 6.12.42-1.qubes.fc41x86_64
  • etc…

So I have several questions:

  1. Why I have kernels 6.15.10-100.fc41x86_64 and 6.15.9-101.fc41x86_64 that doesn’t work with dom0.
  2. When i just boot as “normal” , the default kernel is 6.15.10-100.fc41x86_64 so, it doesn’t work, i must selected the good kernel manually ( actually 6.15.10-1.qubes.fc41.x86_64)
  3. How can i do to have 6.15.10-1.qubes.fc41.x86_64 as default.

For the fc37 kernels, I imagine that they must be present because I upgraded from 4.2 to 4.3rc1, right? is there a way to remove it?

First of all, up to the point answer on how to solve the issue.

You could list the installed kernels with sudo rpm -qa kernel\* | sort -V and remove the old ones or problematic ones with sudo dnf remove BAD_KERNEL. Regenerating grub menu entries should be automatic. But in case needed: grub2-mkconfig -o /boot/grub2/grub.cfg (on legacy boot systems, not EFI).

Second of all, of course, you should not need to do the above manually. The rpmspec should specify that the new kernels are replacing the old unsupported ones. So this is indeed a bug.

Third of all, some more background on the available Kernel options for Qubes OS.

  • linux-kernel-latest (current stable v6.15 available for both r4.2 & r4.3).
  • linux-kernel (current lts i.e. the default v6.12 available for both r4.2 & r4.3).
  • linux-kernel-66 (old lts v6.6 only for r4.2)
  • linux-kernel-61 (older lts v6.1 only for r4.2)
  • linux-kernel-515 (ancient lts v5.15 only for r4.2)

The above diverse choices of Kernels are to suit everyone needs. For some people the latest kernel is what supports their hardware. For some other the lts one is what is more stable and what actually boots. But if you have any of the 3 last ones (after in-place upgrade), it should be safe to remove them from the system. It should be also noted that the above package names are for dom0 kernels. Name of the package for kernels installed at /var/lib/qubes/vm-kernels/* is different (something like kernel-qubes-vm*). And there are multiple choices for that too which might come handy for sys-net and sys-usb to support latest hardware.

Thank, i must remove kernel-xx kernel-core-xxx kernel-devel-xxx kernel-modules-xxx and kernel-qubes-vm-xxx right?

Not qubes-vm-xxx (those are for in-vm kernel support).

And if you remove kernel-core-xxx, it should automatically remove the modules and the main packages as it is a dependency for them.

p.s.: It should be also noted that on Fedora system, dnf usually keeps 3 of the last of each kernel choice. It is controlled via /etc/dnf/dnf.conf and installonly_limit=3 option. This could be increased as long as it does not fill /boot partition.

All is alright @alimirjamali
Thanks.

1 Like

Another thing i don’t understand is that in GRUB_CMDLINE_LINUX i have rd.lvm.lv=qubes_dom0/root rd.lvm.lv=qubes_dom0/swap plymouth.ignore-serial-consoles 6.6.48-1.qubes.fc37.x86_64 x86_64 rhgb quiet

Why fc37 ?

Oh. That old bug:

1 Like

Re thanks :wink:

I just upgraded to the rc2 version from the rc1 version. I had deleted all the fc37 kernels as you explained to me in the rc1. When switching to the rc2 version, all fc37 kernels were downloaded again. I guess it comes from the same bug?

ps: The file /etc/dnf/dnf.conf doesn’t exist.

Using the conventional method? (just updating via GUI updater or qubes-dom0-update should update rc1 to rc2)

It should exist in dom0. At least a part which contains ###QUBES BEGIN### till ##QUBES END###. it contains vital information to avoid issues with Kernels.

The original file is a part of libdnf5 package. Maybe sudo qubes-dom0-update --action=reinstall libdnf5 could reinstall the missing file. Then running /usr/lib/qubes/patch-dnf-yum-config.

Ok. I looked again. The /etc/dnf/dnf.conf should definitly exist. Otherwise patch-dnf-yum-config could not do its job. So it would be either creating an empty dnf.conf file. Or downloading the original via qubes-dom0-update.

i updated via GUI updater.

it’s ok this method created the file.

We have to look back to see why the dnf.conf did not exist at first place. It is strange. Did you remove it?

No i don’t touch anything.

For now, i just remove the latest kernel then i reboot.
I did a new update of dom0 (via GUI updater). This time, the update did not install an fc37 kernel. I rebooted, the last kernel was loaded and no trace of fc37 kernels.
Maybe it was due to the fact that dnf.conf was absent? In any case, I had never deleted/modified anything in the /et/dnf/ folder

1 Like

For reference:

1 Like