I’ve noticed when updating templates that sometimes new kernels are installed but the kernels available to run in a qube never changes. Am I supposed to do something manually to make them available or does that happen automatically at some point?
The in-vm kernels are not used by qubes in most cases. You may read the blow issue on Github for more information:
opened 01:21PM - 01 Aug 19 UTC
T: enhancement
C: kernel
C: doc
P: major
release notes
security
**The problem you're addressing (if any)**
Currently by default all qubes use k… ernel provided by dom0. This has multiple issues:
- kernel build for dom0 environment has incompatible kernel-devel package (especially painful for Debian templates, but also an issue for different Fedora versions): #2844 #3835
- template doesn't control kernel options: #4088
- kernel config not necessary matching template expectation (https://github.com/QubesOS/qubes-linux-kernel/commit/96b8fba8769951659fb9413b1d50a7e2172b90dd)
Using in-vm kernel isn't enabled by default and it's not straightforward:
- for HVM, one needs to choose "(none)" / "" kernel
- for PV, one needs to choose "pvgrub2" kernel
- for PVH, one needs to choose "pvgrub2-pvh" kernel (only recently available)
**Describe the solution you'd like**
Unify setting in-vm kernel - possibly translate "(none)" to "pvgrub2" if virt_mode is PV and to "pvgrub2-pvh" if virt_mode is PVH. Note that "(none)" normally is an invalid choice for PV/PVH.
This would require adjusting "(none)" label at UI level, to be less confusing/magic. Something like "(use kernel from within the qube)".
Set is as default value.
**Where is the value to a user, and who might that user be?**
Less deviation from template's system, according to https://www.qubes-os.org/faq/#what-is-qubes-attitude-toward-changing-guest-distros
**Possible drawbacks**
This change may lead also to some issues:
- less control over qube kernel means we won't be able to quickly apply qubes-specific fixes there - we'll need to wait until relevant distribution pick up updated kernel
- less control over qube kernel config - for example if some kernel feature is disabled, we may have a problem
- harder to provide extra kernel modules (fortunately we [don't need u2mfn in R4.1](https://github.com/QubesOS/qubes-issues/issues/4280) anymore)
- different grub2 version - for example the one in Fedora is heavily patched and grub.cfg may rely on it (for example support for "Boot Loader Specification")
**Describe alternatives you've considered**
Implement automatic pvgrub choice for kernel "(none)", but don't set it as default.
**Relevant [documentation](https://www.qubes-os.org/doc/) you've consulted**
https://www.qubes-os.org/doc/managing-vm-kernel/