Re: [qubes-users] Q4.0 qvm-prefs kernel property vs the installed/latest kernel
On 11/22/18 8:00 PM, unman wrote: On Tue, Nov 20, 2018 at 01:03:43PM -0500, Steve Coleman wrote: 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 /QubeSettings/advanced/kernel/ qvm-prefs --get 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 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 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*} -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/798cc4fa-c84e-dfb6-765c-be56f9978ceb%40jhuapl.edu. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Q4.0 qvm-prefs kernel property vs the installed/latest kernel
On Tue, Nov 20, 2018 at 01:03:43PM -0500, Steve Coleman wrote: > 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 /QubeSettings/advanced/kernel/ > > qvm-prefs --get 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 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 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20181123010057.eabqfz4a7qc4jg4z%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Q4.0 qvm-prefs kernel property vs the installed/latest kernel
Steve Coleman wrote on 11/20/18 6:03 PM: 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 /QubeSettings/advanced/kernel/ qvm-prefs --get 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 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! -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/42111b97-3134-edc4-19d9-9ee61edb84d2%40danwin1210.me. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Q4.0 qvm-prefs kernel property vs the installed/latest kernel
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 /QubeSettings/advanced/kernel/ qvm-prefs --get 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 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/f37dec5e-f9cf-3a23-a5ed-f4cfe2ac7053%40jhuapl.edu. For more options, visit https://groups.google.com/d/optout.