Install NixOS on 512 MB RAM


#1

Hi all I’m Chris and new in here.

I’ve the question if it is possible in any way to install NixOS on a Machine / Instance with only 512 MB RAM.
Currently with the latest ISO it seems not to work.

Background: I’m just evaluating to use NixOS in production as my main LXC and/or maybe runc host.
I’m using Nix for my CI Builds quite a time, but was still not committed to try an systemd based OS for my deployments.

All the best, Chris


#2

Perhaps more of a work-around: but if you do run out of memory, you could allocate a file and use it as a temporary swap-file. I’ve done that in cases where RAM has been exhaused.


#3

Hmm, I’m not quite sure how do do this.
My problem is I can’t even boot NixOS from the ISO (using UEFI).

So the only possibility I see, to do this, is to boot a slimmer OS and then install NixOS from it?


#4

My problem is I can’t even boot NixOS from the ISO (using UEFI).

So the only possibility I see, to do this, is to boot a slimmer OS and then install NixOS from it?

How does it fail to start? It doesn’t boot at all or does boot and fails
tostart the graphical environment?

Did you try using minimal installation CD?1 It doesn’t include Plasma
and X11, thus it is much smaller and easier on resources.


#5

It does’nt boot at all. Of course I’m already using the minimal ISO.
But it seems that the minimal ISO is still to less minimal.

Failure:

But maybe my which to install NixOS on 512 MB memory is just a bit too much for this kind of distribution.


#6

Maybe we should enable zram swap by default on Live CD. They recently added zstd support, which can double/triple RAM without much speed penalty (great for limited memory systems).

Maybe even set zstd as default zram compression algo for kernels 4.19+


#7

I don’t know about more recent versions of NixOS but successfully installed 16.09 on a 512MiB machine. So perhaps you could try installing an older NixOS version and then upgrade in-place? I made a little writeup about my install, which admittedly is a bit non-standard because I had to boot from network and then switch to a USB install.


#8

Is it possible to use zstd for our tmpfs somehow?


#9

I’ve made a a few QEMU runs for minimal ISO and reproduced your issue.

In minimal ISO boot menu there are several options. One of them (not default) is called copytoram. So, when I choose copytoram boot option I have this OOM error too during boot with 512M RAM.

However, default boot option (without copytoram) boots fine even on 256M RAM. Are you sure you don’t want to choose this boot option?


#10

¯_(ツ)_/¯
SO says tmpfs will use swap, so zram swap theoretically should cover this usecase.

Practically, zram swap isn’t started early. It’s a systemd service as of now.
Another problem is that zstd compression is available only in linuxPackages_latest. Will 4.18 become default kernel in 19.03? We also don’t publish iso_minimal_new_kernel images on a site,


#11

I run 512Mb VMs on Vultr without issues.

Have a look at https://github.com/elitak/nixos-infect which is meant for cloud VMs but which you can probably repurpose for your usecase.

It is able to install NixOS from a non Nix system (in place) and incidentally, it also creates a swap file so that the install succeeds on low-memory systems.

See also https://nixos.org/nixos/manual/#sec-installing-from-other-distro


#12

4.19 is longterm kernel and nixos-unstable channel already defaults to it ATM.


#13

:yay:! I’ve set zstd as default in my PR

I also have a branch for zram-in-installer. I plan to add zramSwap.enable to default configuration.nix for devices with <=4Gb, as nowadays 4Gb is little-RAM device… I was able to run installer test with 256Mb RAM, zram device and no swap. Yup, nixos-rebuild switch didn’t choke! This however won’t improve topicstarter situation (copytoram).


#14

Ok, thanks to everybody for your very good inputs.

I still have some troubles.
I’m able to install NixOS on 512MB via BIOS. No chance on 256MB.
Via UEFI I have still no chance even on 512MB.

I’m not using “copytoram” in any case - always default.

So my résumé in my testing case is, my troubles must have something to do with Hyper-V which I’m using.