VM kernel does not exist: /var/lib/qubes/vm-kernels/4.4.38-11/vmlinuz

[Franz]

Hello,

the usual trick of selecting other kernel in Qubes manager does not work
running

qvm-prefs -s kernel default

gives

A VM with the name 'kernel" does not exist in tne system

ls /var/lib/qubes/vm-kernels/

gives
4.4.55-11 4.4.62-12 4.4.67-12

However one of the VMs does correctly starts. this one shows it is using 4.4.55-11

Best

Fran

[Unman]

You are supposed to include the name of the qube you want to work on
when using qvm-prefs.
If you want to run against a number of qubes just script it with a bash
script iterating over the names.

unman

[Franz]

Many thanks Unman, following your suggestion  I do not get errors with the qvm-prefs command, but the same trying to start the VMs I get the same error that makes the heading of this thread.

[Unman]

The recent update provided a new kernel - Qubes only maintains 3
recent kernels, so one has been deleted. That's why you get this error.
(A number of people have reported this.)
You should be able to set the default kernel as you have tried - if this
doesn't work for you just set one of the kernels that you DO have
explicitly.

unman

[Franz]

this is the first thing that I tried using Qubes manager. It worked in the past when after an update the same thing happened, But it is not working anymore now as I reported in the first post. None of the available kernels work.

I even tried to create a standalone as a workaround, but it gives the same error.

best

Fran

[Franz]

I found a strange workaround: if I deprive a VM of network  connection (NetVM to none) that the kernel error issue does NOT appear.

But of course I have no network :-((

Any idea what this may means?

[Unman]

Hello Fran

It's not clear to me what error you are reporting.
The error in the subject line arises because the recent upgrade
deleted the kernel that you have allocated to a qube.

The next error arose because you were using the qvm-prefs command
incorrectly.

And so I dont understand what you mean by "gives the same error".

In you other post you say that you can start a VM when you set the
networking to none - this makes me wonder if you have not yet reset the

Can you check that you have done this and then try to explicitly start
from a terminal the upstream proxies ?

If I haven't understood exactly what your current problem is please can
you explain in more detail. and perhaps provide the output from
qvm-start?

unman

[Franz]

Many thanks Unman for trying so hard to help me :-))

The next error arose because you were using the qvm-prefs command
incorrectly.

And so I dont understand what you mean by "gives the same error".

It is the first one, in the heading,  the second is just syntax that you properly corrected, but even after the correction and after running qvm-prefs without errors, then trying to start the VM I fall again to the first error.
 

In you  other post you say that you can start a VM when you set the
networking to none - this makes me wonder if you have not yet reset the

It seems the end of  your paragraph is lacking.
 

Can you check that you have done this

If you mean rebooting, yes I rebooted many times.
 

and then try to explicitly start
from a terminal the upstream proxies ?

 I do not know what upstream proxies are, but if you means something like

qvm-start <VM-name>

then I always get the heading error, unless the VM is not connected to network. In this last case it starts normally.

If I haven't understood exactly what your current problem is please can
you explain in more detail.

Unman, the problem is that  in the past it was easy to fix this error simply pointing each VM to a different kernel, on the contrary now this workaround does NOT work anymore. Worse than that I cannot even make dom0 recognize that I plugged in some USB stick, so even taking a backup (that luckily finished successfully)  out of dom0 is problem.
 

and perhaps provide the output from
qvm-start?

qvm-start sys-net

ERROR: VM kernel does not exist: /var/lib/qubes/vm-kernels/4.4.38-11/vmlinuz

qvm-start personal

--> Starting NetVM sys-firewall

--> Starting NetVM sys-net
ERROR: VM kernel does not exist: /var/lib/qubes/vm-kernels/4.4.38-11/vmlinuz

result: nothing started

But many thanks again for your strong patience

unman

--
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+unsubscribe@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20170522171007.GA10073%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

[Unman]

So this suggests that you have not yet changed the kernel for sys-net,
yet you say that the qvm-prefs command runs without errors.
1. Run qvm-prefs sys-net kernel.
2. Then qvm-prefs sys-net kernel -s <an installed kernel>
3. Then qvm-prefs sys-net kernel.
4. Then qvm-start sys-net

That was what my missing paragraph conclusion said.

If there's a discrepancy between the result returned at 3 and 4, there's
something seriously amiss, but at least we will know where to look.

unman

[Franz]

@Unman,

 

the above  command is interesting because it gives 4.4.38-11 while Qubes Manager gives 4.4.67-12
 

2. Then qvm-prefs sys-net kernel -s <an installed kernel>

qvm-prefs sys-net kernel  -s 4.4.67-12

3. Then qvm-prefs sys-net kernel.

Important change here:

I get 4.4.67-12
 

4. Then qvm-start sys-net

Hurrah!!! you dit it, it started. Now everything works again.

So what means all that?

1. The kernel identification provided by Qubes Manager is not reliable and cannot be trusted

2. The qvm-prefs does work, but must be run for each VM, while when you first taught me to use it, I understood that it could be used once for all VMs.

3. When something like that happens the best thing to do is to look for the commands that may help: had I known that qvm-prefs sys-net kernel gives the actual kernel used I would had been able to find the answer. Simply trusting Qubes manager was not enough.

I have no words to thank you Unman. You are methodical, one step after the other in the proper order, never loosing faith that a rational simple answer exists, even if we are perhaps thousands of kilometers far away.  Many thanks

Fran

[Unman]

I'm glad that you were able to solve your problem in the end.
This looks ike an interesting bug in Qubes Manager - I'll raise an issue
for it, although the redesign in r4 may resolve it in any case.

unman