How do you install the linux kernel version 6.x on a qubes system currently running Qubes R4.1.2?
For both dom0 and for domU?
dom0 shows kernel 5.15.103-1, my templates are configured for the same via Qubes Global Settings.
My dom0 sources (/etc/yum.repos.d/qubes-dom0.repo): all enabled except for unstable
My domU sources (/etc/qubes/repo-templates/qubes-templates.repo): all enabled
Have you tried:
sudo qubes-dom0-update kernel-latest
in dom0?
I think you’d need the following for both dom0 and domU:
sudo qubes-dom0-update kernel-latest kernel-latest-qubes-vm
B
Thanks, this worked to get the kernel-latest running. However there is now a problem with disk decryption during boot? I can’t decrypt my disks after this upgrade.
So I literally only ran the command provided, then verified dom0 kernel 6.2.10 with uname -a, and set domU kernels to 6.2.10 option in Qubes Global Manager. Now I’m unable to unlock my disk at boot, getting a somewhat generic ‘dependency failed for local encrypted volume’ from the TTY. The password isn’t accepted, enter it 3 times, fails, then dracut-initqueue times out and drops me into an emergency shell.
I enter the emergency shell and look through journalctl, there isn’t anything so obvious. To summarise the entries where the errors happen; After ‘fbcon’ takes over the console, systemd-cryptsetup declares the ‘set cipher aes, mode xts-plain64, key size 512 bits for device /dev/disk/by-uuid/UUID’. I think these are defaults, I didn’t set up anything non-default for anything here, just standard Qubes install. Encrypted btrfs with efi… Then the following line, ‘failed to activate with specified passphrase. (Passphrase incorrect?)’. The passphrase I enter is not incorrect. So the above 2 lines repeat three times as it asks for passphrase 3 times. Then it has ‘systemd-cryptsetup@system.service: main process exited, code=exited, status=1/FAILURE’. Followed is Another message by the same systemd-cryptsetup: Failed with results exit code. Then Failed to start cryptography Setup for system. Dependency failed for local encrypted volumes.
So it isn’t giving anything really specific in `journalctl’. The password is the same password previously used to unlock this disk, I really don’t believe I’ve entered it wrong anytime here.
Looking for suggestions on how to resolve; this happened as a result of upgrading dom0 to kernel-latest. I didn’t run anything else. Should I have? What should I do for now; boot live system and try mount disks, if I can do so then how do I fix? Or how to diagnose? Thanks in advance for any guidance.
Also: I have tried booting my other older kernels (5.10.103/90 or whatever I had for the old kernel), there isn’t any changes in behavior, I get the same error.
Right, so I can mount my disk from a live system, so there is something else going on; it isn’t the password and the actual error isn’t being put to the journal.
Mount your Qubes OS /boot partition in another system and check the old and new initramfs files modification date. Maybe you had them rebuild during update to new kernel and there were some errors during update. You can then mount you Qubes OS, chroot in it and then rebuild initramfs to check for errors.
I met the same problem as you. My solution was to give dom0 more RAM. Originally I set dom0’s max mem to be 1536M. Increasing it to 2048M solved this for me.
That is interesting. I’m fairly certain my dom0 had default memory allocation from the installer, which I believe is 4096 MB?
So to be clear, you can just install kernel-latest and kernel-latest-qubes-vm and you don’t have to mess around with grub/initramfs, since that should be taken care of in the package post-installation scripts (which I thought mine did, and didn’t throw obvious errors…)…?
I’m about to try it again; tried Qubes R4.2 but it’s not ready enough for me to drive it; 404s on update meta-repolink, whonix gw/ws templates don’t have a signing key available through qvm-install, so I’m going back to R4.1.2 and attempt to have kernel-latest in a working state before I invest totally into restoring my system.
Kernel 6.2.x running in Qubes R4.2 feels really speedy and snappy though. Exciting
Yes. I currently have no idea why you met this problem. I’m even not certain why I met this problem. journalctl -xe showed nothing exceptional when I finally brought up my system.
For me, it happened when I created a xen-user.xml with syntax error, which might have messed up with dom0’s VCPU settings.