Qubes not loading latest installed kernel...? + How to remove old kernel versions?

[HydraGene]

Hello all,

So I updated Qubes kernel to version 4.4.55-11, but HCL report still says I am running version 4.4.14-11..

I assume this isn't quiet right..

My VM's are running the latest version according the the VM settings.

Can someone tell me how to run my latest installed kernel?

Also, can someone help me remove the old kernel versions? Because they are kind of obsolete and a waste of space. I have 3 kernels installed now, I want to remove at least the oldest one, which is 4.4.14-11

Would be happy if someone could help me out.

Thanks and best regards,

HydraGene

[Reg Tiangha]

Dumb question, but did you reboot? If not, do so. If you did, then
reboot again, and when the GRUB menu shows up, select "Advanced Options"
and see which kernel is at the top or pre-selected. It's *should* be
4.4.55 but maybe in your case, it's not.

As for the kernel limit, you can change installonly_limit in
/etc/dnf/dnf.conf in dom0 from 3 to 2 and the next time the kernel is
updated, it'll uninstall any kernels beyond the second one, or you could
manually uninstall the oldest kernel yourself using

sudo dnf remove kernel-<version> kernel-qubes-vm-<version>

but hold off on doing that for a bit as there might be a bug right now
in vm kernel uninstallation:

https://github.com/QubesOS/qubes-issues/issues/2757

[hft.h...@gmail.com]

Op dinsdag 18 april 2017 21:03:12 UTC+2 schreef Reg Tiangha:

Thanks for your reply. (I currently experience some issues with the original mailservice.. So that's why I reply with my Google account now..)

Ofcourse I have rebooted, several times even.
GRUB menu? What GRUB menu? lol I know GRUB, but I don't see any GRUB menu when I boot.. I have an UEFI install. /boot/efi is in the EFI partition. /root + swap and /home are on different encrypted partitions.
Should I have made another unencrypted /boot partition?

When I start my laptop, I see some text and one [FAILED] message saying something about kernel. It disappears to fast to read fully.
Which log can I open to read these messages?

After this, Qubes boots to decrypt my drives and to the login screen. Everything seems to work fine.

Even in dom0 Global Settings and via CLI it says kernel 4.4.55-11 is running. But when I generate the HCL report or when I try to reinstall/uninstall the kernel, it says it can't remove kernel 4.4.14-11 because I am booted into 4.4.14-11.

I'll try making GRUB work with encryption the Debian way when I get home and see if GRUB then shows up. I'll keep you updated.
I'll also just upload the full HCL report when I have time.

Would be nice if my questions could be answered in the meantime.

[Reg Tiangha]

On 04/19/2017 01:41 AM,

Ah, my mistake. I don't have a UEFI capable machine so I don't know that
interface as well (I use legacy boot), but there must be an advance boot
setting in the boot loader to let you pick which kernel to boot, similar
to grub?

The definitive thing would be to open up a terminal in dom0 and run

uname -r

and it should display the kernel version that you're running. If it's
saying 4.4.55 but qubes-hcl-report says otherwise, then it'd be a bug in
qubes-hcl-report. That said, I run a 4.10 kernel in my dom0 and
qubes-hcl-report reports the correct kernel. Unfortunately, I don't have
a 4.4 kernel installed to test for myself, and I would but I'm having
some issues on my machine with the latest set of Qubes updates, which I
need to resolve first before I can get back to testing various things.

[hft.h...@gmail.com]

Op woensdag 19 april 2017 09:49:25 UTC+2 schreef Reg Tiangha:

uname -r says version 4.4.14-11

Now I noticed some things.

I tried the Debian way to get GRUB running when encrypted, but Qubes is completely different. I can't find the file that I edited on Debian.

I don't see any choice. In BIOS selecting the Qubes efi to load is the only option. Which made me think, what if I'd look into that drive?
Booted into Qubes, I ran Thunar as root (the only way to view inside /boot/efi)
Once in /boot/efi/EFI/qubes I only see the 4.4.14-11 kernel..

I noticed /boot however had 2 grub directories, 1 loader folder and all kernels installed. Looking at the files it seems like GRUB should be functional if it would show up. My /boot is on the same encrypted partition as /(root).

Is it possible that GRUB can't be loaded because it is on an encrypted drive? I had to manually edit GRUB config with Debian Jessie too in order to use GRUB.

Secondly, what if I manually copy the new kernel over the old one in /boot/efi/EFI/qubes and edit the xen.cfg to match the version number? Would that work? Or is there a very high chance of breaking my system?

I might try this myself after taking a backup. I'll do some more research the coming few days and try some stuff in the weekend.
If you have answers/solutions, let me know in time. :) Thank you for your help.

[Reg Tiangha]

On 04/19/2017 02:42 PM,

In that case, your boot loader configuration file was never updated, so
it still things 4.4.14 is your newest kernel.

I don't know how it works for UEFI so maybe someone else can help with
that. With grub, the configuration file is located in
/boot/grub2/grub.cfg and as a test, you could try to manually edit that
file to point to the correct kernel and initramfs files (make a second
entry so that you'll still have the old one to boot to).

But again, I don't have a UEFI capable system, so I just don't know how
to configure the boot loader on that kind of set up. Hopefully someone
else can help you there.

[hft.h...@gmail.com]

Op woensdag 19 april 2017 22:47:43 UTC+2 schreef Reg Tiangha:

I guess it's different with UEFI, because I don't have a /boot/grub2/grub.cfg file.. Or GRUB didn't install correctly (just as with my Debian experience).
Thanks for your help anyway!

[cooloutac]

Maybe this is totally unrelated, but I had to update dom0 twice. First time it didn't really update. Noticed the green download arrow again in qubes-manager hours later and that time it seemed to a big update.

[cooloutac]

On Wednesday, April 19, 2017 at 5:25:44 PM UTC-4, cooloutac wrote:
> Maybe this is totally unrelated, but I had to update dom0 twice. First time it didn't really update. Noticed the green download arrow again in qubes-manager hours later and that time it seemed to a big update.

Actually it wasn't even me, it was a family member, and I should of told them to only notifiy me when they see a dom0 update, sigh... I've told them to make sure they read what it says but this is kind of crazy.

They told me they already updated dom0 they thought, and I thought ok you normally see that in tempaltes where it updates but doesn't refresh cache or something and still shows a green arrow, but then you go to update and it says nothing to do (cause you know it was already updated maeks sense).

But this was probably a failed update or it did something else.

Only other time this happened to me with Qubes I blame on a bad resume from suspend that I didn't realize till too late, and the fact I am using an SSD. Which I am learning very fast are prone to fk up your data. Qubes got borked after I did a failed Dom0 update and I had to install.

This time its different. We should make the Tor updates by default. But then again this is type of thing that would happen on the whonix template and I always delete it immediately. Always get failed key checks on that all the time, weird update errors and it always has to do with the servers. So I'm just at a loss I rely on the experts some form of encrypted updates I think would def be better then just a key check. I would prefer it not be tor, but I guess thats better the nothing. Especially if people don't pay attention. Anybody could miss it, especially when using the little xterm window when updating with gui. lol.

I'm sorry for rambling about an unrelated topic.

[hft.h...@gmail.com]

Op donderdag 20 april 2017 00:07:22 UTC+2 schreef cooloutac:

After the first time updating I also saw again a green arrow. But with me it was like the first time it did a big update, but the second time it mentioned the system was already up-to-date. A restart resolved the "second arrow" problem. Since then haven't got the problem again.
Also, I tried updating again and again, and my system says no new updates are available. So I think this was not the cause.

[hft.h...@gmail.com]

Op woensdag 19 april 2017 22:42:40 UTC+2 schreef hft.h...@gmail.com:

--UPDATE--
So, I did try copying the new kernel to my /boot/efi/EFI/qubes/ directory and edited the xen.cfg file. It broke my system. I got:
[ TIME ] Timed out waiting for device <device name>
[DEPEND] Dependency failed for Cryptography Setup for <luks-device>
[DEPEND] Dependency failed for Encrypted Volumes.
But luckily I could recover my system by editing xen.cfg back to original by using rescue usb.

I tried to reinstall grub by: sudo grub2-install
"grub2-install: error: /usr/lib/grub/x86_64-efi/modinfo.sh doesn't exist. Please specify --target or --directory"
Is this a normal error while in UEFI mode? Or is there something not right with my system?

I am to lazy to reinstall my system right now to see if the encrypted /boot directory is the problem.

I'll keep this post updated whenever I decide to reinstall Qubes.

[Tao Effect]

Any update on this?

I just encountered a similar problem:

- Qubes 3.2 indicated there was an update for dom0

- I updated via the graphical utility, installed kernel 4.9.35-19.pvops.qubes.x86_64

- Rebooted

Upon reboot, `uname -a` indicates I'm still running the old kernel.

So I tried manually running: sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable kernel kernel-qubes-vm --best --allowerasing

It downloaded stuff (for some reason from "Fedora 23" repo even though I thought I'd updated to Fedora 25? Or is that separate - just for TemplateVM?) and then said, among other things:

"Package kernel-qubes-vm-1000:4.9.35-19.pvops.qubes.x86_64 is already installed, skipping"

Makes no sense! What do I do?

Like this fellow below, I do not appear to have any GRUB related things on my system being used.

Is there a way to force the machine to switch to using GRUB? Perhaps some BIOS option?

This is the machine I'm using: https://groups.google.com/forum/#!topic/qubes-users/0JTfsfPVl9w

Thanks for any help!

- Greg

--
Please do not email me anything that you are not comfortable also sharing with the NSA.

On Apr 22, 2017, at 12:15 PM, hft.h...@gmail.com wrote:

--UPDATE--
So, I did try copying the new kernel to my /boot/efi/EFI/qubes/ directory and edited the xen.cfg file. It broke my system. I got:
[ TIME ] Timed out waiting for device <device name>
[DEPEND] Dependency failed for Cryptography Setup for <luks-device>
[DEPEND] Dependency failed for Encrypted Volumes.
But luckily I could recover my system by editing xen.cfg back to original by using rescue usb.

I tried to reinstall grub by: sudo grub2-install
"grub2-install: error: /usr/lib/grub/x86_64-efi/modinfo.sh doesn't exist. Please specify --target or --directory"
Is this a normal error while in UEFI mode? Or is there something not right with my system?

I am to lazy to reinstall my system right now to see if the encrypted /boot directory is the problem. 

I'll keep this post updated whenever I decide to reinstall 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...@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/b1417c4f-18a3-4653-9b95-6a9fce54d6fd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tao Effect]

Something else I just noticed:

/boot contains initramfs-4.9.35-19.pvops.qubes.x86_64.img

BUT /boot/eft/EFI/qubes does not!

Both /boot and /boot/efi/EFI/qubes contain "initramfs-4.8.12-12.pvops.qubes.x86_64.img", and the two files differ when doing a diff on them.

The /boot/efi/EFI/qubes/xen.cfg file does not have an entry for the 4.9 kernel, but it does have 2 entries for 4.4.14 and 1 entry for 4.8.

There does not appear to be any difference between the boot arguments for the 3 entries other than the version numbers of the kernels (that I can spot with my eyes alone).

I'm scared of modifying the xen.cfg file for 2 reasons:

1. The fact that the .img files for 4.8 kernels in /boot and /boot/efi/EFI/qubes are different means that I don't know what that difference is, and I can't just copy the 4.9 kernel from /boot into the other directory.

2. The fellow below tried modifying his xen.cfg file manually and broke his machine. I would like to avoid that.

Any help greatly appreciated!

--
Please do not email me anything that you are not comfortable also sharing with the NSA.

To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/4B494A8E-2B13-4696-B8EF-A279C260F86F%40taoeffect.com.