FHS folders in /

Today I stumbled upon usr lib and lib64 folders in my /. Having quite large and messy configuration.nix and beeing courious, I decided to see what could be causing this. After unsoucsessfull google search and hour of disabling modules and rebuilding I ended up with the following configuration

{ config, lib, pkgs, ... }:

{
        imports = [
                # Include the results of the hardware scan.
                ./hardware-configuration.nix
        ];
        boot = {
                loader = {
                        grub = {
                                enable = true;
                                devices = [ "nodev" ];
                                efiSupport = true;
                        };
                        efi = {
                                canTouchEfiVariables = true;
                        };
                };
        };

        services = {
        # X.org
                xserver = {
                        enable = true;
                        dpi = 170;
                        windowManager = {
                                i3 = {
                                        enable = true;
                                };
                        };
                };
        };

        networking = {
                networkmanager = {
                        enable = true;
                };
        hostName = "X1_Yoga";
        };

        time = { 
                timeZone = "Europe/Prague";
        };
        system.stateVersion = "24.05"; # Did you read the comment?

}

yet the folders presist.

I have a suspicion this is somehow my stupidity and lack of ability to read the documentation, if so, please feel free to redirect me to the corresponding doc page. In the rare situation this is not the case, how the hell is that possible ?

What’s in those folders?

usr contains link to bin, lib and lib64 both contain dynamic linker

The lib ones are from this: nixos/stub-ld: init module by tejing1 · Pull Request #269551 · NixOS/nixpkgs · GitHub

The /usr one is there exclusively to let us have /usr/bin/env as a common way to allow shebangs to work, e.g. #!/usr/bin/env bash at the top of a script.

/bin/sh is there because that’s how the system() function in libc works.

6 Likes

Should probably learn to google better, but thanks

Ah that explains it, I have none of those enabled on my system, so none of those dirs exist.

Those can be disabled? How? Have you experienced any breakage from this?

Do you found any answers to your questions? Just curious about it too

I’ve found environment.ldso, which is itself null by default, but is set by environment.stub-ld.enable in nixos/modules/config/stub-ld.nix:

All of /bin/sh setup is done in nixos/modules/config/shells-environment.nix. Notably, there is a hidden option (environment.binsh) to set what program is symlinked to /bin/sh:

The actual symlink is created by system.activationScripts.binsh, defined in the same file:

Actually changing /bin/sh is strongly advised against. It would break libc’s system() call, and all of Nixpkgs is written under the assumption that any shell is implicitly bash.
I suppose, in theory, it might be possible to patch both libc and Nix to eliminate /bin/sh, but I don’t believe that would ever be practical.

/usr/bin/env is created by environment.usrbinenv, another hidden option defined in nixos/modules/system/activation/activation-script.nix:

Again, it is normally assumed that /usr/bin/env exists on NixOS, so there will likely be issues if disabled; however, system.activationScripts.usrbinenv does accept null as a special value, and will clean up the extra directories in that case (if nothing else is using them).

It seems some modules may create symlinks in FHS directories as well; see the description of services.x2goserver.enable.


So, as for my original questions, those directories can be disabled. However, disabling any of them except for stub-ld is very likely to cause breakage.

1 Like