Build testing kernels in Vagrant

[garrettr]

The build-grsec-kernel role currently uses make-kpkg, provided by the package kernel-package in Debian-based systems, to build the kernel. I have come to believe this package may be unnecessary, and it has some downsides that are annoying to work around.

I discovered the issues with this package while trying to build a grsec testing kernel in Vagrant. My process: vagrant up && vagrant ssh, make menuconfig to turn on grsec (automatic configuration for server with security priority), build it with the make-kpkg command from compile.yml. This lead to an error (which annoyingly occurred after all the compilation and linking was done, so I had to wait about 1.5 hours before I saw it):

/usr/bin/make  INSTALL_MOD_PATH=/usr/local/src/linux-4.2.6/debian/linux-image-4.2.6-grsec        \
        INSTALL_FW_PATH=/usr/local/src/linux-4.2.6/debian/linux-image-4.2.6-grsec/lib/firmware/4.2.6-grsec  \
        INSTALL_PATH=/usr/local/src/linux-4.2.6/debian/linux-image-4.2.6-grsec//boot  install
make[2]: Entering directory `/usr/local/src/linux-4.2.6'
scripts/kconfig/conf  --silentoldconfig Kconfig
make[2]: Leaving directory `/usr/local/src/linux-4.2.6'
make[2]: Entering directory `/usr/local/src/linux-4.2.6'
sh ./arch/x86/boot/install.sh 4.2.6-grsec arch/x86/boot/bzImage \
        System.map "/usr/local/src/linux-4.2.6/debian/linux-image-4.2.6-grsec//boot"
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 4.2.6-grsec /usr/local/src/linux-4.2.6/debian/linux-image-4.2.6-grsec//boot/vmlinuz-4.2.6-grsec
/etc/kernel/postinst.d/apt-auto-removal: 84: /etc/kernel/postinst.d/apt-auto-removal: cannot create /etc/apt/apt.conf.d//01autoremove-kernels.dpkg-new: Permission denied
run-parts: /etc/kernel/postinst.d/apt-auto-removal exited with return code 2
make[3]: *** [install] Error 1
make[2]: *** [install] Error 2
make[2]: Leaving directory `/usr/local/src/linux-4.2.6'
make[1]: *** [debian/stamp/install/linux-image-4.2.6-grsec] Error 2
make[1]: Leaving directory `/usr/local/src/linux-4.2.6'
make: *** [kernel_image] Error 2

Some Googling lead me to a Launchpad issue, which explained that this was a bug in trusty's version of kernel-package (12.036+nmu3). The issue was triggered by an upstream kernel change, but that change only exposed the underlying bug in the Debian package (lmkl), which was fixed in 13.003.

The upshot is that you cannot build a Linux kernel with version >= 3.15-rc1 in Ubuntu trusty due to this bug in kernel-package. We didn't notice this bug earlier because we've been building stable grsecurity kernels (based on 3.14.x) for SecureDrop. I only noticed it when I tried to build a testing kernel (based on 4.2.x). In addition, Conor and Kevin have mostly been testing on DigitalOcean with Debian Jessie VM's, and Debian Jessie contains a sufficiently up-to-date version of kernel-package such that they hadn't encountered this problem before.

Ok, but I still want to be able to build a testing kernel in Vagrant. So what are my options?

1. Continue using the trusty base box, but pull in an updated version of kernel-package
2. Use a different base box (e.g. Ubuntu Precise or Debian Jessie), that provides an updated version of kernel-package.
3. Provide and support a custom base box for kernel building
4. Consider replacing the make-kpkg with the make deb-pkg target provided in the vanilla kernel sources.

[garrettr]

Here's an interesting conversation from the Debian #debian-kernel IRC about the (lack of) difference between kernels built with make-kpkg and make deb-pkg:

garrettr_: What is the difference between kernels compiled with "make deb-pkg" (using the makefile that comes with a vanilla kernel) and kernels compiled with "make-kpkg"?
bwh: garrettr_: I'm not sure any more. kernel-package used to include extensive maintainer scripts.
bwh: and kernel-package allows some customisation that 'make deb-pkg' doesn't
bwh: but 'make deb-pkg' generally does the right thing automatically
garrettr_: bwh: Thanks. Are those customizations mostly cosmetic (e.g. in the naming of the files)?
garrettr_: I'm trying to determine if there is any really compelling reason to use make-kpkg over make deb-pkg
garrettr_: Especially since kernel-package pulls in a whopping 1.5GB of dependencies on Jessie :'(
bwh: I don't think so

[garrettr]

The primary benefit of using make-kpkg seems to be the inclusion of --overlay-dir and possibly also --initrd. See this comment from the Ubuntu Kernel/Compile docs:

Note: I couldn't get the above scripts to help in generating an initrd for the kernel - and so the built kernel couldn't boot; the only thing that worked for me was the recommendation in http://www.debian-administration.org/article/How_Do_I_Make_an_initrd_image, "use initramfs command. It is real solution."; what I used (after the custom-built kernel's *.deb's were installed), was:

cd /boot
sudo mkinitramfs -k -o initrd.img-2.6.32.15+drm33.5-mylucid 2.6.32.15+drm33.5-mylucid
sudo update-grub2

Note (Michael): that is because you need to include the right package scripts to build the initrd at package install time. The make-kpkg option is --overlay-dir. By default, make-kpkg uses /usr/share/kernel-package as an overlay directory, which contains the default, uncustomised scripts for a Debian distribution, and not the ones needed for building a Ubuntu kernel.

[conorsch]

Resolved by #36.