:: [DNG] Building De{vu,bi}an kernel p…
Αρχική Σελίδα
Delete this message
Reply to this message
Συντάκτης: Mason Loring Bliss
Ημερομηνία:  
Προς: DNG
Αντικείμενο: [DNG] Building De{vu,bi}an kernel packages with embedded ZFS
Some working notes for building ZFS into the kernel using the new
mechanisms. The last time I built Debian kernels, it was with make-kpkg,
and evidently things have improved substantially since then.

I've been building custom ZFS modules for a while, as some of my hardware
that uses ZFS is too slow to really have DKMS be viable. But even with the
modules, you have the issue of needing to build a new ZFS kmod for each
upgrade, and then if for some reason you install the kmod in a different
apt run from when you installed the new kernel, you'll probably find that
depmod didn't run and your initramfs didn't catch the new module, and you
have to correct it... I've done this often enough that I've got a fairly
strict procedure where I add the new kmod-zfs on the same run as when I
install the kernel, but this requires a little more discipline than is
ideal.

So, last night I decided to try building ZFS into the kernel so I don't
need modules at all. The down side is that I'm building my own local
kernel. The upside is also that I'm building my own local kernel. :) Plus,
I can just let the system update normally, pulling whatever's newest from
my local repository. (I'll document that sometime - more reason for me to
work on our wiki project.)

A great reference for the new way to build kernel packages is here:

    https://debian-handbook.info/browse/stable/sect.kernel-compilation.html


Build prerequisites are noted here:

    https://wiki.debian.org/BuildADebianKernelPackage


Since the last time I was building my own, Linux has learned how to build
Debian kernel packages, so there's no further need to have extra tools, and
you don't have to build as root any more, both of which are nice.

Since my goal is to build ZFS into my kernel, I need to configure it and
run a supplied script. It's assumed that you've unpacked the kernel source
into a local directory:

    mkdir ~/kernel
    cd ~/kernel
    tar xf /usr/src/linux-source-4.19.tar.xz


Adding in ZFS bits:

    cd ~/zfs-0.8.5/
    ./configure
    ./copy-builtin ~/kernel/linux-source-4.19/


And then finally building the kernel:

    cd ~/kernel/linux-source-4.19/
    cp /boot/config-4.19.0-12-amd64 .config
    sed \
      -i 's/CONFIG_SYSTEM_TRUSTED_KEYS=.*/CONFIG_SYSTEM_TRUSTED_KEYS = ""/g' \
      .config
    make oldconfig  # say 'y' when asked about ZFS and
                    # whack enter when asked about additional X.509 keys
    make deb-pkg LOCALVERSION=-bliss KDEB_PKGVERSION=$(make kernelversion)-1


In truth, I edited the .config to eliminate CONFIG_SYSTEM_TRUSTED_KEYS
manually after I ran "make oldconfig". This should work as written - I've
tested it up to but excluding the actual build.

I did see the following warnings as the build process got partway through
ZFS but I've not observed any fallout from this.

      AS      fs/zfs/icp/asm-x86_64/sha1/sha1-x86_64.o
    fs/zfs/icp/asm-x86_64/sha1/.tmp_sha1-x86_64.o: warning: objtool: sha1_block_data_order()+0x11: unsupported stack pointer realignment
      AS      fs/zfs/icp/asm-x86_64/sha2/sha256_impl.o
    fs/zfs/icp/asm-x86_64/sha2/.tmp_sha256_impl.o: warning: objtool: SHA256TransformBlocks()+0x19: unsupported stack pointer realignment
      AS      fs/zfs/icp/asm-x86_64/sha2/sha512_impl.o
    fs/zfs/icp/asm-x86_64/sha2/.tmp_sha512_impl.o: warning: objtool: SHA512TransformBlocks()+0x1c: unsupported stack pointer realignment


I'm running the kernel built by this process on a couple systems now to
give it a chance to do its thing for a while. My understanding is that
running built-in is the least-tested configuration, so make sure you've got
reliable and tested back-ups. (But of course you do already, right?)

NOTE: while a lot of the GPL/CDDL interaction people complain about is
quasi-legal FUD - the whimsical notion of modules becoming derivative works,
for instance, has never been tested in court - what we're doing here is
pretty clearly defined, and while your building ZFS into the kernel and
using it yourself is Just Fine, you're unambiguously violating the GPL if
you distribute the resulting binaries to other people, so don't do that.

Finally, note also that you still have to build and install the ZFS
userland tools. This process I've documented just obviates needing a
separate kernel module. You can follow the instructions here:

    https://openzfs.github.io/openzfs-docs/Developer%20Resources/Custom%20Packages.html


TL;DR:

    cd ~/zfs-0.8.5/
    ./configure
    make -j1 deb-utils


At some point, to go along with this, I'll post my native-ZFS-root
installer scripting and notes, which assumes modules and will optionally
assume built-in ZFS before long, and which supports either LUKS or native
ZFS encryption, both with or without mirroring, on either UEFI or legacy
systems. (It's flexible. It'll even install Debian or Ubuntu.) (It'll make
the most sense for me to ship instructions for a local repository first.)

--
Mason Loring Bliss (( If I have not seen as far as others, it is because
mason@??? )) giants were standing on my shoulders. - Hal Abelson