Visor Boot Manager: a 340 KB graphical UEFI menu with zero-config detection
A minimal, fast, graphical UEFI boot manager written in C. no external dependencies — just a config file :)
At a glance
- What is it?
- Visor is a single-binary UEFI boot manager written in C that draws an animated icon menu, auto-detects Windows, UKIs and BLS entries, and ships a boot.conf you can delete entirely. Here is how it installs, what it does not do, and who should stay on GRUB.
- Who is it for?
- Adopt Visor if you run UEFI-only x86_64 or AArch64 hardware and want a graphical menu that auto-detects kernels without hand-written entries; the README states it boots EFI-stub kernels, UKIs and chainloads other EFI executables. Do not adopt it if you still need legacy BIOS, multiboot, or a shell-like scripting layer, since Visor has none of those by design.
- Can I use it commercially?
- Yes. BSD-2-Clause 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 3 days ago.
- What is it written in?
- Mainly C, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 17, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What Visor solves for people tired of text menus
Most UEFI boot managers force a choice. GRUB gives you a text menu and a generated grub.cfg you are told not to hand-edit. systemd-boot gives you a small binary and one BLS entry file per kernel you must write yourself. rEFInd gives you icons but a static menu. Visor's pitch is that the menu can look current without giving up the small footprint: the README describes a single ~340 KB .efi with no external dependencies and no scripting language, configured by one plain-text file.
The audience is narrow and specific. You need x86_64 or AArch64 UEFI hardware, and you need to boot Linux through an EFI-stub kernel or a Unified Kernel Image, or chainload some other EFI executable. If your machine is old enough to need legacy BIOS, Visor is not in the running at all: the comparison table lists Legacy BIOS as "No - UEFI only". The project is also young. The README's own table puts Visor's maturity at "Young (2026), one maintainer", which is an honest thing to print next to GRUB's 25+ years.
The part that separates Visor from a pretty rEFInd clone is what happens when you supply nothing. The README states that if you drop the config entirely, Visor auto-detects Windows, UKIs, kernels and BLS/OSTree deployments, and derives a correct root= cmdline by itself. The comparison table names the inputs for that cmdline: the UKI section, fstab, and the GPT partition type. That is the real feature. A boot menu that finds your kernel is worth more than one that animates.
How the boot menu is built: one binary, gnu-efi, two architectures
Visor is freestanding C compiled against gnu-efi. The repository's Makefile shows the shape of it. There is no libc and no runtime: the flags include -ffreestanding, -fno-stack-protector, -fno-PIE and -fshort-wchar, and the include path is -I $(SRC_DIR)/include. The output is not a normal executable but a PE image, produced with objcopy -O pei-x86-64 --subsystem=10 for x86_64 and -O pei-aarch64-little --subsystem=10 for AArch64.
One tree builds both architectures, which the README calls out as a feature. The Makefile branches on ARCH. For x86_64 it wants x86_64-linux-gnu-gcc or gcc, adds -mno-red-zone and -DGNU_EFI_USE_MS_ABI, and uses src/visor_x86_64.lds as the linker script. For aarch64 it wants aarch64-linux-gnu-gcc, adds -mstrict-align, and uses the gnu-efi linker script elf_aarch64_efi.lds. Anything else hits an explicit error: unsupported ARCH=$(ARCH); use x86_64 or aarch64.
The version string is baked in at compile time, and the Makefile gets it from an unusual place. It runs sed -n 's/^pkgver=//p' PKGBUILD, falling back to 1.4 if that fails, then passes it as -DVISOR_VERSION='L"$(VISOR_VERSION)"'. So the AUR packaging file is the source of truth for the version that appears in the binary. If you build from a tarball without PKGBUILD, you get the fallback unless you set VISOR_VERSION yourself.
The config file is the only interface. The README is blunt that there is no scripting language, and the comparison table repeats it: "None, on purpose". That means no conditional entries, no generated entries at boot time, no hooks. Whatever logic you want has to be resolved before the config is written. A fully commented reference ships as boot.conf.example in the repository root, and a schema file, boot.conf.schema.json, is referenced as the basis for the companion Studio editor.
Installing Visor boot manager and booting it the first time
The README gives a one-line installer. It installs the build tools for your distribution, downloads Visor, builds it, and installs it to your ESP, building as your normal user and asking for sudo only at the install step. The README also notes you can download get.sh and read it before running.
sh -c "$(curl -fsSL https://raw.githubusercontent.com/IO-ZetZor/Visor-BootManager/main/get.sh)"With wget instead of curl, the README gives this form:
sh -c "$(wget -qO- https://raw.githubusercontent.com/IO-ZetZor/Visor-BootManager/main/get.sh)"After it finishes, the config lives at <ESP>/EFI/visor/boot.conf. The README says to edit it to point at your real kernels, or delete it and let auto-detection do the work. Deleting it is the more interesting path: on a machine with a UKI or a BLS layout, Visor is supposed to build the entries itself, including the root= argument.
On Arch, the AUR package is the alternative route. The README gives yay as the example, and paru as another:
yay -S visorThat package builds from source, puts the EFI binary in /usr/lib/visor/ and the visor CLI in /usr/bin/visor. It does not deploy anything on its own. You run visor install afterwards to write to the ESP:
visor installUpdates go through the same CLI. The README states that visor update pulls and reinstalls the latest version at any time. The latest release listed is v1.5.6, described as "Modularity and small fixes" and dated 2026-09-14. The README points to the project site for the full install guide, installer flags and the configuration reference, and notes that the companion Studio editor can be run locally with visor studio.
Where Visor is the wrong tool
The README's own comparison table is the most useful page in the project, because it lists the losses plainly. Legacy BIOS support is absent. Multiboot 1 and 2 are absent, which rules out hobby operating systems that rely on them; Limine is named as the loader for that case. There is no scripting, so anything that needs conditional logic at boot has to be solved elsewhere.
The maturity line matters more than it looks. "Young (2026), one maintainer" against GRUB's 25+ years is a statement about bus factor, not about code quality. A boot manager sits in the path between firmware and your data. If it fails, you are reaching for a USB stick. The README does not document a rollback procedure, and it does not describe what happens if the installed binary is present but unbootable. That is the gap I would want closed before putting Visor on a machine I cannot physically reach.
Some of the listed features are also load-bearing in ways the README does not fully explain. "Windows immunity" claims self-healing of a missing or reordered boot entry, an overwritten BOOTx64.EFI fallback, and a damaged GPT partition table. Those are strong claims about writing to firmware variables and repairing partition tables, and the README does not describe the mechanism or the failure modes. Encrypted boot artifacts use something the README calls VISORENC plus a "one-password LUKS handoff", which is a design worth reading the wiki for before trusting it with a /boot partition. Secure Boot is described as shim/SHIM_LOCK aware with sbctl signing in the installer, which is a narrower story than GRUB's mature shim integration or systemd-boot's, and the README does not claim otherwise.
The filesystem situation deserves a note too. Visor can install filesystem drivers for non-FAT volumes, credited to EfiFs by Pete Batard. That is an add-on you opt into, not something in the 340 KB binary, and the README does not say how large the drivers are or which filesystems they cover.
Visor against rEFInd, systemd-boot and GRUB
rEFInd is the closest comparison and the README credits it as "the massive inspiration for what a boot menu should feel like". The difference is in the menu: rEFInd draws graphical icons but the menu is static, while Visor adds animations, blur, wallpaper accent colors, themes, mouse and touch. rEFInd also auto-detects kernels, but only partially derives cmdlines where Visor claims a full derivation from UKI section, fstab and GPT type. rEFInd's footprint is listed at ~500 KB plus icons and themes; Visor's at ~340 KB in one binary. rEFInd has 15+ years behind it and Visor does not.
systemd-boot is the opposite trade. It is roughly 100 KB and deliberately text-only, with one BLS entry file per kernel. If you already generate BLS entries from your image tooling, systemd-boot needs nothing from you and Visor's auto-detection is redundant. If you do not, Visor writes those entries for you. systemd-boot also has no btrfs snapshot boot and no live USB hotplug, both of which Visor lists as built in.
GRUB is the honest fallback and the README says so directly: "if you want a bulletproof do-everything loader, use GRUB". GRUB covers legacy BIOS, multiboot, and a shell-like configuration language, and it reads LUKS-encrypted /boot. Visor matches the encrypted-boot-files point with its own VISORENC scheme rather than by reading LUKS /boot. Where Visor diverges is the config model: GRUB's grub.cfg is generated and hand-editing is discouraged, while Visor's boot.conf is meant to be edited, or deleted.
The features with no counterpart in the table are snapshot booting through snapper, Timeshift or plain btrfs, OSTree deployment browsing with automatic rollback, and animated USB hotplug in the menu. Those are the reasons to pick Visor over systemd-boot on a machine that already uses those layouts. None of them are documented in the README beyond the table row.
Licence, releases and what maintenance costs you
Visor is BSD-2-Clause, and so is the companion Studio project. That is a permissive licence: you can ship a modified binary in a product without publishing your changes, provided you keep the copyright notice and the disclaimer. Nothing in the README suggests any additional restriction, and there is no contributor licence agreement mentioned. This is not legal advice; if you are redistributing Visor inside a commercial image, read the LICENSE file in the repository root rather than a summary.
Maintenance looks inexpensive by design. There is no dependency tree to track, because there are no dependencies beyond gnu-efi at build time. The version comes from PKGBUILD, so the AUR package and the built binary stay in step. The visor update command handles pulling and reinstalling. The risk is not dependency churn, it is that the project's bus factor is one and the README says so. If the maintainer stops, you are left with a working binary and a C codebase that builds with gnu-efi, which is a recoverable position for anyone comfortable with freestanding C and a linker script. It is a much worse position if you are not.
Release cadence is visible in the recent tags: v1.5.4 on 2026-09-03, v1.5.5 on 2026-09-08, v1.5.6 on 2026-09-14. The last push to the repository was on 2026-09-15. The pattern is small, frequent releases rather than long-stable branches, which suits a boot menu where each change is testable by rebooting. The upgrade cost for you is a reboot per version, and the README does not describe a way to keep two versions installed side by side for fallback.
Editorial conclusion
Adopt Visor if you run UEFI-only x86_64 or AArch64 hardware and want a graphical menu that auto-detects kernels without hand-written entries; the README states it boots EFI-stub kernels, UKIs and chainloads other EFI executables. Do not adopt it if you still need legacy BIOS, multiboot, or a shell-like scripting layer, since Visor has none of those by design. Verify first on your own machine that auto-detection derives the right root= cmdline for your layout, because the README does not document a rollback path if the installed binary fails to boot.
Frequently asked questions
How do I install Visor boot manager?
The README gives a one-line installer that fetches get.sh, builds Visor and installs it to your ESP, asking for sudo only at the install step. On Arch you can instead install the AUR package with yay -S visor and then run visor install to deploy it.
How do I access the boot manager?
The README does not document how to enter Visor from firmware, so the answer depends on your machine's own boot-menu key or the firmware boot order. Once Visor is installed to the ESP and selected as a boot option, it draws the menu itself at power-on.
Can I use Windows Boot Manager as a boot option in Visor?
Yes. The README states that Visor chainloads any other EFI executable, including Windows, and that its auto-detection finds Windows when no config file is present. The comparison table also lists self-healing of a missing or reordered Windows boot entry.
Is Windows Boot Manager necessary if I use Visor?
Visor chainloads the Windows EFI executable rather than replacing it, so the Windows boot files still need to exist on the ESP for Windows to start. The README does not describe removing Windows Boot Manager, only detecting and chainloading it.
What happens if I turn off Windows Boot Manager?
The README does not document turning Windows Boot Manager off, so this cannot be answered from the project's own material. The related claim it does make is that Visor self-heals a missing or reordered boot entry and an overwritten BOOTx64.EFI fallback.
Community notes