NixOS with no control of boot process

I have a machine that boots linux, but in a non-standard way. Is it possible to install NixOS on the machine in a way where NixOS does not manage the boot process, and I manually configure the bootloader?

(This is about an ARM64 chromebook, but I think it’s not necessarily an ARM-specific question. I currently have the chromebook capable of booting into Debian, but not in a way that (IIUC) NixOS supports. But it seems to me, that maybe I don’t really need NixOS to “support” booting my chromebook – after all, Debian doesn’t really support it either, and it runs okay)

1 Like

NixOS wants to controll its own bootloader, it effectively has to, to be able to manage the generations.

If you want to “dualboot” just dissallow setting efi vars for the NixOS BM and configure your primary bootloader to chainload NixOS’ bootloader.

This is the recommended way.

If there is something else you need to do to make the debian work, tell us what that is, and we might help you porting that over to the NixOS boot process. I have seen people reporting successful boots on ChromeBooks. Not sure about the exact model though.

1 Like

If you really want to avoid NixOS controlling the bootloader, maybe, using a boot.isContainer = true; could help here or copying this idea.

2 Likes

Maybe what you are looking for is home-manager?

I believe any other way you will end up with a bunch of conflicts in /etc/

To clarify (or maybe I’m the only one who’s misunderstanding):

I was imagining/hoping that NixOS would have 100% control of the filesystem/partition(s) that it lives in. Just not control of any boot partitions/sectors/whatever outside of there.

Maybe the solution would be for NixOS to blithely install and manage a non-working boot-loader somewhere in its domain, and I would manually copy over kernel/ramdisk/whatever to the “real” boot-loader as/when necessary. Maybe that’s very close to the “dualboot” solution NobbZ was suggesting above.

I’m new to NixOS (why start using it in a simple situation?!). I feel like the “real” answer is “contribute support for my chromebook to NixOS”, but I’m not quite at that point yet.

1 Like

What’s the issue with the bootloader thing anyways? NixOS has a bootloader for RPI, I’d assume it would work on a Chromebook too

Oh right, it works on pine64 laptops too!

Hmm… my thinking is that the RPi (and a Pinebook Pro) is sufficiently different from a Chromebook that works-on-one doesn’t mean works-on-the-other, but really, I don’t know.

The boot method I’m currently using is the Chromebook-standard, Chromebook-specific boot mechanism of writing a special boot payload to a magic boot partition. I don’t fully understand it yet, but I think it (or some part of it) is called “depthcharge”. Long-term, I imagine the solution would be to add support for this chromebook-specific boot process into NixOS (it can be done with only open-source SW), or porting a boot system already supported by NixOS to this chromebook. But I’m not ready to take the lead on either of these, and I’m not sure how long I’d have to wait for someone else to do it.

It doesn’t seem like it’d be a terrible loss (considering my non-mission-critical situation) to forgo applying the NixOS system to boot management while I get familiar with how NixOS handles most/all of the other aspects of system management.

Actually, maybe googling for “nixos” and “depthcharge” is the way to go…

But I still think it’d be somewhat simpler to go the “leave-booting-out-of-NixOS-control” route for now, if that were possible.