System Graft
The drivers the installer forgot, grafted into an initrd
What it does
Injects out-of-tree kernel modules into a SquashFS initrd, adds a load hook to the image's init scripts, and writes the result to bootable removable media. You supply the image and the modules. It ships neither, contains no third-party firmware or binaries, and never modifies its input.
The usual case is an appliance Linux image with a monolithic kernel and a narrow set of built-in drivers, when you need a driver for hardware you own that the vendor's build left out. Doing it by hand with unsquashfs and mksquashfs gives you a broken image without a word of warning: ownership is lost and setuid bits are dropped on a non-root round trip. Since v0.2.0 it'll also tell you which of your hardware the image can already drive, instead of leaving you to find out after the reboot.
- Hardware coverage reports: give it `lspci -nn`, `lsusb` or bare vendor:device pairs and it says, per device, whether the image can drive it
- Recognises hardware served by a compiled-in driver instead of reporting it as missing
- Faithful repack: ownership, setuid and setgid bits and the full permission table preserved
- Wires the module into the image's init sequence, and reports whether each .ko is signed and what firmware it needs
- A verification pass reporting the preserved bits, the injected module's presence and a sha256 of the result
- Bootable UEFI USB writer. GUI and CLI, always writing a new file rather than touching the input
Where it stands
Released at v0.2.3, which credits a built-in driver the alias database names, lets the Linux USB writer see an attached disk image, reads ownership numerically so a uid that comes out as a name with a space in it no longer drops an entry, builds macOS universal, and reports its own version properly again (0.2.1 and 0.2.2 shipped saying 0.2.0). v0.2.2 finds the FAT32 volume by name instead of assuming it's the first slice, and hardware coverage reporting arrived in v0.2.0. The suite is 120 tests on Ubuntu and macOS in CI, 17 of them on the patch path itself, and it's been run against several real appliance firmware images and driver sets. One image it produced, a Waves SGS 16.5 initrd with three injected drivers, has been booted in a KVM virtual machine, where the injected drivers loaded and drove the emulated NICs. No image has been booted on real hardware. Hardware coverage has three states on purpose: `lspci -nn` without `-mm` carries no subsystem IDs, so a pattern that needs one is reported UNCERTAIN rather than as a miss. The USB writer, on macOS and on Linux, has only ever been run against an attached disk image, never a physical stick. It repartitions and erases block devices, so confirm the target twice.