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 you supply the modules — it ships neither, contains no third-party firmware or binaries, and never modifies its input.
The typical case: an appliance Linux image ships a monolithic kernel with a narrow built-in driver set, and you need a driver for hardware you own that the vendor's build didn't include. Doing it by hand with unsquashfs and mksquashfs silently produces a broken image — ownership is lost and setuid bits are dropped on a non-root round trip. Since v0.2.0 it will also tell you which of your hardware the image can already drive, rather than 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.2, which finds the FAT32 volume by name rather than assuming it is the first slice. Hardware coverage reporting arrived in v0.2.0. The suite is 118 tests on Ubuntu and macOS in CI, 16 of them on the patch path itself, and has been run against several real appliance firmware images and driver sets. An 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 is deliberately three-state: `lspci -nn` without `-mm` carries no subsystem IDs, so a pattern needing 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 — confirm the target twice.