Open unrooted opened 3 years ago
I'd like to add onto this issue - I found this piece about the non-compatibility of NixOS on the bedrocklinux website, and I'll try to respond to them with the best of my ability.
### NixOS
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.
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.
(1) Too bad for Nix. I am not versed in what limitations the brl fetch environment provides and cannot specifically provide an answer for this.
(2) This is true. Note that the daemon can be invoked by the nix-daemon
command.
(3) NixOS won't care, but will overwrite them next time you rebuild.
We can think of it like this: your configuration.nix files are generators for other files out there. For example, here's a line from my config:
networking.hostName = "NotYourPC";
This will in turn write to the appriopriate files in /etc
.
Now, we can change the hostname to "NotYourSuperCoolLaptop" by manually editing these files, or invoking the hostname
command to do so for us. Just like any other system, this would work and our hostname would be changed. Actually, we could probably live like this forever - but alas, the next time you rebuild Nix will realize this file is changed and overwrite it.
Of course, the whole point of NixOS is to give you configuration abilities, and it is possible to change these files, if we write these changes in our NixOS configuration ourselves. We may just have to write a configuration that contains changes that Bedrock Linux needs as a module and add it to the system - best-case scenario we get it on the nixpkgs itself.
Interested to see what solutions turn up in this thread.
I've been researching this topic for a while in my spare time recently.
I've been able to install nix-generate-config
and nixos-install
on non-NixOS distro (Artix on the picture).
It seems like I've been able to install it to proper directory...?
I've also managed to kinda enable this, but kinda is a good word and I don't know what happened. Maybe this is because I've limited NixOS config, to use initScript
and isContainer
options. Both of them were able to be installed to proper directory and both of these were 'stuck' there. I had problems with using other options of NixOS when it comes to bootloader. But I guess it won't make sense anyway, because NixOS strata should NOT take over bootloader, at least I guess it shouldn't.
I've also tried hijacking NixOS, for fun because why not.
I've symlinked init from NixOS to /sbin/init
so it was the proper location for Bedrock to see it. It kinda worked. where kinda is an appropriate word.
It indeed created /bedrock
directory and files in it, but complete-hijack-install
is an empty file.
Seems like it also doesn't add things from /bedrock
and it's subdirectories to $PATH, but brl
can somewhat be run directly.
Proof (I hope) that this was done on NixOS:
Also, brl fetch
kinda works as well.
But I've ran outta space on my VM. So I couldn't purse that further. But I'm gonna take a look there once I free up some space. I'll keep it in mind.
I've also been experimenting with just Nix
on Bedrock itself. As a package manager it works perfectly fine. Nix-Shells, Nix Flakes, Home Manager, all of them work, but sadly, NixOS will require further attention and work, I'll be looking forward to research it further in the near future. But this looks promising.
If hijack script have produced empty complete-hijack-install maybe🤷 we can use such thing like modifying .bashrc/hijack-script to catch where is it fails? I don't know, but maybe you need ask [here][(https://github.com/NixOS/nixpkgs/issues/24346#issuecomment-720093424), why it have improper dir for systemd, when Artix is s6(non-systemd) init based distribution. Also you could give a try to GuixSD (which has nix as crucial part) if you don't mind to use this OS as a core of commercial product.
NixOS requires systemd.
Which is an interesting problem for Bedrock, what if you don't want systemd on your machine but want to use NixOS?
I remember a while back, a reason I didn't want to switch over to NixOS from Gentoo was because of the init system. Most people in the NixOS community are the "embrace systemd" type.
Anyways, iirc Nix needs systemd and doesn't have an alternate init system option as of yet.
NixOS indeed requires systemd, but Nix, as a package manager itself, doesn't. It works perfectly fine on Artix, Alpine and on Bedrock where Artix or Alpine are init stratums. Even flakes work perfectly fine.
Yes, modyfing hijack-script sounds like a good idea. Without that, I assume the problem is due to weirdness of NixOS...
Anyway, 'fetchability' of NixOS also needs to be done, but seems like we have a good start there. I wonder how this will end when it comes to bootloader
options in configuration.nix
file, same when it comes to NixOS strata providing an init. I'll continue my research in that field.
Also. In the meantime of my 'research', I've found two promising projects.
One, states to be heavily based on NixOS, but anyway it claims to be working with runit init system. Quoting: but compiles down to a kernel, initrd, and a 48mb squashfs
, this looks.. promising? I hope.
And the second one, which claims, quoting: process manager agnostic Nix-based process managed framework that can be used to run multiple instances of services on a single machine, using Nix to deliver and isolate all required package dependencies and configuration files.
. This sounds even more promising, and it does have a support for s6 init.
I don't know if it's important, but those things might help us later. Or at least we can take an inspiration from them. They both sound promising.
Everything here sounds promising, I'll continue my research and I'll keep you updated.
Any updates on this? I hear some discussion on getting openrc to work on nixos however at the moment I think we should be concerned with getting Nixos to work with Bedrock first, its immutable nature while being one of its benifits may be a disadvantage when trying to get bedrock to work, you would possibly need to build brl in accordance with nix store by implimenting it in configuration.nix or a flake
Any updates on this? I hear some discussion on getting openrc to work on nixos however at the moment I think we should be concerned with getting Nixos to work with Bedrock first, its immutable nature while being one of its benifits may be a disadvantage when trying to get bedrock to work, you would possibly need to build brl in accordance with nix store by implimenting it in configuration.nix or a flake
Sadly, no NixOS-specific progress in quite some time. My frustratingly limited resources have been primarily focused on getting 0.8.0 out, which due to unexpected personal life constraints is taking much longer than I had expected. I don't plan on personally pursing NixOS support until after 0.8.0 is out the door, and I haven't had much success with contributors for things like this.
Various planned features of 0.8.x may help with minor roadmaps for NixOS compatibility. For example, the 0.8.x roadmap includes (initially limited) cross-stratum services support which could be used to have another distro's init kick off the Nix daemon service at boot time. Or for another, 0.8.x is planned to support having the Bedrock-specific file locations be relocatable, which could allow experimentation with putting the Bedrock-specific files in a location NixOS doesn't track quite as closely and is content to allow mutation.
I also expect 0.8.0's eventual release to gather attention and collect more potential contributors which could assist here.
Known goals:
brl fetch
supportKnown issues:
brl
norpmm
is present, but the/bedrock
directory was created, with an empty, unwritable file calledcomplete-hijack-install