Q4.0 qvm-prefs kernel property vs the installed/latest kernel

[Steve Coleman]

I have two up to date fedora-26 templates, that have long since been
upgraded to fc28, that are both apparently 'stuck' at kernel version
4.14.74-1. I apparently can not set either template to a newer kernel.
There are a lot of customizations involved so I am hoping not to have to
go back to the fc28 rpm and start all over.

Both methods of inspection show the old kernel:

QubeManager <template-name>/QubeSettings/advanced/kernel/<dropdown>

qvm-prefs --get <template-name> kernel

The current/latest installed fc28 kernel version appears to be
4.18.18-200, yet this latest kernel does not even show up under the
QubeManager settings, nor qvm-prefs, and absolutely refuses to
set/update this 'kernel' key to this latest kernel version number.

The qvm-prefs utility simply claims that this newer kernel version is
not installed, yet "rpm-qa | grep 4.18.18-200" clearly shows that it is.
In fact rpm says that the older kernel 4.14.74-1 is *not* installed. If
so, then how is this template even running? I'm using it daily!

I know dnf can block a package from upgrading, but that is clearly not
what is happening here. The packages do update but apparently Qubes is
just not seeing them, as to be able to display any in Qube-Manager or
set/use them using qvm-prefs.

The "Qubes Global Settings" shows the default kernel as 4.14.74-1, and I
can't even change that, because the newer kernels are not listed there
either.

A file system scan for the old version number yields /usr/lib/modules/*
directory that shows up with 4.14.74-1 as an *fc26* module rather than a
fc28 module, so this whole version disparity appears to be due to some
kind of botched fc26 --> fc28 system/module check routine during a past
upgrade? At least that I my best guess at the moment of what broke and
when.

In fact /usr/lib/modules/4.14.74-1.pvops.qubes.x86_64/build/
is the only *build directory* where as all the newer kernels this is
merely a symlink into /usr/src/kernels/*/

Is there anywhere that I would find a Qubes "version setting" that
switches from fc26 modules to fc28 modules? Or is it just somehow
scanning for this "build" directory and then ignoring the newer symlinks?

Any clues of what this should be doing might be very helpful about now.

thanks,

Steve

[awokd]

Steve Coleman wrote on 11/20/18 6:03 PM:

AppVMs boot from and use a kernel supplied by dom0 (pvops). You can see
the version they're using with qvm-prefs kernel paramater or Qube
Settings/Advanced. If you want to use a kernel installed inside the VM
itself, you have to make it an HVM instead. See
https://www.qubes-os.org/doc/managing-vm-kernel/#using-kernel-installed-in-the-vm-r40
for details on how to do that, and look through the rest of that doc for
more information on how kernels get handled in Qubes!

[unman]

Steve,

The appVMs are booting using kernels set in dom0.
You can find more recent kernels in the testing repositories.
Install them in dom0 and they will become available
to use in your qubes.

They are kernel-qubes-vm.. and kernel-latest-qubes-vm

sudo qubes-dom0-update --enablerepo=current-testing --action=search
kernel-latest-qubes-vm

I think the "latest" is now 4.19.2, but you can specify earlier versions
if you wish

[Steve Coleman]

Thank you for that wonderful explanation. It turns out that the issue
was that the package "kernel-latest-qubes-vm" was not installed in Dom0.
So, no wonder I could not set any newer kernel version number.

Not sure how that happened unless it was some kind of dependency being
removed via some kind of conflict resolution. The only thing is there is
absolutely *no rpm history* for this package! This gets chalked in as
being a mystery in my book.

thanks,

Steve 8*}