Autoserver/Kernel Configuration

Autoserver has a custom Linux kernel builder script, in the linux-builder directory. The system is designed to be very flexible and simple: given a .config file, the script will build and package a Linux kernel corresponding to that .config file.

This page lists the minimum required kernel configuration options needed to boot Autoserver on various platforms.

The initramfs does not have any sort of udev, so all required modules have to either be built directly into the kernel or statically loaded in the initramfs and loaded at runtime with modprobe or insmod (both of those tools are already included in the busybox that lives in the initramfs).

General

Autoserver, requires, at a minimum, the following kernel configuration options:

  • Hardware device drivers needed to access the boot disk (IDE/SATA, SD/EMMC, NVMe, SCSI, USB, etc.)
  • The HCI driver is the most common USB driver.
  • Please note that some hardware systems may implement SD card readers as USB devices (i.e. SD cards would appear as USB flash drives rather than SD cards to the operating system)
  • Block device drivers (sd_mod, sr_mod, mtdblock, etc.) needed to access the disk device as a block device, so that it can be read and mounted.
  • Filesystem drivers (vfat, ext4, etc.) and partition type support (MBR, GPT, etc.). For vfat, make sure that you have the proper NLS modules (cp437, iso8859-1) built in, too.

If you intend to add the usb_storage kernel module as built into the kernel, take note of the following notice:

  • The usb_storage module loads all USB disk drives (flash drives, hard disk drives, etc.) that are plugged into the device. It may do so in an undefined order. This means that if two or more USB drives are plugged into the system, then one of them will be e.g. /dev/sdb and one will be /dev/sdc. Which one will be /dev/sdb and which one will be /dev/sdc is undefined. As our initramfs does not have any sort of udev, it will not be possible to use /dev/disk/by-uuid/UUID or similar to identify disk drives.
  • This also means that even if the boot disk is "/dev/sda" on an IDE/SATA bus, then there could be circumstances where "/dev/sda" could inadvertently refer to an external flash drive. Such a thing may happen, for example, if the controller, cable, or disk is not plugged in or has a hardware failure. If this were to happen, then Autoserver would inadvertently look for the system.img file on the flash drive instead. In some cases, this could have obvious security implications.
  • For this reason, booting Autoserver off USB devices is discouraged, and the default Autoserver kernels do not load the usb_storage module by default.
  • If you are aware of the above implications and still want to boot Autoserver off a USB drive, then one way of protecting against the above attack is to put a "secret" value (a "nonce") at some fixed byte offset on the flash drive, and then compare that nonce at that byte offset before mounting the boot disk in the initramfs. This nonce can be theoretically be placed anywhere, but the recommended place to place this nonce would probably either be in the master boot record or the space before the first partition (be sure to check that there's actually nothing there so that you won't accidentally overwrite your bootloader while doing so). Here's a shell script fragment that does the above operations quite cleanly (sh, dd, sha256sum, grep, and mount are already included in the initramfs static busybox):
found_disk=""
for disk in /dev/sd?; do
    exec 3<"$disk"
    # Parameters to dd are as usual to extract the data at the specified location.
    if dd skip="$((byteoffset/bs))" bs="$bs" count="$((size/bs))" <&3 | sha256sum | grep -q "^$expected_sha256sum"; then
        found_disk="$disk"
        break
    else
        exec 3<&-
    done
done

mount -t vfat /proc/self/fd/3 /boot_disk
exec 3<&-

Optionally (but required if you want to debug):

  • Keyboard drivers (PS/2 and/or USB); for USB keyboards, the required modules are hid, hid_generic, and usbhid.
  • Video card drivers (may be platform specific)
  • Serial drivers (8250 on x86)

In addition:

  • Network card drivers (r8169, e1000e, etc.)
  • Namespaces and cgroups support (including the user namespace) if you want to run ctrtool and/or other container runtimes.

When in doubt, you can take an existing image that was built for that platform and boot that image on it. Take note of the kernel modules that are loaded (cat /lib/modules/"$(uname -r)"/modules.builtin, lsmod, etc.) and enable the same configuration options in the newly built kernel.

x86-64/AMD64

  • There is currently only one version for this architecture target. There will (currently) not be a 32-bit version.
  • PIIX4 is the most common hard disk driver for IDE drives. For SATA drives, you will also need to enable the ahci kernel module.
  • Similar things exist for NVMe and SCSI drives.

ARM/ARM64

ARM platforms tend to vary in their hardware, and there is usually no one-size-fits-all solution, so I will tend to only list individual boards (ones that I currently have) here and target those specific platforms. Of course, Autoserver is not limited to those platforms, and you can modify the .config file to target your specific platform if the stock kernels don't work.

Currently, we plan on maintaining two versions of the Linux kernel for these targets:

  • one (64-bit) for both the Raspberry Pi 4 and PINE64 devices, and
  • one (32-bit) for both the Raspberry Pi 3 B/B+ and the ASUS Tinker Board.

Raspberry Pi 4

  • arm64
  • armhf
  • Just enable all of the CONFIG_* options that mention "BCM2835" or "RASPBERRYPI".

Raspberry Pi 3 B/B+

  • arm64
  • armhf

Raspberry Pi Zero (W[H])

  • armv6l
  • Due to the relatively unusual toolchain needed to compile for this target (it's more advanced than armel but not quite armhf), we will likely need to reuse the Raspberry Pi Foundation's kernel (and possibly userland) for this target.

Pine A64 LTS

  • arm64

ROCKPro64

  • arm64

ASUS Tinker Board

  • armhf