NixOS Support Status

[shadowrylander]

Hello!

I was just wondering as to the status of hijacking NixOS; I'm considering trying it out, but I really want to use Bedrock as well! Has any progress been made in the betas, perhaps?

Thank you kindly for the information! 😸

[paradigm]

See documentation here: https://bedrocklinux.org/0.7/distro-compatibility.html

[shadowrylander]

Is the situation the same for hijacking it as well? It seems that only mentions the state of fetching.

[paradigm]

At the time of writing,

• NixOS's Community Usage column is Very Low, which means very few people have tried and reported anything about NixOS + Bedrock. There simply aren't a lot of known details to express.

• NixOS's Known Issues column indicates many and directs to:

One effort to add brl fetch support involved bootstrapping via the stand-alone Nix package manager, which itself was installed via https://nixos.org/nix/install. However, Nix apparently disliked running in the limited brl fetch environment. This might be related to Nix sandboxing efforts. More investigation is needed.

Which is about issues with fetching and

Nix requires a runtime daemon. Proper support for NixOS might require brl enable support for pre/post enable hooks to launch the daemon when the stratum is enabled.

It is unclear if NixOS design assumptions will result in it becoming upset at non-local components, such as /etc files, changing out from under it.

which is about general NixOS and Bedrock concerns.

• NixOS's Fetch Support column indicates No, which follows from the Known Issues content.

• NixOS's Maintainer column indicates None. No one has displayed the capability, time, and intent to working on making NixOS work with Bedrock. While a drive-by submission is in theory possible, these are rare.

[shadowrylander]

Hmm... I'm way too new to manipulating these things to be of any help, but I think I can at least report back as to the current state of hijacking a fresh install.

[paradigm]

If there's no one working on fixing the issues, a longer unmaintained list of specifics that are broken isn't useful.

[shadowrylander]

That's fair! Either way, I'll try it out and see what happens. Who knows? 😸

[paradigm]

Good luck

[shadowrylander]

Thanks! I'll need it.

[ghost]

I tried it in a VM and the hijack process couldn't even find the init system, with:

ERROR: No file detected at /sbin/init. Unable to hijack init system.

Because (to my knowledge) NixOS stores all packages in a different /nix/store/ directory to sandbox them from each other, Bedrock would have to manually find the NixOS init system which sounds like a pain. You could* hardcode the directory and update it on every systemd update, as the directory name is a hash of the packages dependencies, but that sounds annoying and bodgy.

So ironically, despite the more sensical reason (in my opinion) being the fact that Nix requires a daemon, the sandboxing actually makes it hard. Also, this layout could cause problems with Bedrock/non-NixOS shells trying to find programs, as they aren't always in the same directory.

[paradigm]

I tried it in a VM and the hijack process couldn't even find the init system, with:

ERROR: No file detected at /sbin/init. Unable to hijack init system.

Because (to my knowledge) NixOS stores all packages in a different /nix/store/* directory to sandbox them from each other, Bedrock would have to manually find the NixOS init system which sounds like a pain. You could hardcode the directory and update it on every systemd update, as the directory name is a hash of the packages dependencies, but that sounds annoying and bodgy.

How does the bootloader find NixOS's init?

[ghost]

The config for the bootloader is updated by Nix automatically every time the kernel, initrd, or init is updated. So maybe you could somehow make a nix package that gives bedrock the right path to init every time, since Nix already knows, but now we're talking about external dependencies. You could also piggyback off of the bootloader's config, but that seems messy considering NixOS's support for different bootloaders. Maybe (and that's a big maybe!) you could change the init package in the official repo to put the init path somewhere in the boot filesystem at a consistent place?