Old kernel-devel package in fedora vm

[chris-freedom]

Qubes OS version (e.g., R3.2):

Affected TemplateVMs (e.g., fedora-24, if applicable):

---

Expected behavior:

install same version as a kernel 4.4.67-13

Actual behavior:

No package kernel-devel-4.4.67-13.pvops.qubes.x86_64 available.
Error: Unable to find a match.

Steps to reproduce the behavior:

sudo dnf install kernel-devel-$(uname -r)

General notes:

Current kernel version is 4.4.67-13 but latest kernel-devel i can install is kernel-devel-1000:4.4.31-11.pvops.qubes.x86_64. How can i fix it?

---

Related issues:

[jaja654]

When I wanted to compile a kernel module for dom0 I run into the same issue. My solution is somewhat convoluted, as I am a debian user with pretty limited fedora knowledge:

1. I could only get the correct kernel-devel package in dom0, grabbed it in download only mode.
   sudo qubes-dom0-update --action=download kernel-devel

(it is possible that a VM based on the fedora-23 template has the correct package, but I don't have the f-23 template anymore.)

2. send the rpm to a debian VM
   qvm-copy-to-vm <your-fine-VM> kernel-devel-4.4.67-13.pvops.qubes.x86_64.rpm

3. convert the rpm into deb with alien (aptitude install alien) and install it (dpkg -i ...)

4. build kernel module with dkms.

5. final installation fails as kernel modules are in a read-only fs in the VM, but no problem, the built .ko file(s) are needed in dom0 anyways and can be sent there (with qvm-run --pass-io ...) and succesfully inserted with insmod ....

[jaja654]

When I wanted to compile a kernel module for dom0 I run into the same issue. My solution is somewhat convoluted, as I am a debian user with pretty limited fedora knowledge:

1. I could only get the correct kernel-devel package in dom0, grabbed it in download only mode.
   sudo qubes-dom0-update --action=download kernel-devel

(it is possible that a VM based on the fedora-23 template has the correct package, but I don't have the f-23 template anymore.)

2. send the rpm to a debian VM
   qvm-copy-to-vm <your-fine-VM> kernel-devel-4.4.67-13.pvops.qubes.x86_64.rpm

3. convert the rpm into deb with alien (aptitude install alien) and install it (dpkg -i ...)

4. build kernel module with dkms.

5. final installation fails as kernel modules are in a read-only fs in the VM, but no problem, the built .ko file(s) are needed in dom0 anyways and can be sent there (with qvm-run --pass-io ...) and succesfully inserted with insmod ....

[marmarek]

@jaja654 I think your procedure is the simplest currently possible.

[marmarek]

@jaja654 I think your procedure is the simplest currently possible.

[mtalexan]

This process is still required when building any kernel modules as of the 4.0 release as well. However there's a modification to the download command that's required in 4.0 since the dnf plugins are all force-disabled and the action=download is only available via a plugin.
The new way to get the download is:
sudo qubes-dom0-update --downloadonly kernel-devel
but then you have to manually go retrieve it from /var/lib/qubes/updates/rpm/.
This requires that the package was not previously installed in your dom0.

If you previously installed the kernel-devel package in your dom0 (on purpose or by accident), you have to force a "re-install" as well so it will download the package instead of a determining it's already installed and not downloading it. The command is then:
sudo qubes-dom0-update --downloadonly --action=reinstall kernel-devel
followed by retrieving it from the cached folder as previously mentioned.

Note that unless you have keepcache=1 in your /etc/dnf/dnf.conf file (it's not there by default), that rpm file will only be present in the cache immediately after running the above qubes-dom0-update command and before running any others.

[mtalexan]

This process is still required when building any kernel modules as of the 4.0 release as well. However there's a modification to the download command that's required in 4.0 since the dnf plugins are all force-disabled and the action=download is only available via a plugin.
The new way to get the download is:
sudo qubes-dom0-update --downloadonly kernel-devel
but then you have to manually go retrieve it from /var/lib/qubes/updates/rpm/.
This requires that the package was not previously installed in your dom0.

If you previously installed the kernel-devel package in your dom0 (on purpose or by accident), you have to force a "re-install" as well so it will download the package instead of a determining it's already installed and not downloading it. The command is then:
sudo qubes-dom0-update --downloadonly --action=reinstall kernel-devel
followed by retrieving it from the cached folder as previously mentioned.

Note that unless you have keepcache=1 in your /etc/dnf/dnf.conf file (it's not there by default), that rpm file will only be present in the cache immediately after running the above qubes-dom0-update command and before running any others.

[mtalexan]

FYI for future readers:
#2844 talks about the topic of issues with building kernel modules for use in VMs. All the default VMs are based on the Qubes-created kernels. These are very old though and there's a mismatch between what TemplateVMs like Fedora-* and Debian-* think is the current kernel and what's actually the current kernel they're using.
The "solution" as of Qubes 4.0 and earlier is to not use the Qubes provided kernel for any VM in which you need to build against the kernel (e.g. build kernel modules). Instead you clone the template VM, and in the clone you change the kernel that's in use to be the modern one the distribution provides (i.e. the kernel package provided by Debian or Fedora). Instructions for doing this are here: https://www.qubes-os.org/doc/managing-vm-kernel/#using-kernel-installed-in-the-vm

[mtalexan]

FYI for future readers:
#2844 talks about the topic of issues with building kernel modules for use in VMs. All the default VMs are based on the Qubes-created kernels. These are very old though and there's a mismatch between what TemplateVMs like Fedora-* and Debian-* think is the current kernel and what's actually the current kernel they're using.
The "solution" as of Qubes 4.0 and earlier is to not use the Qubes provided kernel for any VM in which you need to build against the kernel (e.g. build kernel modules). Instead you clone the template VM, and in the clone you change the kernel that's in use to be the modern one the distribution provides (i.e. the kernel package provided by Debian or Fedora). Instructions for doing this are here: https://www.qubes-os.org/doc/managing-vm-kernel/#using-kernel-installed-in-the-vm