An alternative approach to packaging NVIDIA's *.run drivers.

0XBF · 12-10-2022, 08:36 PM

@chrisretusn

Thanks for all the useful suggestions. I took some time to edit my SlackBuild to implement some of them:

re. the /dev bind mount:
In my original testing I didn't seem to need the /dev mount so I went with the minimum requirements for me. Its a good idea still so I added it in. The /dev/null catch makes it necessary anyways.

re. the /home mount:
The build directories I used were based on the standard SBo ones. I didn't want to change those so that builds are kept in a common place with all the other SlackBuilds I use. You can certainly use other build directories, as your method demonstrates.

re. the strip and permissions:
Thanks for the input here. I had the strip in there from the template I used and didn't actually check if it was needed or not. I checked like you suggest and see that its not needed so I took it out.

I also added the standard permissions "find and chmod" fix so that all those 444 files are made 644. Thanks for the pointer.

re. the nvidia_drm modprobe -r:
The nvidia_drm kernel module gets loaded by the installer during the .run script's installation process. If I do not unload nvidia_drm then the umount /sys step fails for me with:

Code:

umount: /tmp/SBo/chroot-nvidia-drivers/sys: target is busy.

This happens every time, if I do not unload the nvidia_drm driver before trying to umount /sys. Then it becomes this stuck mountpoint, along with the parent directory for the chroot mount.

If I unload the nvidia_drm module from within the chroot first, then the umount cleanup is fine. Taking it out would put me back to umount failing so I'll leave it in. I did streamline the code around it a little to utilize the _cleanup function better.

re. Detecting kernels in /boot:
I use elilo and copy the kernels I am using to the EFI partition. I don't use the symlinks and just call the kernels by name in my elilo.conf instead. In my EFI partition I usually keep a copy of the latest kernel, then the last version as backup from the previous kernel upgrade, and also the original kernel from initial install. Checking for links doesn't quite work in this case.

I do like the idea of looking at /boot for the kernels though. What if I did something like:

Code:

KERNEL_LIST="${KERNEL_LIST:-$(ls /boot/vmlinuz-* | grep -o '[0-9]*\.[0-9]*\.[0-9]*' | sort | uniq)}"

This would also catch -huge kernels. I haven't used a -huge kernel in years but I would guess they would need to build nvidia modules for as well?

Also I added the ':-' parameter so that other kernel versions can be supplied via the command line. E.g. The following would build only for the running kernel (in case someone only wants that and not modules for all kernels)

Code:

KERNEL_LIST=`uname -r` ./nvidia-drivers.SlackBuild

Or a defined list of kernels can be passed:

Code:

KERNEL_LIST="5.15.19 5.15.80" ./nvidia-drivers.SlackBuild

Or any other custom expression to generate a kernel list could be used.

I uploaded the nvidia-drivers.SlackBuild to my github to put the latest version I am using there. I could keep posting it here like the last two iterations but those will become un-editable at some point. I'll leave the old ones up for reference, but going forward I'll just keep the working copy here: https://github.com/0xBOBF/slackbuild...ers.SlackBuild

Thanks for the useful testing and pointers

chrisretusn · 12-11-2022, 03:58 AM

Quote:

Originally Posted by 0XBF

@chrisretusn

Thanks for all the useful suggestions. I took some time to edit my SlackBuild to implement some of them

Your welcome. Thank you for the wonderful idea/concept of using a chroot (overlayfs) do build from. That is brilliant!

Quote:

re. the /home mount:
The build directories I used were based on the standard SBo ones. I didn't want to change those so that builds are kept in a common place with all the other SlackBuilds I use. You can certainly use other build directories, as your method demonstrates.

I included this because there maybe others out there that don't use the standard SBo directories. It took me awhile to figure out why copying the installer to srcdir keep failing with file not found.

Quote:

re. the nvidia_drm modprobe -r:
The nvidia_drm kernel module gets loaded by the installer during the .run script's installation process. If I do not unload nvidia_drm then the umount /sys step fails for me with:

Code:

umount: /tmp/SBo/chroot-nvidia-drivers/sys: target is busy.

This happens every time, if I do not unload the nvidia_drm driver before trying to umount /sys. Then it becomes this stuck mountpoint, along with the parent directory for the chroot mount.

Like I said in my post above "Perhaps it's different for different systems." I ran my version of the script over a dozen times, not once has it failed to umount.

Quote:

re. Detecting kernels in /boot:
I use elilo and copy the kernels I am using to the EFI partition. I don't use the symlinks and just call the kernels by name in my elilo.conf instead. In my EFI partition I usually keep a copy of the latest kernel, then the last version as backup from the previous kernel upgrade, and also the original kernel from initial install. Checking for links doesn't quite work in this case.

Right now I am still on lilo as boot of my systems, this one (bios type only) and my laptop (with bios mode enabled). Eventually I will have to work with elilo or maybe even grub.

Quote:

I do like the idea of looking at /boot for the kernels though. What if I did something like:

Code:

KERNEL_LIST="${KERNEL_LIST:-$(ls /boot/vmlinuz-* | grep -o '[0-9]*\.[0-9]*\.[0-9]*' | sort | uniq)}"

This would also catch -huge kernels. I haven't used a -huge kernel in years but I would guess they would need to build nvidia modules for as well?

That would work. I don't use huge either but as long as it picks up the kernel version, that all that is needed. I prefer to use find for these things, this is what I would use:
find /boot -type f -name "vmlinuz-*" | cut -d- -f3 | sort | uniq

Quote:

Also I added the ':-' parameter so that other kernel versions can be supplied via the command line.

I just opted for a command line option switch to build or not to build. In my use case, I normally only use one kernel, the "stock" one that comes with Slackware. The only time I fall back to a prior kernel is on the rare case a new one in Slackware doesn't work, ironically it's usually nvidia (or virtualbox) that won't build with the new kernel.

Quote:

I uploaded the nvidia-drivers.SlackBuild to my github to put the latest version I am using there. I could keep posting it here like the last two iterations but those will become un-editable at some point. I'll leave the old ones up for reference, but going forward I'll just keep the working copy here: https://github.com/0xBOBF/slackbuild...ers.SlackBuild

I have a GitHub account, one of these days I may get around to using it.

This is the greatest thing about Slackware, we can do it our way. There is a lot of different ways to come to that same or similar results.

0XBF · 12-11-2022, 02:15 PM

Quote:

Originally Posted by chrisretusn

It took me awhile to figure out why copying the installer to srcdir keep failing with file not found.

I had added that step of copying the .run file to the build directory because I was running into permissions issues when I was developing the script in my home directory and running it in chroot from there. Copying it to a temporary build directory ($SRCDIR) first and them chrooting allowed me to run the script consistently. Sorry for any surprises

Quote:

Originally Posted by chrisretusn

I prefer to use find for these things, this is what I would use:
find /boot -type f -name "vmlinuz-*" | cut -d- -f3 | sort | uniq

A good suggestion. Getting the kernel versions with the '-' delimiter is also probably more reliable than grepping for three number fields. I updated my script to use that instead.

Thanks again for your input.

chrisretusn · 12-12-2022, 08:32 AM

Quote:

Originally Posted by 0XBF

I had added that step of copying the .run file to the build directory because I was running into permissions issues when I was developing the script in my home directory and running it in chroot from there. Copying it to a temporary build directory ($SRCDIR) first and them chrooting allowed me to run the script consistently. Sorry for any surprises

It's all on me. I chose to be nonstandard, I had to adapt to fit my build environment.

Your script worked perfectly out of the box, I knew right away it was my issue. I just thought it would be interesting to see what I ran into and how I solved it.

The issue is because of my chosen location for doing my build. Not 'TMP=${TMP:-/tmp/SBo}'.

Code:

SRCDIR=$(pwd)   # Source directy, SlackBuild and supporting files.
TMP=${SRCDIR%/*}/tmp  # Base directory for build.
PKGDIR=$TMP/package   # Files to be packaged.
OUTPUT=$TMP           # Logs and packages.

# Some directories for the overlay and chroot mount points.
INSTLRDIR=${SRCDIR%/*}/build  # Location of the NVIDIA installer.
WORKDIR=$TMP/workdir          # Required for the overlayfs.
CHROOT=$TMP/chroot            # The chroot mount point.

This fits with my build environment.

On my system, my /home/ directory is a mounted partition off root /, when 'chroot $CHROOT /home/$SRCFILE $NVOPTS
' is called I get the "No such file or directory" error. This is because /home/ is not on the same partition as / so the contents of /home/ is not included in the chroot (/home/ is there but empty). Same would apply if I used SRCDIR in my build environment. I actually considered change my TMP variable to /tmp/SBo, or just moving the nvidia installer to /tmp as /tmp/ is included in the chroot.

Then it hit me.

All I needed to do was bind mount /home/ to the chroot. I chose I choose to bind only what I needed, the location of the nvidia installer.

Code:

# Set up the overlayfs and bind mounts.
mount -t overlay overlay -o lowerdir=/,upperdir=$PKGDIR,workdir=$WORKDIR $CHROOT
mount --bind /dev $CHROOT/dev
mount --bind /proc $CHROOT/proc
mount --bind /sys $CHROOT/sys
mount --bind $INSTLRDIR $CHROOT/home/

All in all it was a fun and learning experience. Your method of packaging the installer results in awesome. Basically the only time a new package need to be created is an new version of the nvidia installer or a kernel upgrade. If there is updates to mesa,xorg-server or egl-wayland all that is needed is a reinstall of the package.

chrisretusn · 01-03-2023, 06:22 AM

I added another "test for" in my script. To test for the nouveau driver. I know installer will catch it, but I like the idea of the script catching it first.

Code:

# Make sure the nouveau driver is not in use.
# NOTE Even the the package xf86-video-nouveau in uninstall the kernel will load a nouveau driver. 
if [[ $(lsmod | grep nouveau ) ]]; then
  echo "The Nouveau kernel driver is currently in use by your system."
  echo "This driver is incompatible with the NVIDIA driver, and must be disabled before proceeding."
  echo "Please install the package xf86-video-nouveau-blacklist from extra."
  echo "Then reboot for it to take effect."
  exit 1
fi

chrisretusn · 03-01-2023, 02:34 AM

A revisit to this tread, reminds me...

I've been using this alternative build for awhile now on Slackware64-current. It is working flawlessly across several kernel upgrades and some mesa, xorg-server, egl-wayland upgrades. I have slackpkg+ setup to notify me of these upgrades.

What follows is done in runlevel 3.

With upgrades to mesa, xorg-server or egl-wayland upgrades, I simply do a reinstall of the package (no reboot).

With upgrades to the kernel I run the script to build a new package to pickup the new kernel.

Here is a example run of "how I do it" when there is a new kernel available in an update.

Using slackpkg w/slackpkg+ I first do the upgrade, saving the kernel for last. It is blacklisted.

Using 'slackpkg download kernel -noblacklist' I select the desired kernel packages (generic, modules, source) for the new kernel.

I then run 'installpkg /var/cache/packages/slackware64/*/*.txz' after that is finished I 'rm /var/cache/packages/slackware64/*/*'

I then change my symlinks in /boot/ (vmlinuz-generic-stock@ vmlinuz-generic-working@) to point to the correct vmlinuz files with "stock" being the new kernel and "working" being the last working kernel. My lilo.conf points to those links so I don't have to edit it. My version of the script uses those symlinks to determine what kernels to build for.

I then run 'mkinitrd -F -k working:stock' (I use the actual numbers 6.1.13:6.1.14) to update the initrd and of course run lilo. The default boot in lilo is "stock"

I then run the SlackBuild script and run upgradepkg on the new package.

Then reboot to the new kernel and all is well.

kjhambrick · 03-01-2023, 03:46 AM

Quote:

Originally Posted by chrisretusn

A revisit to this tread, reminds me...

I've been using this alternative build for awhile now on Slackware64-current. It is working flawlessly across several kernel upgrades and some mesa, xorg-server, egl-wayland upgrades. I have slackpkg+ setup to notify me of these upgrades.

What follows is done in runlevel 3.

With upgrades to mesa, xorg-server or egl-wayland upgrades, I simply do a reinstall of the package (no reboot).

With upgrades to the kernel I run the script to build a new package to pickup the new kernel.

Here is a example run of "how I do it" when there is a new kernel available in an update.

Using slackpkg w/slackpkg+ I first do the upgrade, saving the kernel for last. It is blacklisted.

Using 'slackpkg download kernel -noblacklist' I select the desired kernel packages (generic, modules, source) for the new kernel.

I then run 'installpkg /var/cache/packages/Slackware64/*/*.txz' after that is finished I 'rm /var/cache/packages/Slackware64/*/*"

I then change my symlinks in /boot/ (vmlinuz-generic-stock@ vmlinuz-generic-working@) to point to the correct vmlinuz files with "stock" being the new kernel and "working" being the last working kernel. My lilo.conf points to those links so I don't have to edit it. My version of the script uses those symlinks to determine what kernels to build for.

I then run 'mkinitrd -F -k working:stock' (I use the actual numbers 6.1.13:6.1.14) to update the initrd and of course run lilo. The default boot in lilo is "stock"

I then run the SlackBuild script and run upgradepkg on the new package.

Then reboot to the new kernel and all is well.

chrisretusn --

Thanks for the recap.

It is much like what I do with installpkg with upgradepkg on Slackware 15.0

One thinng I don't understand is `rm /var/cache/packages/Slackware64/*/*"

What does that do for you ?

Thanks again.

-- kjh

chrisretusn · 03-02-2023, 02:19 AM

Quote:

Originally Posted by kjhambrick

chrisretusn --

Thanks for the recap.

It is much like what I do with installpkg with upgradepkg on Slackware 15.0

One thinng I don't understand is `rm /var/cache/packages/Slackware64/*/*"

What does that do for you ?

Thanks again.

-- kjh

You're welcome.

Note: In my post above `rm /var/cache/packages/Slackware64/*/*" should be 'rm /var/cache/packages/slackware64/*/*'; I fixed it.

This is probably overkill on my explanation.

Both slackpkg and slackpkg w/slackpkg+ use /var/cache/packages/ to store packages during upgrades. Under the /package/ directory there is a /slackware64/ tree of sub-directories. By default the packages are removed after the upgrade is completed (see caveat below). Using "slackpkg download" does not remove any packages from the cache.

The 'rm /var/cache/packages/slackware64/*/*' simply removes the kernel packages and their signature files from the a/ and k/ sub-directories. It also will remove all files in the all of those sub-directories too without touching the directory structure.

Why I remove those packages? I don't want 'installpkg /var/cache/packages/slackware64/*/*.txz' to install older versions of kernel packages in the cache. Another reason, since I use a local mirror for upgrades, the packages in the cache are symlinked to mirror packages. When the mirror is updated those link will be broken. A third reason is easier to type that a fully qualified file name.

One big caveat! If you have "DELALL=off" (default is on) set in slackpkg.conf, you will not want to use my method of clearing the cache. My method in using installpkg would not be good either.

Best in this case to use fully qualified file names with installpkg and not bother with "rm"

If using slackpkg+, if the variable DOWNLOADONLY=on (default is off) is set the same would apply.