The step #1 works as expected (how-to-downgrade-a-specific-package : Dnf will say that there is no update, but the package will nonetheless be downloaded to dom0.).
But yes, step #2 failed. The error is Error: conflicting requests.
I never downgraded a package for Fedora, so I searched and found the below promising solution:
increase the installonly_limit value on /etc/dnf/dnf.confsource. Explanation: you already got 3 kernel versions (packages kernel-x.y.z, see rpm -qa kernel), dnf limits to only 3 versions with the installonly_limit value. So choose the 4 or 5 value.
The 5.x kernels cause my system to crash randomly, probably related to #6397. Recent updates have pushed my 4.x kernels out. I’m having difficulty adding a 4.x kernel back. The instructions above don’t appear to be working.
Attempt at 4.19.163:
[user@dom0 Desktop]$ sudo qubes-dom0-update kernel-4.19.163
Using sys-firewall as UpdateVM to download updates for Dom0; this may take some time...
Warning: Enforcing GPG signature check globally as per active RPM security policy (see 'gpgcheck' in dnf.conf(5) for how to squelch this message)
Last metadata expiration check: 0:15:52 ago on Mon Apr 12 08:01:35 2021.
No match for argument: kernel-4.19.163
Error: Unable to find a match: kernel-4.19.163
[user@dom0 Desktop]$ sudo dnf downgrade kernel-4.19.163
Failed to synchronize cache for repo 'qubes-dom0-cached', disabling.
No package kernel-4.19.163 available.
Error: Nothing to do.
[user@dom0 Desktop]$
The same happens with 4.19.155. No package kernel-4.19.155 available.
if you get an error talking about “–allowerasing”, then you need to remove an old kernel with dnf remove. In fact, only 3 versions of the same package are installable (get the list with rpm -qa | grep ^kernel-[45]).
@ludovic thanks!
I used the increasing installonly_limit mentioned above instead of removing kernels, and I now have the 4.19.176-1 kernel installed. I also edited grub to set this as the default kernel.
There’s something unusual about the 5.4 kernels in the 4.1 dom0 repo that you linked @ludovic . I can download any of the 5.10 ones without issue, but no matter what variation of kernel-5.4.## I attempt, I always get a “No match for argument” error. The only difference I can see is the missing .fc32. in the file names for all the 5.4 kernels.
For example given “sudo qubes-dom0-update kernel-5.4.88-1.qubes.x86_64”
No match for argument: kernel-5.4.88-1.qubes.x86_64
Whereas “sudo qubes-dom0-update kernel-5.10.96-1.fc32.qubes.x86_64” works perfectly.
Search in the current repository : sudo qubes-dom0-update --show-output --console --action=repoquery 'kernel*' → no 5.4 kernels.
Search In the testing repository : sudo qubes-dom0-update --show-output --console --enablerepo=qubes-dom0-current-testing --action=repoquery 'kernel*' | grep "5.4" → no 5.4 kernels.
Search in the security testing repository : sudo qubes-dom0-update --show-output --console --enablerepo=qubes-dom0-security-testing --action=repoquery 'kernel*' | grep "5.4" → 5.4.83 and 5.4.98 are available.
So, from my point of view, 2 solutions are available for you, the choice depends on your skills and the risks :
get the 5.4.83 or 5.4.98 kernel from the security testing repository (example : sudo qubes-dom0-update --check-only --show-output --console --enablerepo=qubes-dom0-security-testing --action=install kernel-1000:5.4.98, remove --check-only for an install action)
download the 5.4.88 kernel rpm file from a VM, copy it to dom0 (see the copying-to-dom0 doc), and install it with sudo dnf install <the rpm file with absolute or relative path>, the new kernel should be available from the grub menu (else search “grub.cfg” in this forum).
Related documentation:
qubes-dom0-update --help and man qubes-dom0-update
Hey thanks for the detailed response and confirming I’m not crazy. I’m assuming if the rpms are not in the repo index they’re effectively unsigned, so at that point I’m just trusting that nothing nasty has been injected into yum.qubes-os.org. So I might lean towards security-testing.
Since the description of security-testing is the packages go there first then get migrated to current, it seems like maybe part of that migration is broken? If all the 5.4’s never quite make it into the current repo.
My system that worked great on release 4.0 is completely unstable on 4.1 w/ the 5.10 kernel so I have to try something.
I will try newer ones eventually, I didn’t want to go too far on a tangent with kernel debugging in this thread, just wanted to figure out the issue I was having with installing an older version.
To anyone else wanting to try downgrading from 5.10 to a 5.4 kernel in qubes 4.1, the one in security-testing is working great for me so far.
