<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/source/rss.xsl.xml"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
    <title>Changes in boot-test.sh</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>a7ebe2d436e5d2fabf223796f992683c17acf50f - boot-test.sh: Test many boot loader combinations.</title>
        <link>http://kernelsources.org:8080/source/history/freebsd/tools/boot/boot-test.sh#a7ebe2d436e5d2fabf223796f992683c17acf50f</link>
        <description>boot-test.sh: Test many boot loader combinations.This is a script that eventually will test boot with qemu all thesupproted combinations for the boot loader. There&apos;s several things thatcould be done with gptboot or boot0sio (or not) that aren&apos;t tested. Wedon&apos;t test the 10-odd hardware root devices we support, nor do we testcomplex scenarios like RELAXED vs STRICT zfs efi booting.However, the scenarios we do support are included here. We test aarch64,amd64, armv7, powerpc64, powerpc64le, and riscv64 for BIOS, UEFI, andPrep and OpenFirmware (as appropriate) crossed with CDROM, MBR and GPT(and some hybrid) crossed with lua, 4th and simple loaders. Plus somelinuxboot and memdisk scenarios, including the recently addedcompression for ram disk scenarios:=== Results: 67 passed, 3 failed, 9 timed out (of 79) ===The timeouts are well understood, usually failure to find the rootdisk. The failures are bad console assumptions. netboot-bios failsbecause TFTP with a single packet buffer in qemu gives horriblethroughput, so the test takes 18-20 minutes. Now that I have adashboard, I can fix the rest one by one.There&apos;s also a powerpc architecture that you can request specifically,but it&apos;s just for convenience and tests with the non-functional mac99qemu machine. I will eventually eliminate this architecture. I added itto make sure the FreeBSD version wasn&apos;t too hard coded since thisframework pulls from CD images to get the binaries for the minimal rootused in testing and there&apos;s no 15.x 32-bit powerpc images.We need to add http and nfs root booting tests, but that&apos;s for thefuture. Plus there&apos;s some other functional tests that we should also addfor different types of root (usb, sata, sas, nvme, ufs, emmc, sd, etc)that would be useful to test, especailly the non-sata/non-nvme ones.How we do that is still TBD.I leaned on claude to iterate over the recipes that I&apos;ve developed overthe years, collected off the internet or got on IRC recently to producethis framework. Most of this code is fairly good, while a few parts,especailly some of the comments, are detectable as AI produced. My plansare to iteratively improve those.  Since this is just a test, and sinceI&apos;ve broken many scenarios w/o realizing, it&apos;s a good tradeoff. I&apos;ve notmade it an ATF test since we test all the architectures, but I&apos;m open tofeedback in this area.Total time to test all the architectures is about 10 minutes. It assumesyou&apos;ve built GENERIC* and the boot loader for all the architectures too.In the future, I plan on moving to MINIMAL for all the boot testing, butlikely only after PCI devmatch is integrated into it. That would beincrementally faster test times.The man page is decent, but was also generated by Claude with onlytrivial edits by me to date.... But at least there&apos;s a man page for it,though neither it nor the script is installed onto the system.Sponsored by: NetflixAssisted-by: Claude Code (Opus 4.6, Opus 4.8(1M) and Sonet 5.0)Differential Revision:	https://reviews.freebsd.org/D58008

            List of files:
            /freebsd/tools/boot/boot-test.sh</description>
        <pubDate>Sat, 11 Jul 2026 21:36:51 +0200</pubDate>
        <dc:creator>Warner Losh &lt;imp@FreeBSD.org&gt;</dc:creator>
    </item>
</channel>
</rss>
