Install stuck for hours with 100% CPU usage #402
Comments
|
This problem seems to occur only in configurations where I use ZFS. If I change it to use F2FS, everything works fine. Perhaps I've made a mistake with ZFS, but both vmWithDisko and --vm-test seem to work fine. |
|
why are you auto-gc'ing so much == thats so crazy |
I dunno, am I supposed not to? |
|
it looks like you're running out of space during install |
|
I'm not sure that's the case, because an otherwise equivalent install using F2FS works. I'll try to make a minimal reproducible example |
Seems like you're right, because this little situation with unresponsive VPS happens at the same step as previously even if I disable garbage collection. But how can I check what causes this though? |
|
I would use disko-install to configure the storage with the disko config you are using and verify the sizes you think you are specifying are what ends up happening. I would not use nixos-anywhere until i knew my disko config was working as intended. verify that /nix/store is not too small. maybe share your disko config, and the output of you may consider getting on the nixos matrix chat if you want suggestions in real time |
Yeah, you're right, guessing the cause of the problem from my info so far is next to impossible :) Thanks, I'll try matrix |
|
This is the output of It makes sense that |
|
I am having a similar problem on a VPS with 1GB of RAM. I can I did the same on the same VPC ~1 month ago and it worked, I am not sure what changed. |
|
same issue on cloudcone vps with 1GB of RAM [root@nixos-installer:~]# df
Filesystem 1K-blocks Used Available Use% Mounted on
tmpfs 478724 7536 471188 2% /
tmpfs 478724 36 478688 1% /nix/.rw-store
/dev/loop0 284672 284672 0 100% /nix/.ro-store
overlay 478724 36 478688 1% /nix/store
overlay 478724 7536 471188 2% /etc
tmpfs 239364 3100 236264 2% /run
devtmpfs 47876 0 47876 0% /dev
tmpfs 478728 0 478728 0% /dev/shm
tmpfs 478728 1088 477640 1% /run/wrappers
tmpfs 95744 4 95740 1% /run/user/0 |
|
Through a web of linked github issues, I found a comment saying that it is most likely due to the decompression happening on-target after downloading the built binaries from cache. Edit: not completely true, kexec still chokes with the "vanilla" kexec tarball. Here, adding |
|
Using this command, I was able to deploy https://github.com/phaer/nixcon-2024-examples (hi @phaer 😄 ) onto a 1 GB VPS. git clone https://github.com/phaer/nixcon-2024-examples.git
cd nixcon-2024-examples
nix develop
nixos-anywhere -L -f .#example-uefi --kexec "$(nix build --refresh --print-out-paths github:luqasn/nixos-images#packages.x86_64-linux.kexec-installer-nixos-unstable-noninteractive)/nixos-kexec-installer-noninteractive-x86_64-linux.tar.gz" --no-substitute-on-destination --debug root@<yourip>The key points here are the custom kexec with This is where I got the cache hint: I first tried the copy stage "manually" without compression like so: nixos-anywhere -L -f .#example-uefi --kexec "$(nix build --refresh --print-out-paths github:luqasn/nixos-images#packages.x86_64-linux.kexec-installer-nixos-unstable-noninteractive)/nixos-kexec-installer-noninteractive-x86_64-linux.tar.gz" --debug --phases kexec,disko root@<my-ip>
nix copy --extra-experimental-features 'nix-command flakes' --no-write-lock-file -L --substitute-on-destination --to 'ssh://root@<my-ip>?remote-store=local?root=/mnt&compression=none' /nix/store/6j26apa0wvy4zg7di09m74b6j955xji0-nixos-system-example-uefi-24.11pre-gitwhich worked, but then I discovered the |
|
Personally, none of these workarounds solved the problem on my system. Since the VPS I was using allowed third party ISOs I was able to boot a nixos-minimal ISO and remount /nix/.rw-store with a larger size after creating a swap partition on the target disk device. Not entirely the one-step process I was hoping for (and presumably it won't help on generic distributions) but a solution nevertheless. If there's a way to increase the size of /nix/.rw-store with |
Hm, interesting. Personally I'd have thought that using |
When using
nixos-anywhereto install, at one point the installation process gets stuck, VPS becomes highly unresponsive and CPU usage goes to the moon. I've tried to wait, but it doesn't seem to move further:The text was updated successfully, but these errors were encountered: