New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement compatibility with DKMS (Nvidia, etc.) #1091

Open
dustymabe opened this Issue Nov 7, 2017 · 10 comments

Comments

Projects
None yet
6 participants
@dustymabe
Collaborator

dustymabe commented Nov 7, 2017

rpm-ostree version info:

  centos-atomic-host:centos-atomic-host/7/x86_64/standard
                Version: 7.1708 (2017-09-15 15:32:30)
                 Commit: 33b4f0442242a06096ffeffadcd9655905a41fbd11f36cd6f33ee0d974fdb2a8
           GPGSignature: 1 signature
                         Signature made Fri 15 Sep 2017 05:17:39 PM UTC using RSA key ID F17E745691BA8335
                         Good signature from "CentOS Atomic SIG <security@centos.org>"

When installing nvidia kmod it fails:

# rpm-ostree install epel-release && reboot
#
# cat <<EOF > /etc/yum.repos.d/nvidia.repo
[nvidia]
baseurl=https://developer.download.nvidia.com/compute/cuda/repos/rhel7/x86_64/
enabled=1
gpgcheck=0
EOF
#
# rpm-ostree install nvidia-kmod
....
....
Resolving dependencies... done
Overlaying... done

Creating symlink /var/lib/dkms/nvidia/384.81/source ->
                 /usr/src/nvidia-384.81

DKMS: add completed.

Creating symlink /var/lib/dkms/nvidia/384.81/source ->
                 /usr/src/nvidia-384.81

DKMS: add completed.

Creating symlink /var/lib/dkms/nvidia/384.81/source ->
                 /usr/src/nvidia-384.81

DKMS: add completed.
error: Running %post for nvidia-kmod: Executing bwrap(/usr/nvidia-kmod.post): Child process exited with code 8

From the journal:

Nov 07 22:04:30 vanilla-c7atomic rpm-ostree[13001]: /usr/share/info/dir: Read-only file system
Nov 07 22:04:30 vanilla-c7atomic rpm-ostree[13001]: /usr/share/info/dir: Read-only file system
Nov 07 22:04:30 vanilla-c7atomic rpm-ostree[13001]: mkdir: cannot create directory ‘/var/lib/dkms’: Read-only file system
Nov 07 22:04:30 vanilla-c7atomic rpm-ostree[13001]: ln: failed to create symbolic link ‘/var/lib/dkms/nvidia/384.81/source’: No such file or directory
Nov 07 22:04:31 vanilla-c7atomic rpm-ostree[13001]: mkdir: cannot create directory ‘/var/lib/dkms’: Read-only file system
Nov 07 22:04:31 vanilla-c7atomic rpm-ostree[13001]: ln: failed to create symbolic link ‘/var/lib/dkms/nvidia/384.81/source’: No such file or directory
Nov 07 22:04:31 vanilla-c7atomic rpm-ostree[13001]: ls: cannot access /var/lib/dkms/nvidia/384.81/source: No such file or directory
Nov 07 22:04:31 vanilla-c7atomic rpm-ostree[13001]: Error! The directory /var/lib/dkms/nvidia/384.81/source/
Nov 07 22:04:31 vanilla-c7atomic rpm-ostree[13001]: does not appear to have module source located within it.  Build halted.
Nov 07 22:04:31 vanilla-c7atomic rpm-ostree[13001]: mkdir: cannot create directory ‘/var/lib/dkms’: Read-only file system
Nov 07 22:04:31 vanilla-c7atomic rpm-ostree[13001]: ln: failed to create symbolic link ‘/var/lib/dkms/nvidia/384.81/source’: No such file or directory
Nov 07 22:04:31 vanilla-c7atomic rpm-ostree[13001]: ls: cannot access /var/lib/dkms/nvidia/384.81/source: No such file or directory
Nov 07 22:04:31 vanilla-c7atomic rpm-ostree[13001]: Error! The directory /var/lib/dkms/nvidia/384.81/source/
Nov 07 22:04:31 vanilla-c7atomic rpm-ostree[13001]: does not appear to have module source located within it.  Build halted.
Nov 07 22:04:31 vanilla-c7atomic rpm-ostree[13001]: Txn /org/projectatomic/rpmostree1/centos_atomic_host failed: Running %post for nvidia-kmod: Executing bwrap(/usr/nvidia-kmod.post): Child process exited with code 8

The scriptlets are:

-bash-4.2# rpm -qp nvidia-kmod-384.81-2.el7.x86_64.rpm --scripts
warning: nvidia-kmod-384.81-2.el7.x86_64.rpm: Header V3 RSA/SHA512 Signature, key ID 7fa2af80: NOKEY
postinstall scriptlet (using /bin/sh):
dkms add --rpm_safe_upgrade -m nvidia -v 384.81
dkms build -m nvidia -v 384.81
dkms install --force -m nvidia -v 384.81
preuninstall scriptlet (using /bin/sh):
dkms remove --rpm_safe_upgrade -m nvidia -v 384.81 --all || :
postuninstall scriptlet (using /bin/sh):
if [ "$1" -eq "0" ] ; then
    dracut -f /boot/initramfs-$(uname -r).img $(uname -r)
fi

@cgwalters cgwalters changed the title from %post compat: installing nvidia-kmod fails to Implement compatibility with DKMS (Nvidia, etc.) Nov 7, 2017

@cgwalters

This comment has been minimized.

Member

cgwalters commented Nov 7, 2017

Yeah, there's a huge world of stuff here. Supporting dkms is going to require a lot of work.

@Conan-Kudo

This comment has been minimized.

Conan-Kudo commented Dec 4, 2017

@cgwalters Would this also cover supported akmods as a mechanism too? Or would that be easier than DKMS?

@cgwalters

This comment has been minimized.

Member

cgwalters commented Dec 4, 2017

Would this also cover supported akmods as a mechanism too? Or would that be easier than DKMS?

I have no idea honestly without diving in a lot. I suspect they're going to be mostly equivalent but it's really just a wild guess.

@Conan-Kudo

This comment has been minimized.

Conan-Kudo commented Dec 29, 2017

@cgwalters The Akmods mechanism makes kmod RPMs for the kernel packages installed and installs them, rather than building kmods for the running kernel and just slotting them in.

This was recently integrated into Fedora proper.

@cgwalters

This comment has been minimized.

Member

cgwalters commented May 16, 2018

@jlebon

This comment has been minimized.

@cgwalters

This comment has been minimized.

Member

cgwalters commented Aug 24, 2018

I said this elsewhere but to repeat here; I think we could pretty easily implement a generic hook in rpm-ostree upgrade that calls out to a user-specified external process, which would accept as input the new ostree, and could perform arbitrary modification (overlayfs), which would then be included in the final commit.

Where things bifurcate a lot here is - do you install the equivalent of dnf builddep kernel on the host? Let's call this option #1. If you do...that's a whole lot of layered stuff and is (IMO) against the larger goals. Or, option #2 - does the hook do what the atomic-wireguard stuff does and basically install the kernel+builddeps in a container? There's some nontrivial infrastructure to hook up rpm-ostree + build container in such a way - do we ship it as a package/container?

Option #3 is to have rpm-ostree itself create a container, reusing the same packages. This would be totally possible, it's a system-level variant of the rpm-ostree ex container support that we have today. But it'd be some nontrivial work in rpm-ostree, and increase our overlap with general-purpose container tools.

What would mix both #2 and #3 is a podman/containers-storage "backend" that knows how to call out to rpm-ostree to do the heavy lifting for the filesystem builds.

@alexhaydock

This comment has been minimized.

alexhaydock commented Aug 24, 2018

Perhaps it's not quite the right issue to discuss this in, but I'd just like to raise the concern that ideally whatever solution for is proposed for this issue should not make it too difficult for an end-user to sign the resulting akmods-built modules for Secure Boot using their own keypair.

As this issue identifies, losing easy access to ZFS, VirtualBox and the NVidia Drivers is a major concern for new users to Atomic/Silverblue, but I think it's also a concern if a user is only able to access the above at the cost of disabling Secure Boot.

@znmeb

This comment has been minimized.

znmeb commented Sep 7, 2018

@alexhaydock Not just new users! I've been a Linux workstation / laptop user since Red Hat 6.2 and if a distro won't support my AMD GCN 1.1 card or WiFi hotspot or HP Omen laptop with an NVidia 1050Ti, I'll run a different distro. Secure Boot is over-rated; if I have to disable it to use my machine, that's exactly what I'll do.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment