SchOS/tools/posix/mkiso.sh
Nexoniarz 651899220c boot: the BIOS loader is gone
1449 lines of boot/bios/, tools/sign.pl and tools/padstage2.pl, plus the
build rules, the disk image and the ISO entry that existed to carry them.

Everything since roughly 2012 boots UEFI, and CSM -- the firmware-side
BIOS emulation that lets a legacy loader run on such a machine at all --
has been going away since Intel dropped support for it in 2020. So this
is not a path being retired early; it is one whose remaining hardware is
already the exception.

The cost was never the code, it was the tax on everything near it. Stage
2 had a 65-sector ceiling it overflowed silently -- 25440 bytes against
24576 -- and because the kernel is written at sector 1 + STAGE2_SECTORS,
an overflowing loader was overwritten by the very kernel it was loading.
The resolution list could not be shared with UEFI either: VBE mode
setting is INT 10h, so matching it needed unreal mode, which is the
riskiest code in the tree for a feature that already worked elsewhere.

What replaces schos.img is the staged ESP, handed to QEMU as a virtual
FAT volume. That is a development arrangement and not an installable
disk; a real GPT image with a real FAT partition is the installer's job,
and until it exists nothing here writes a disk a machine boots unaided.
Secure Boot is untouched too -- the loader is unsigned.

The ISO keeps one El Torito entry, the FAT image holding loader and
kernel. It never booted from a USB stick via BIOS anyway: the firmware
presents the stick as a hard disk while stage2main.c read the kernel back
over ATAPI.

The 32-bit multiboot entry in entry.S now has no caller and is left in
place. Deleting kernel entry code is its own change with its own way of
failing silently, and it should not ride along with this one.

Ported with it: run.ps1, the six screenshot tools, and schcom_test.sh,
each with its own OVMF varstore copy so no run inherits another's UEFI
variables.

Two things this shook out. OVMF now belongs in `all`: nothing boots
without firmware, `make clean` wipes build/ including the copy fetched
from the host, and a clean followed by a build left every run script
throwing. And it cannot be listed as a prerequisite at the top of the
file -- make expands prerequisites when it reads the line, and
$(OVMF_CODE) is defined further down, so naming it there appends nothing
and says nothing.

Verified from a clean tree: 110 [ok] and no failures on the full suite,
the ISO boots with no hard disk attached, schfs-check passes, schcom's
end-to-end pixel test passes, and fbshot captures a real 1280x800 frame.
2026-08-11 10:20:28 +02:00

155 lines
6.6 KiB
Shell

#!/bin/sh
# Build a bootable SchOS ISO.
#
# tools/posix/mkiso.sh [output.iso]
#
# The disc carries one El Torito boot entry and a real directory tree:
#
# /boot/efiboot.img a FAT image holding the loader and the kernel
# /EFI/BOOT/BOOTX64.EFI the same loader, visible as a file on the disc
# /bin /etc /usr ... the staged sysroot, as an ordinary hierarchy
#
# --- Why only one entry -----------------------------------------------------
#
# There was a second, for BIOS: cdboot and stage2 concatenated with the kernel
# and loaded by El Torito in no-emulation mode. The BIOS loader is gone, so the
# entry that started it is too.
#
# What UEFI wants is not that mechanism at all. Firmware does not run
# no-emulation boot code; it looks for a FAT filesystem containing
# EFI/BOOT/BOOTX64.EFI and hands that volume to the application it finds. So
# the entry is a FAT image built with mtools, and it carries the kernel as well
# as the loader -- BOOTX64.EFI opens \schos\kernel on the volume it was itself
# loaded from, and for a UEFI boot that volume is this FAT image, not the ISO
# 9660 tree around it. Without the kernel in here the loader comes up and halts
# with EFI_NOT_FOUND, which is what it did.
#
# The loader is also copied into the ISO tree at /EFI/BOOT/BOOTX64.EFI, because
# some firmware looks there directly when booting from a USB stick.
#
# --- Booting from a USB stick -----------------------------------------------
#
# -isohybrid-gpt-basdat adds a GPT that marks the FAT image as a basic data
# partition, so writing this .iso to a stick with dd produces something UEFI
# will boot. That was already the only arrangement that worked from a stick:
# the firmware presents the medium as a hard disk, while the BIOS loader read
# the kernel back over ATAPI, so it never booted this way even when it existed.
#
# --- Rock Ridge and Joliet --------------------------------------------------
#
# Plain ISO 9660 gives 8.3 uppercase names with no permissions, so the sysroot
# would arrive as /BIN/TOYBOX.;1 with every file marked the same. Rock Ridge
# restores POSIX names, permissions and symlinks for Unix readers; Joliet does
# long names for Windows. Both are additions to the same image -- a reader that
# understands neither still sees a valid, if ugly, ISO 9660 disc.
#
# -cache-inodes matters more than it looks: the sysroot is a toybox multicall
# binary with a couple of hundred hard links to it. Without inode caching each
# link becomes its own copy and the disc grows by two orders of magnitude.
set -e
BUILD=${BUILD:-build}
OUT=${1:-schos.iso}
STAGING="$BUILD/iso"
SYSROOT=${SYSROOT:-sysroot}
KERNEL="$BUILD/kernel/kernel"
EFIAPP="$BUILD/uefi/BOOTX64.EFI"
[ -f "$KERNEL" ] || { echo "mkiso: missing $KERNEL -- run make first" >&2; exit 1; }
[ -f "$EFIAPP" ] || { echo "mkiso: missing $EFIAPP -- run 'make uefi' first" >&2; exit 1; }
# mtools is not optional any more. It used to be: without it the disc fell back
# to being BIOS-only, which was a degraded disc rather than no disc. There is no
# other entry to fall back to now, so a missing mformat means the ISO would not
# boot anything, and failing here says so instead of shipping it.
if ! command -v mformat >/dev/null 2>&1 || ! command -v mcopy >/dev/null 2>&1; then
echo "mkiso: need mtools (mformat, mcopy) to build the EFI system partition" >&2
echo " Fedora: sudo dnf install mtools" >&2
echo " Debian/Ubuntu: apt install mtools" >&2
exit 1
fi
rm -rf "$STAGING"
mkdir -p "$STAGING/boot" "$STAGING/EFI/BOOT"
cp "$EFIAPP" "$STAGING/EFI/BOOT/BOOTX64.EFI"
# The FAT image for the UEFI El Torito entry.
#
# It carries the kernel as well as the loader. BOOTX64.EFI opens \schos\kernel
# on the volume it was itself loaded from, and for a UEFI boot that volume is
# this FAT image -- not the ISO 9660 tree around it. Without the kernel in here
# the loader comes up and halts with EFI_NOT_FOUND, which is what it did.
#
# The ISO 9660 tree still carries the sysroot for a running system to read; the
# loader's own two files live in here because that is the volume it is handed.
#
# Sized from what actually goes in plus slack, rather than fixed: a hardcoded
# size is a thing that breaks quietly the first time the kernel grows.
EFI_IMG="$STAGING/boot/efiboot.img"
payload_kb=$(( ( $(wc -c < "$EFIAPP") + $(wc -c < "$KERNEL") + 1023 ) / 1024 ))
img_kb=$(( ( (payload_kb + 512 + 31) / 32 ) * 32 ))
[ "$img_kb" -lt 512 ] && img_kb=512
rm -f "$EFI_IMG"
if true; then
# Create the file first and format it with an explicit geometry.
#
# Not `mformat -f`: that takes one of the standard floppy capacities
# (360, 720, 1440, 2880 KB) and rejects anything else -- "Bad size 512".
# Giving heads, sectors-per-track and a total sector count instead lets the
# image be whatever the loader actually needs, which is the point of sizing
# it from the file rather than hardcoding 1.44 MB.
dd if=/dev/zero of="$EFI_IMG" bs=1024 count="$img_kb" status=none
mformat -i "$EFI_IMG" -h 64 -s 32 -T $((img_kb * 2)) ::
mmd -i "$EFI_IMG" ::/EFI ::/EFI/BOOT ::/schos
mcopy -i "$EFI_IMG" "$EFIAPP" ::/EFI/BOOT/BOOTX64.EFI
mcopy -i "$EFI_IMG" "$KERNEL" ::/schos/kernel
fi
# The sysroot, as an ordinary hierarchy. Copied rather than linked so that
# whatever ends up on the disc is a snapshot, not a view of a tree that may be
# rebuilt underneath it.
if [ -d "$SYSROOT" ]; then
for d in "$SYSROOT"/*; do
[ -e "$d" ] || continue
cp -a "$d" "$STAGING/"
done
fi
# xorriso if it is here, mkisofs otherwise. Both accept the El Torito flags
# below unchanged -- xorriso's -as mkisofs mode exists precisely to be
# argument-compatible with it. The fallback is not academic: there is no xorriso
# package for Windows in scoop, where this is developed, but cdrtools provides
# mkisofs.exe.
if command -v xorriso >/dev/null 2>&1; then
MKISOFS="xorriso -as mkisofs"
HYBRID="-isohybrid-gpt-basdat" # mkisofs proper does not know this one
elif command -v mkisofs >/dev/null 2>&1; then
MKISOFS="mkisofs"
HYBRID=""
else
echo "mkiso: need xorriso or mkisofs on PATH" >&2
echo " Windows: scoop install cdrtools" >&2
echo " Debian/Ubuntu: apt install xorriso" >&2
exit 1
fi
# shellcheck disable=SC2086 # EFI_ARGS is a deliberate word list
$MKISOFS \
-quiet \
-V SCHOS \
-A "SchOS" \
-R -J -joliet-long \
-cache-inodes \
-e boot/efiboot.img \
-no-emul-boot \
$HYBRID \
-o "$OUT" \
"$STAGING"
echo "==> $OUT ($(wc -c < "$OUT") bytes)"
echo " UEFI: qemu-system-x86_64 -bios OVMF_CODE.fd -cdrom $OUT"
echo " USB: dd if=$OUT of=/dev/sdX bs=4M"