Running FHS software

Most Linux software assumes the classic layout: scripts start with #!/usr/bin/env, programs open /etc/passwd or /usr/share/..., and binaries built elsewhere ask for /lib64/ld-linux-x86-64.so.2. Zainium OS keeps them working in two ways.

Packages are adapted when installed

zex rewrites packages from Void, Alpine and Chimera to Zainium paths: the program loader, the library path (RPATH), pkg-config prefixes and script interpreters.

Paths are resolved when used

This is the job of sys_resolver; the short version:

libsys_resolver.so is preloaded into systemd services, login shells and PAM sessions. When a program opens, runs or inspects an FHS path that does not exist, the resolver maps it:

1. a leading /usr/local/ or /usr/ is removed;
2. lib64 becomes lib;
3. lib/modules becomes drivers/modules, lib/firmware becomes drivers/hardware/firmwares, boot becomes kernel;
4. the result is tried under /overlayer/syshub, the musl directory, /overlayer/zexlib/union and /overlayer/zaisys, in that order.

For example /usr/bin/env becomes /overlayer/syshub/bin/env and /etc/passwd becomes /overlayer/syshub/etc/passwd. /home and /tmp are never touched.

Missing loaders

A program whose loader path does not exist — /lib64/ld-linux-x86-64.so.2 or /lib/ld-musl-x86_64.so.1 — is started with this system's loader of the same C library.

Limits

A preloaded library cannot act in statically linked or setuid programs, because the loader does not preload into those. Such programs need real Zainium paths.