Build Linux (and ZFS) manually for Devuan

I run Devuan Linux, because I don't like systemd and I do like Debian. I have root on ZFS, which is a great way to protect your data but also comes with challenges. I wanted to install Linux 6.14 because I want NTSYNC support, but the latest release of OpenZFS for Linux does not support Kernel 6.14. However, the master branch of ZFS does support it, and has for a while now, so I decided to build ZFS myself so that I could upgrade my kernel.

Latest OpenZFS on Debians

If you don't use ZFS, then you can skip this section. Because OpenZFS is not part of the Linux kernel in more ways than one, but is also very intimately tied to it, it's very sensitive to Linux versions. A very new kernel will likely necessitate a new OpenZFS.

The really short form is that you have to follow the OpenZFS build instructions explicitly, and then I had to tidy up the install before rebooting because the ZFS init scripts got installed as non-executable. I had trouble when trying to build both native and non-native packages; just do all the steps in order, creating a fresh ZFS source tree instead. The bare process is to upgrade ZFS and reboot on your current kernel so that you have a running ZFS which supports the kernel you are going to build, build and install the new kernel (DKMS then builds ZFS for your new kernel automatically) and then reboot again.

One thing you should know before building debian packages for things is that they wind up in the parent directory from where you ran the build, so you should first create a directory for each project you're going to work on. For example:

mkdir ~/src
cd ~/src
mkdir linux zfs

Now you can do the following steps:

cd ~/src/zfs
git clone https://github.com/openzfs/zfs
cd zfs
git checkout master
sh autogen.sh
./configure
make -s -j$(nproc)

If this succeeds, you can now:

make native-deb

...and the build system will create the packages in ~/src/zfs. This is a great time to take a snapshot of your important filesystems; you can easily destroy the snapshot later if everything goes well. If you have another Linux installed somewhere you can use this to restore your system. I have Devuan installed with root on ext4 on a separate disk as a fallback, but you could just use the installer system on a USB stick. I strongly suggest that if you do not have a fallback disk in your system, you always keep the installer system ready.

Anyway, all that said, once the build completes you can go back to the parent directory and install the new ZFS packages you've just created:

cd ..
ls -1 *.deb | grep -v dracut | xargs sudo dpkg --auto-deconfigure -i

If for some reason you are using dracut (which I have used, and which did work OK with Devuan with root on ZFS) change the dracut in the command line to initramfs.

I mentioned above that there is some cleanup to do. When I first rebooted, I found that my ZFS pools had mostly not mounted. The system booted, but a lot of things didn't run. This was because of an error in the install scripts for ZFS which I haven't bothered to track down. Here's how to fix it if necessary, and you can and should do this before rebooting1 if the files /etc/init.d/zfs-* aren't executable:

cd /etc/init.d
sudo chmod +x zfs-*
for i in zfs*; do sudo update-rc.d $i defaults; done

If you get any errors about dependencies, re-run the last line again. Once this is done (and with no errors) you should be able to successfully reboot the system and proceed with building linux. As a side note, variations on this are a good way to just reset runlevels after big updates when you're having boot weirdness. You can force uninstall all of the init scripts from all of the runlevels, then do the above but for * instead of zfs-*, again repeating until the errors stop. This will enable everything installed on your system which has an init script, so you then might have to remove some things, but it is effective at making sure all of the init scripts are in the right order. See the manpage for update-rc.d for more info.

Building Linux for Debians

One thing to know about the picking a kernel process in general is that you can go just look at the official directory to see what versions are available before downloading. For instance, for a 6.x kernel, I visit https://mirrors.edge.kernel.org/pub/linux/kernel/v6.x/.

cd ~/src/linux
wget https://kernel.org/pub/linux/kernel/v6.x/linux-6.14.6.tar.xz
tar xaf linux-6.14.6.tar.xz
cd linux-6.14.6
cp /boot/config-`uname -r` ./.config
scripts/config --disable DEBUG_INFO
scripts/config --disable DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT
make nconfig

If you want to build all the debug info, skip the two lines about DEBUG_INFO. You can also make "oldconfig" here instead of "nconfig" if you'd rather be quizzed about everything that wasn't in your .config, which is potentially a fun or tedious process. Or, "xconfig" if you prefer to click. Your starting point will be whatever configuration worked for the kernel you're running now. The more recent your current kernel, the more likely this is to produce a working kernel configuration with no changes. If your whole goal was just to get a working but newer kernel, and you are starting from a recent kernel, you can simply save and exit now. Otherwise, go make your changes and then do that, then:

make clean
make -j$(nproc) bindeb-pkg

If all goes well, this will produce some packages in the parent directory.

cd ..
dpkg -i *.deb

DKMS will build your installed DKMS-based modules for your new kernel. Now you should be able to reboot again and be fully up to date.

nvidia on Debians

I also use nvidia graphics; I suspect that my next computer will use an AMD GPU, but I have been a consistent nvidia user for many years of upgrades now. I have found that if you want to run native Steam (not in a container) then you need to use multiarch, and the runfile installer works best with a multiarch system. I also use CUDA. Whether you use the CUDA installer for Debian or just install the driver alone, the runfile will save you a lot of trouble. I mention the nvidia driver at all here because you may need to update it before installing the very latest Linux kernel. You can install first the one and then the other, in case the latest driver is newer than the one that comes with CUDA. I haven't had this cause me a problem yet. 

What has troubled me is that I use a tmpfs for the system on /tmp and use my own temp dir in ~/tmp, and the nvidia installer doesn't respect $TMPDIR like I've found most things do. It does however have an option --tmpdir=/whatever.  You will probably have to drop to single user mode, or what's easier, reboot to recovery mode before you run the installer. You can't update the driver while you're using graphics.

End notes on compiling stuff

(to be followed by foot notes)

If you happen to have a bunch of computers in your house, you can make them all cooperate on compiling software with their spare computer time with distcc.

More popularly useful and handy while you are fiddling around with new kernels, ccache caches compile output, determines when you're recompiling something you just compiles because of the way the build process works, and loads the result from the cache. If you want to use it you only need to do two special things after installing it. One, make sure its directory /usr/lib/ccache is first (or at least very early) in your path. Two, specify a cache directory with $CCACHE_DIR. This can speed up the Linux kernel re-build process quite a lot, so if you're trying out different build options, modules etc. it's a very good thing.

If you have plenty of memory and would like to use your computer for other things while you compile your kernel, you might like to know how to make it use no more resources than you're not already using for anything else. This will do it: (I call my script "nicer"):

nice ionice -c 3 $*

• 1

  But it will also work after rebooting; after you do this, it's most convenient to just reboot again.