#!/bin/sh
# auto/config - live-build configuration for the bty live env.
#
# live-build invokes this script when (re)configuring the build dir
# (typically the first ``lb build`` run, and again whenever ``lb build``
# itself calls ``lb config``). Encodes our lb config args: Debian
# trixie, amd64, no debian-installer, no memtest, no apt recommends,
# no security.
#
# Two output modes, switched by the ``BTY_USB_ISO`` environment
# variable:
#
#   - **default (netboot)**: kernel + initrd + squashfs trio for the
#     ``live-x86`` PXE-flash flow. Server hosts these three files
#     over HTTP and clients chain into them via iPXE.
#   - **BTY_USB_ISO=1 (iso-hybrid)**: hybrid ISO image bootable from
#     CD or USB stick (BIOS + UEFI). Used by the ``usb-iso`` variant.
#     Adds ``--bootloaders syslinux,grub-efi`` for dual-firmware boot
#     and ``bty.mode=interactive`` to the kernel cmdline so
#     ``bty-tui-on-tty1.service`` fires on USB boot the same way it
#     fires for the PXE-tui flow.
#
# Both modes use the same chroot package set + hooks; only the binary
# packaging differs. ``lb build`` re-runs this script during its
# internal ``lb config`` step, so the env var must be set in the
# build invocation's environment - not just at the initial config
# call. ``cijoe/scripts/usb_iso_build.py`` does this via ``sudo env
# BTY_USB_ISO=1 lb build``.
#
# Requires live-build 20240208+ (Debian trixie or newer) which
# fetches ``dists/<release>/main/Contents-<arch>.gz`` from the
# per-component layout Debian now publishes. Ubuntu's stock
# live-build 20230502 still uses the obsolete top-level URL and
# 404s on every active Debian release; release.yml's live job
# pulls the trixie .deb explicitly to work around that.
set -e

# Plymouth lives in ``config/package-lists/bty-plymouth.list.chroot.usb``
# as an inert template (the ``.usb`` suffix is not a live-build-
# recognised extension; live-build ignores the file unless it
# matches ``.list.chroot[_<scope>]``). We activate it by copying
# to ``bty-plymouth.list.chroot`` only on USB bakes, and remove
# the active copy on netboot bakes. The hook
# ``hooks/normal/0950-bty-plymouth.hook.chroot`` self-guards on
# the presence of plymouthd, so an absent plymouth simply skips
# the theme setup with no error.
#
# Why split: USB boot is the operator's first impression (mascot
# splash is worth the disk + init cost). Netboot runs in headless
# / KVM / PXE contexts where plymouth adds latency (the MS-01 /
# EPYC plymouth-quit-wait wedges came from this) and provides
# zero operator value.
PLYMOUTH_SRC="config/package-lists/bty-plymouth.list.chroot.usb"
PLYMOUTH_DST="config/package-lists/bty-plymouth.list.chroot"

if [ "${BTY_USB_ISO:-}" = "1" ]; then
    BINARY_IMAGES=iso-hybrid
    BOOTLOADERS_OPTS="--bootloaders syslinux,grub-efi"
    # ``splash`` triggers plymouth to render the bty boot splash
    # (see ``hooks/normal/0950-bty-plymouth.hook.chroot``). Without
    # it the kernel scrolls boot messages over our suppressed
    # bootloader menu, which works but doesn't show bty branding
    # during the kernel boot window.
    BOOTAPPEND="boot=live components quiet splash noeject modprobe.blacklist=nouveau nouveau.modeset=0 bty.mode=interactive bty.version=__BTY_VERSION__"
    # Activate the plymouth package list for the USB bake.
    if [ -f "${PLYMOUTH_SRC}" ]; then
        cp "${PLYMOUTH_SRC}" "${PLYMOUTH_DST}"
    fi
else
    BINARY_IMAGES=netboot
    BOOTLOADERS_OPTS=""
    # No ``splash`` -- plymouth isn't installed in this variant.
    # ``plymouth.enable=0`` is belt-and-braces in case a future
    # change pulls plymouth in transitively; with the package
    # absent it's a no-op.
    # ``modprobe.blacklist=nouveau nouveau.modeset=0`` keep the
    # in-tree Nvidia driver from binding -- nouveau stalls early
    # boot 10-60s on Maxwell/Pascal/Turing cards probing for
    # firmware bty doesn't need.
    BOOTAPPEND="boot=live components quiet plymouth.enable=0 modprobe.blacklist=nouveau nouveau.modeset=0 bty.version=__BTY_VERSION__"
    # Deactivate the plymouth package list for the netboot bake.
    rm -f "${PLYMOUTH_DST}"
fi

# shellcheck disable=SC2086 # BOOTLOADERS_OPTS is intentionally word-split
lb config noauto \
    --mode debian \
    --distribution trixie \
    --architectures amd64 \
    --archive-areas "main non-free-firmware" \
    --firmware-chroot true \
    --binary-images "${BINARY_IMAGES}" \
    --debian-installer none \
    --memtest none \
    --apt-recommends false \
    --security false \
    ${BOOTLOADERS_OPTS} \
    --bootappend-live "${BOOTAPPEND}" \
    "${@}"
# ``--archive-areas "main non-free-firmware"`` unlocks the
# ``firmware-*`` packages. Default areas are just ``main``, which
# silently drops every firmware blob and produces a live env where
# i915 wedges the GPU on probe and certain NIC / WiFi chipsets fail
# to load. Debian split ``non-free-firmware`` out of ``non-free``
# in bookworm precisely so this archive can be enabled on its own.
#
# ``--firmware-chroot true`` pulls ``firmware-linux-nonfree`` (a
# metapackage that Depends on EVERY individual nonfree ``firmware-*``
# package: realtek, iwlwifi, atheros, brcm80211, mediatek, ath11k,
# bnx2/bnx2x, netronome, nvidia-graphics, amd-graphics, and a long
# tail of server-NIC + old-WiFi blobs). The size cost (~300 MiB
# compressed) buys "boots on whatever bare-metal box the operator
# points it at" -- the alternative is the operator hits a missing
# firmware -> driver init failure -> dead NIC and can't proceed.
# A curated list is too narrow: Realtek WiFi/BT chipsets alone
# span half a dozen firmware packages and consumer mini-PCs cycle
# them quickly.
# The trixie-backports archive layered via
# ``config/archives/backports.list.chroot`` plus the pin in
# ``config/preferences/backports.pref.chroot`` makes apt pull the
# newest kernel + firmware Debian ships, not just trixie's.
# Bootloader-menu suppression: see
# ``hooks/binary/0500-bty-skip-bootloader-menu.hook.binary``. Don't
# add ``--syslinux-timeout`` here -- live-build trixie doesn't
# recognise that flag and ``lb config`` errors out.
