Re: [qubes-users] Q4.0 qvm-prefs kernel property vs the installed/latest kernel

2018-12-04 Thread Steve Coleman

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

2018-11-22 Thread unman
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

2018-11-22 Thread 'awokd' via qubes-users

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

2018-11-20 Thread 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 /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.