Booster: a host-specific initramfs generator for encrypted Linux
Fast and secure initramfs generator
At a glance
- What is it?
- Booster is a Go initramfs generator that builds an early boot image around the machine it is running on rather than packing a generic early userspace, with a first class focus on LUKS unlock paths including TPM2, FIDO2 keys, Clevis bindings and remote SSH unlock. It also gives you commands to list and unpack an image before you trust it to boot.
- Who is it for?
- Adopt Booster if you run encrypted Linux, particularly on laptops with hardware tokens, and you want an initramfs that contains what your machine needs and nothing else, with an unlock flow you can reason about years later. Do not adopt it if your distribution's own initramfs tooling already covers your layout well, or if you need a rescue image that boots on hardware you cannot enumerate, since the default is host-specific.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 11 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 24, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The image is built around the machine, not around a package list
Booster is described as a fast and secure initramfs generator, and its central idea is in how it decides what goes into the image. Instead of packing a large generic early userspace, Booster discovers what your machine actually needs and builds a focused image around it.
The result is described as a lean boot image with the drivers, unlock tools, filesystem support and recovery paths your host needs, without carrying a kitchen sink into every reboot. The claimed benefits follow from that: a smaller image is easier to audit, faster to generate and faster to execute during boot.
By default Booster builds a host-specific image. It looks at the current system, includes the modules and tools needed to boot it, and leaves out the rest. When you need something broader, the --universal flag includes a wider set of modules for rescue scenarios, portable media or systems where the hardware may change.
That default is the trade the whole design rests on. A host-specific image is smaller and more auditable, but it is also tied to the hardware it was built on, which is exactly why the universal mode exists and why the readme recommends it for portable installs and recovery media.
The project is written in Go, and it is MIT licensed with the repository laid out as a generator directory, an init directory for the early userspace, packaging, contrib, docs and tests.
Unlocking a LUKS root is the feature everything else serves
The readme is explicit that full-disk encryption is a first-class workflow rather than an add-on, and the list of unlock sources is long.
Booster can unlock LUKS devices from kernel parameters, from /etc/crypttab, from GPT autodiscovery, from direct root= references to LUKS containers, from keyfiles, from detached headers and from hardware-backed tokens. The supported styles are plain passphrase unlock with careful prompt handling, shared passphrase caching for related encrypted volumes, keyfiles embedded in the initramfs or stored on a separate device, detached LUKS headers embedded in the image or read from a raw block device or loaded from a separate filesystem, systemd-cryptenroll TPM2 and FIDO2 tokens, Clevis-style bindings for TPM2, Tang and other policies, and SSH-based remote passphrase unlock for machines you cannot physically reach.
The SSH option deserves a mention because it solves a specific operational problem. A rack-mounted or headless machine with an encrypted root has no keyboard to type a passphrase into, so remote unlock during early boot turns a physical access requirement into a network one.
The storage side is equally concrete. Booster supports GPT autodiscoverable root partitions, and roots on LUKS, LVM, mdraid, Btrfs, ZFS, NVMe, USB, MMC and eMMC, including Btrfs subvolumes and multi-device Btrfs setups. It handles hibernation resume devices, device references by UUID=, LABEL=, PARTUUID=, PARTLABEL=, HWPATH=, WWID= or /dev/..., and multiple encrypted mappings coming from the kernel command line or from /etc/crypttab.
The dependency list in the go.mod reflects this: there are separate modules for LUKS handling, Clevis bindings, Tang, device mapper, udev, TPM support and FIDO2, so the crypto integrations are first class rather than shelled out to.
Hardware tokens race in the background, and the wrong key is skipped silently
The token orchestration is where the readme spends the most detail, and the problems it solves are the ones you only discover with a locked laptop in front of you.
Non-interactive tokens can race in the background, PIN-based tokens are prompted in a deterministic order, and the regular passphrase prompt appears as a fallback instead of blocking the whole boot forever. The readme describes the goal as calm, coordinated prompts where successful unlock paths cancel prompts that are no longer needed.
The FIDO2 handling has been improved specifically. Native FIDO2 support is enabled with enable_fido2: true, and a crypttab entry with fido2-device= causes Booster to bundle the FIDO2 plugin automatically, so you do not have to assemble the plugin set by hand for that path. Booster can check whether a connected FIDO2 key actually holds the credential before asking for its PIN, which avoids the situation where a wrong key is plugged in and the machine prompts for a PIN that will never work. Missing token hints are delayed, so a fast TPM2 or Clevis unlock can complete without the noise of a hint for a token that was never needed, and an empty PIN submission skips that token and continues to the next unlock path.
The general principle is that the unlock flow should never present a prompt that has already been answered. That sounds obvious, but it is the difference between a boot that takes two seconds and a boot that sits there waiting for input that will never come.
The readme positions Booster as a good fit for encrypted laptops, developer workstations, servers with remote recovery needs, minimal Linux systems, and boot setups that should still be understandable years after they were configured.
Inspecting the image before you reboot into it
The inspection commands are small, but they change how you approach a change to your boot setup.
Booster includes image-inspection commands so you can verify what was built before rebooting:
booster ls /boot/booster-linux.img
booster cat /boot/booster-linux.img /init
booster unpack /boot/booster-linux.img /tmp/booster-imageThe first lists what is in the image, the second prints a single file from it, in this case the init script that runs first, and the third unpacks the whole thing to a directory so you can read it with ordinary tools. That is a meaningful difference from a conventional initramfs, where the contents are a compressed cpio archive you have to unpack by hand before you can read anything.
The debugging options sit alongside this. Use booster.log=debug,console for detailed boot logs, add busybox for an emergency shell, or enable network support to retrieve logs from a machine that will not boot. The network option is the one that saves a remote machine: if the kernel is up enough to have networking and you can see a log line, you can often diagnose a failed unlock without a console.
Taken together, the inspection commands and the log options address the same problem from two sides. The inspection commands let you check the image before it matters, and the log options let you see what happened when it does.
Installing it, and the one distribution that has to build it
Booster ships as a package for several distributions, and the readme gives a working install for each.
On Arch Linux the official package is installed with pacman -S booster, and the package creates the image in /boot/:
$ ls -lh /boot/booster-*.img
-rwxr-xr-x 1 root root 3.9M Dec 10 20:51 /boot/booster-linux.imgThat listing is a good illustration of the size claim: the example image is 3.9 MB.
On Void Linux it is xbps-install -S booster, followed by xbps-reconfigure -f linux to regenerate the initramfs for an already installed kernel. On Alpine it is apk add booster, after which the readme points to /usr/share/doc/booster/README.alpine for the setup-specific bootloader instructions, which is where the Alpine-specific boot loader wiring lives.
Fedora is the exception and the readme says so plainly: Booster is not in Fedora's repositories, and you build the RPM from a checkout. That path needs the packaging dependencies, the packaging script and then the built package:
dnf install rpm-build golang gcc git-core libfido2-devel rubygem-ronn-ng systemd-rpm-macros
./packaging/fedora/createpkg.sh
dnf install ~/rpmbuild/RPMS/x86_64/booster-*.rpmThe libfido2-devel dependency in that list is a hint about the FIDO2 support, and the ronn gem is there for the man page format. After installing, you select Booster as the generator in /etc/kernel/install.conf so images are rebuilt on kernel updates:
initrd_generator=boosterThat last step is the one that matters for a rolling distribution, because without it a kernel update silently replaces your carefully built initramfs with a generic one, and your FIDO2 or Clevis unlock stops working at the worst possible moment.
You can also build an image by hand, either host-specific or universal:
booster build /boot/booster-linux.imgbooster build --universal /boot/booster-linux.imgAfter creating the image, the readme says to point your boot loader at it, and the full configuration details are in the Booster man page.
What the project does not settle for you
There are boundaries worth being clear about, because an initramfs is the layer where a mistake is least recoverable.
The host-specific default is the main one. An image built on one machine is not a rescue image, and if the hardware changes or the disk layout moves, the image will not save you. The universal mode exists for that reason, and it is larger, which is the point of the trade.
The boot loader step is manual. The readme says to point your boot loader at the image after creating it, and for Alpine there is a separate README with the setup-specific bootloader instructions. That means the integration with your boot loader is not abstracted away, and a distribution whose boot loader configuration is unusual will need more work.
The feature list is also about unlocking rather than about everything an initramfs can do. It covers LUKS, the listed filesystems, the token types and the device reference formats, and it does not claim to cover every possible early boot scenario such as complex software RAID recovery or every exotic filesystem.
Finally, the project state. The releases are 0.13 from 2026-06-14, 0.12 from 2024-12-02 and 0.11 from 2023-07-17, so the version numbers are still below one, while the last push was on 2026-10-13. Work is clearly current, but there is no 1.0 marker, which for a boot component means you should treat upgrades with the same care you would give a kernel change.
Editorial conclusion
Adopt Booster if you run encrypted Linux, particularly on laptops with hardware tokens, and you want an initramfs that contains what your machine needs and nothing else, with an unlock flow you can reason about years later. Do not adopt it if your distribution's own initramfs tooling already covers your layout well, or if you need a rescue image that boots on hardware you cannot enumerate, since the default is host-specific. Before you commit, build the image, inspect it with booster ls and booster unpack, and confirm your boot loader points at the new image while keeping the old one reachable.
Frequently asked questions
What problem does Booster solve?
Booster builds a compact initramfs that moves a Linux system from firmware to the real root filesystem, containing the drivers, unlock tools, filesystem support and recovery paths the host needs rather than a large generic early userspace. The result is a smaller image that is easier to audit and faster to boot.
How do I install Booster on Arch, Void and Alpine?
Use pacman -S booster on Arch Linux, xbps-install -S booster on Void Linux followed by xbps-reconfigure -f linux, and apk add booster on Alpine Linux. Booster is not in the Fedora repositories, so there you build the RPM from a checkout and select Booster in /etc/kernel/install.conf.
What encryption unlock methods does Booster support?
Plain passphrases, shared passphrase caching for related volumes, keyfiles embedded or on a separate device, detached LUKS headers, systemd-cryptenroll TPM2 and FIDO2 tokens, Clevis-style bindings for TPM2, Tang and other policies, and SSH-based remote passphrase unlock for machines you cannot physically reach.
How do I check the contents of a Booster image before booting it?
Booster has built-in inspection commands: booster ls lists the image contents, booster cat prints a single file such as /init, and booster unpack extracts the image to a directory. For boot failures there is booster.log=debug,console, a busybox emergency shell, and network support for retrieving logs from an unbootable machine.
Does Booster support FIDO2 security keys?
Yes. Native FIDO2 support is enabled with enable_fido2: true, and a crypttab entry with fido2-device= causes Booster to bundle the FIDO2 plugin automatically. Booster can also check whether a connected key holds the credential before prompting for its PIN, and an empty PIN submission skips to the next unlock path.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/anatol-booster)Was this useful?