When a domU update pulls new kernel updates like the currently 5.19.13 shouldn’t i be able to select these kernels for my appVM and if not why are we even downloading them every time?
dom0 has,
$ rpm -qa kernel-latest-qubes-vm
kernel-latest-qubes-vm-1000:5.19.9-1.fc32.qubes.x86_64
Template has,
[user@fedora-35 ~]$ rpm -qa kernel
kernel-5.19.11-100.fc35.x86_64
kernel-5.19.12-100.fc35.x86_64
kernel-5.19.13-100.fc35.x86_64
Well i thought the same but it turns out that i can only select between the following kernels in AppVM Settings, the pull down only lists:
default (5.15.64-1.fc32) (current)
5.15.46-2.fc32
5.15.63-1.fc32
5.19.9-1.fc32
So why are we pulling these other Kernels in the Template that we cannot yet use, i must be missing something here or my system is borked.
Have not found a way to make qvm-prefs list all available Kernels for the AppVM.
I noticed that, too. Putting the linux-kernel on hold might help.
The kernel used for PVHs (and PVs?) is afaik always provided by dom0. Only HVMs use the kernel they are shipped with.
Did not know that these “unused kernels” would have use when running HVM’s which i haven’t gotten around to use yet.
Learned something new, thanks!
Wouldn’t you able to use those kernel by setting none in qube’s settings?
This isn’t right, as is explained in the link I posted.
If the qube has virt-mode HVM, then you can use a native kernel by
setting kernel to “none” in GUI or qvm-prefs. Otherwise you can use one
of the dom0 provided kernels.
If the qube has virt-mode PVH, then you can use a native kernel by
setting kernel to “pvgrub2-pvh” in GUI or qvm-prefs. Normally they use
dom0 provided kernels but they need not.
If you don’t see that option they you have to install grub2-xen-pvh in
dom0
Unman thanks again for your input, it helps to understand all the options QubesOS offers.
The Manage Kernel page feels overwhelming and maybe it could use an update and new touch on the structure of all the available options given there, for example the > grub2-xen-pvh is not mentioned on the page.
I do understand now why the kernels are there even though i am not using them yet but might want to in some future use case.
Why is that the default behaviour?
I think we have covered this before. Here’s my take:
Using kernels provided by dom0 makes it easier to control and update
that part of the Qubes “infrastructure”.
(If it were necessary to patch the kernel in some way, then a single
update would be enough, rather than having to generate patched kernels
for Debian, Fedora, Ubuntu, Arch, Gentoo etc.)
It’s also far easier to troubleshoot problems if one knows that affected
qubes all share the same kernel.
And it’s consistent with the general Qubes approach, of providing a
reasonably simple backend to the process of creating and using qubes.
Thanks, that seems reasonable.
Thanks! I missed this somehow and there, although there are only 5 results with the search term…
I’m also wondering why it isn’t on Managing kernels doc.
The documentation is a community effort - if you would like to
contribute by editing the page to make things clearer and correct that
omission, that would be fine.
Yes I’m aware, but unfortunately for me it is a matter of a principle. I just don’t like to be registered with majors like Microsoft, Google, Yahoo, etc, so I don’t have an account on Github anymore. My note wasn’t an objection, it was rather an ascertaining.
But you can register with a burner email over Tor. What’s the issue?
Why did Microsoft buy Github? If they give me company shares for contributing, I’ll sign up at github again. With clear name and clearnet IP. 
Sorry I wasn’t clear enough. It’s not about anonymity at all. For me it would be like having Windows on the other partition or disk, hoping it wouldn’t mess up with my Qubes. It will. Sooner or later. Via Github, or inside my computer. Not a single experience with majors would give me a hope for the opposite.
Interesting topic which would deserve a seperate thread under All around Qubes.
It is all about plattforms. Microsoft bought Github in order to create revenue. Of course they have to create income for their employees and revenue for their shareholder. And of course it is convenient to have a platform for publishing FOSS and Github used to do a good job. But now it is time to move on. If we don’t it’ll end up worse than what has been done to science by companies like Elsevier: