agunix frequently questioned answers

What is agunix?

A self-hosting POSIX* userspace. Not necessarily a Linux distro, at least once someone bothers to port it to more kernels. The primary goal of agunix is to minimize bloat.

* mostly

Init system? libc? Package manager?

runit. musl. pacman.

So you're an Arch Linux fork?


Why avoid GNU?

We have some GNU stuff, but we avoid it where possible. GNU packages in agunix are considered bugs and will be replaced as soon as a suitable replacement can be found (even if we have to write it ourselves). We avoid GNU tools because they are often bloated and overengineered. GNU offers many non-standard extensions that encourage non-portable behavior, and their software design and codebases are a shitshow, for lack of a better term.

Why use musl over glibc?

glibc suffers from all of the same ails all GNU software shares (notably a huge selection of non-portable APIs and massive amounts of bloat), but most importantly is not friendly to static linking.

For a comparison of GNU software to some of its alternatives, click here.

Why avoid systemd?

Again this boils down to bloat and software design. As far as init systems are concerned, systemd isn't awful, but it's also overengineered and bloated. They also have a massive problem with scope creep. We use runit, which is much more focused and simple.

Why don't you ship a default kernel?

The kernel on an agunix system should be finely tuned to the needs of your system. If we built a kernel that suited all use-cases it would be huge and include massive amounts of code that is unrelated to your system.

Is agunix lightweight?

We ship lighter alternatives to a lot of mainstream software. Our system design is lightweight as well: at boot, there are typically only 3 processes running — runit, a getty, and your shell. Static linking also allows us to avoid shipping a bunch of shared libraries, and we package development headers and static libraries separately from runtime packages. We also clean out a lot of garbage upstreams often ship, such as documentation in any format other than man pages.

Is agunix secure?

Currently agunix makes no promises of security. We have plans for security but they haven't been realized yet. If you want a distro that definitely won't eat your children, look elsewhere. If you're okay with a distro that might not eat your children, try agunix and maybe help us make it more secure.

Is agunix for me?

If you don't know what you're doing, definitely not. If you think you know what you're doing, probably not. If you actually know what you're doing, you should be able to tell for yourself.


What's this about static linking?

Most of our packages use static linking.

Aren't statically linked binaries bigger?

Generally not when you consider their size combined with the shared libs you have to carry around anyway. Regardless, our use of lightweight alternatives to mainstream software makes agunix much smaller than most other distros anyway.

Is dynamic linking supported?

You can use dynamic linking in your own programs and some agunix packages do, too. On the whole, though, we avoid it like the plague when making packages. We will patch upstream software to support static linking or throw it out in favor of alternatives that are probably lighter anyway.

Aren't upgrades awful?

Nope. Security updates might be, but we're working on software that can evaluate the impact of security vulnerabilities and only update affected packages. We will also add support for delta upgrades if it becomes necessary.

Non-security updates to libraries don't trigger recompiling dependent packages. Such packages are upgraded on a per-request basis - ping us if you feel like rebuilding a package would be a good thing. If a piece of software doesn't depend on new features in a library and isn't affected by fixed bugs, then there's little reason to recompile.

What's so great about static linking, then?

Speed, stability, and simplicity. A program that was compiled once for agunix will continue to work forever, even if you upgrade the libraries it depends on. Hell, you can remove those libraries after you finish compiling it (surprise: /usr/lib is empty on a fresh agunix install). Our packages are also portable across distros because of this - you could untar an agunix package over / on any Linux distro and it will work. This is actually how we install agunix alongside other distros in the first place.

So is PAM supported then?

No. And neither is your use case that requires it.


How do I obtain agunix?

Downloads are not yet available. The following procedures are manual, likely to break along the way, and require a background in Unix and Linux to deal with the inevitable problems. Good luck!

Standalone installation

Since we use the same package manager as Arch Linux, bootstrapping it from the Arch Linux install media is possible. Boot into the Arch install media on your machine.

Partition and mount disks

Do this normally. GDT is preferred, so use gdisk. If you want any weird setups like LUKS or LVM, set them up now. Mount the disks at /mnt or wherever you want, I'm not a cop.

Trust the agunix keyring

pacman-key -r 89AC5EADEE64961BD2832A6B77CCF3F7D515E678
pacman-key --lsign-key 89AC5EADEE64961BD2832A6B77CCF3F7D515E678

Set up the package repositories

Grab our pacman.conf and mirrorlists and replace the ones in the install media with them.

Install the base system

pacstrap -MG /mnt base, plus any additional packages you'd like to install.

chroot into the new system

arch-chroot /mnt


Write your hostname to /etc/hostname. Set the root password with passwd. Enable any services you want.

Prepare an initramdisk (optional)

If you have a funky disk setup, you may want to prepare an initramfs to support configuring it at boot. Install tinyinitrd and read initrd-update(8).

Obtain firmware (optional)

If you need any firmware to use your hardware, you should identify it now and stash the relevant files away somewhere (grab them from /usr/lib/firmware on the install media). You can put them in /usr/lib/firmware in your new system, but it's recommended that you bake them into your kernel instead.

Compile your kernel

Obtain the Linux kernel sources and grab our default .config. Use make menuconfig to enable drivers, filesystems, or other kernel options you require.

Modular kernels are not presently supported, and our default config disables them. You will have to edit your kernel configuration for a bit to enable everything you need - the default .config has very little enabled.

Run make to compile the kernel. Drop the image in /boot or wherever you want, I'm not a cop.

Install a bootloader

Leave the chroot and install your favorite bootloader. SYSLINUX is suggested. Unmount your disks and reboot, and hopefully all your hard work paid off.

Installing in a chroot

  1. Get pacman and pacstrap working on your host system. On Arch Linux you can just install arch-install-scripts.
  2. pacman-key -r 89AC5EADEE64961BD2832A6B77CCF3F7D515E678
  3. pacman-key --lsign-key 89AC5EADEE64961BD2832A6B77CCF3F7D515E678
  4. Grab our pacman.conf and mirrorlists and edit the pacman.conf to use the mirrorlist file. You do not need to replace the host system's pacman.conf/mirrorlist with these, just stash them nearby.
  5. mkdir agunix
  6. pacstrap -dMGC agunix/ base, plus any additional packages you'd like to install.
  7. chroot into the new system with arch-chroot, or manually mount /dev, /proc, etc in the new system and use chroot

Installing alongside another Linux distro

  1. Download pacman, pacman-mirrorlist, and curl from You can use your distro's existing curl if you want. Use ag-pacman instead of pacman if the distro you're installing with uses pacman itself - it's the same as pacman but can co-exist with another pacman install.
  2. untar these packages over / (or some other prefix)
  3. pacman-key --init
  4. pacman-key --populate agunix
  5. pacman -Syu pacman pacman-mirrorlist curl --force to overwrite the manually installed packages with ones managed by pacman.

You can use pacman normally at this point to install agunix packages (or ag-pacman if necessary). Make careful use of --nodeps and --assume-installed as necessary to fulfill dependencies provided by the host distro.


In general, read the man pages to learn how to use things.

User management

We use BSD's doas tool instead of sudo. Read doas(1) for help using it. By default, the admin group is allowed to use doas.

Network configuration

You can install and enable dhcpcd with pacman -Syu dhcpcd and sv enable dhcpcd. This will start it up on boot. To start it immediately, use sv start dhcpcd.

To configure a static IP or other networking setups, write a script that uses ip(8) to configure your network interfaces. Write this script to /etc/sv/networking/run and use sv enable networking and sv start networking to use it.

Package management

Use pacman -Syu [packages...] to update the system and install new packages. Use pacman -R [packages...] to remove them. Read pacman(8) for additional usage. If you have issues with package signatures, you may have to run pacman-key --init and pacman-key --populate agunix.

Compiling packages

Our packages are available at pacman -Syu --needed base-dev will install sufficient development tools to compile any agunix PKGBUILD with the makepkg command.

Running services

Services are managed with sv(1). Use sv enable [services...] to start services up on boot and sv run [services...] to start them immediately. Logs are generally written to /var/log/[service-name].