orivej_ has quit [Ping timeout: 256 seconds]
orivej has joined #nixos-aarch64
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #nixos-aarch64
Sonarpulse has joined #nixos-aarch64
<shad> Hello everyone.
<samueldr> welcome back!
<shad> I'm trying to nixos-rebuild from a prebuild sd-image that I installed a few days ago (one a pine 64, with the help of samueldr for pinpointing a working uboot)
<shad> and I'm running into the following error:
<shad> copying path '/nix/store/dhqnmz17wfn2bi7kvrdva9ym62r5dxvj-glibc-locales-2.27' from 'https://cache.nixos.org'...error 9 while decompressing xz file
<shad> Hi samueldr
<shad> Has this error occured to anyone before?
<samueldr> is it consistent or has it happened once?
<shad> all the time
<shad> I never managed to get a nixos-rebuild switch to work
<samueldr> that's a nixos-rebuild --upgrade, or at least, after a channel upgrade?
<shad> I did the nix-channel --update, but it wasn't working either.
<shad> Using the channels was not working, so I tried using the nixpkgs's git
<samueldr> weird, though looks like the cache.nixos.org itself isn't problematic: https://gist.github.com/samueldr/bb7b79a9bcc0e599151dcc2a0efd87ef
<samueldr> (unless you're at a place where they now block amazon IPs)
<samueldr> ah (sorry for the intrusion) but I don't think .fr providers would :)
<shad> I don't think they would either (and it's OK)
<samueldr> so uh, as a hunch, is there anything in `dmesg` that could point towards failing storage (either FS or hardware)
<shad> At least, this is consistant, the nix-store --realise command does not work
<samueldr> that's uh, reassuring?
<shad> dmesg does not indicate FS issues
<samueldr> hmmm, I wouldn't think anything specific to the A64 non-lts would cause that, though I may be wrong
<shad> disk is not full
<samueldr> yeah, disk full errors are... more obvious :) (from experience)
<samueldr> since it doesn't look like aarch64-specific, I encourage you to ask on #nixos, shad
<shad> BTW, before I tried any of that, I let the device run idle for a few days. I hit the bug when I was in year 2113 (or something like that). Quite obviously, cache.nixos.org's certificate were expired. :-)
<shad> It seems like a good idea. I'm just a little bit afraid that it's coming from a dumb mistake.
<samueldr> well, if it's a dumb mistake, searching through the logs makes me think you're the first one to make it
<samueldr> and it doesn't look obvious to me
<shad> I'll extract the error logs to make it pretty (my serial output is quite horrible).
<shad> Oh, and nix-store --verify --check-contents returned a few path that needed fixing.
<samueldr> https://git.tukaani.org/?p=xz.git;a=blob;f=src/liblzma/api/lzma/base.h;h=566247a19bb856c44529bbdc806626796090a334;hb=HEAD#l171
<samueldr> using my guessing hat, this is possibly the error you're hitting
<shad> indeed
<samueldr> if you have another SD card on hand, I would use something like f3 to verify it's not corrupting data, and then try using it instead of your current storage
<samueldr> (as a troubleshooting step)
<shad> I'm don't have any extras for now
<shad> -'m
<shad> samueldr: which branch would you advise for the nixpkgs repo ? master or unstable-aarch64 ?
<samueldr> uh, the one the image shipped with
* samueldr is checking
<samueldr> though, that's a channel and not a branch in the main nixpkgs repo, it would approximate to master, but (definitely probably) a bit behind
<samueldr> if you want a git repo with branches tracking channels, this would be it https://github.com/NixOS/nixpkgs-channels
<samueldr> (this is useful to get the greatest amount of pre-built things)
<shad> Ah, I never paid attention to that repo, but it could have been useful on my x86 computers. :-)
<samueldr> still would on aarch64 I think
<shad> samueldr: I think my issue might be coming from the xz command
<samueldr> explain
* samueldr is now in doctor mode https://www.emacswiki.org/emacs/EmacsDoctor
<shad> give me a few sec, I'll copy and paste it somewhere
<sphalerite> nix verify --all --no-trust
<sphalerite> might be worth doing, to check that the executable hasn't just been corrupted.
<samueldr> is there a difference with `nix-store --verify --check-contents`, since shad said they did it earlier
<sphalerite> oh right, I missed that. It's the same thing but with pretty progress info
<samueldr> good to know :) (I assumed that verify command would handle corrupt store paths)
<sphalerite> it doesn't do repairs though
<shad> alright, this is various "output" from my board
<shad> samueldr: I suggest you have a closer look at manual-curl-pine64.txt and manual-curl-x86.txt
<shad> I now believe the xz command somehow does not work on my system (on some archive, not all)
<samueldr> *totally a guess* what could happen is that both nix and that xz are using the same libs
<samueldr> give me a couple minutes, I have something I'd like you to try
<sphalerite> shad: 9 isn't even a documented exit code for xz.
<shad> sphalerite: (I'm running nix verify --all --no-trust as you suggested)
<shad> (2 corrupted so far)
<sphalerite> oh!
<sphalerite> Well that would explain it
<sphalerite> you said you ran nix-store --verify --check-contents earlier though?
<sphalerite> That should have found the errors too
<samueldr> eh, guess that `nix-store --realise /nix/store/ci96w9kxfkmlc7x2vwqiz4da0r6abxnq-nix-2.0 && /nix/store/ci96w9kxfkmlc7x2vwqiz4da0r6abxnq-nix-2.0/bin/nix-store --realise /nix/store/dhqnmz17wfn2bi7kvrdva9ym62r5dxvj-glibc-locales-2.27` won't be useful (as a test)
<sphalerite> I had all kinds of fun with a corrupted copy of gcc at one point. It dumped some very particular escape codes to the terminal which made everything following its invocation unreadable, including the commands I was typing
<clever> sphalerite: type reset
<clever> thats the command to restore the tty to defaults
<sphalerite> yeah I did that
<sphalerite> in the end I snapped the SD card in half as revenge for the wasted hours :p
<clever> lol
<shad> sphalerite: yes, there was some errors with nix-store --verify
<clever> modern cards can survive that
<clever> half the card is just empty
<sphalerite> it was a microSD
<clever> ah
<clever> those are more likely to die a painful death
<sphalerite> :)
<sphalerite> shad: `nix-store --repair-path` on the broken ones might fix the problems
<shad> I'll try to come by a new microSD card as well, it might take me a few days however.
<sphalerite> depending on whether the SD is to blame and how badly it's broken if so
<shad> sphalerite: I tried that already, but it couldn't uncompress the "repair" (error 9 as I recall)
<shad> I'll try again though
<sphalerite> ooh right
<sphalerite> heh, nice catch-22 you've got there
<samueldr> shad: just for kicks, using a fallback nix, possibly copy-closured?
<samueldr> or a mount -o remount re-write of that particular xz path
<clever> samueldr: `nix copy` and other 2.0 things can modify the sd card from an x86 host
<samueldr> clever: yeah, something like that!
<shad> samueldr: I'm not too familiar with copy-closure
<shad> I'll look into it.
<clever> with nix 2.0
<shad> But you guys are too fast to provide me help.
<shad> I can't keep up with your suggestions :-)
<samueldr> if anyone can muster a fix out of thin air, clever can
<clever> NIX_REMOTE=local?root=/mnt/ nix-store --verify --check-contents
<shad> [3543 paths verified, 4 corrupted]
<clever> this will check if the store is corrupted
<clever> nix copy /nix/store/foo --to local?root=/mnt/
<clever> this will copy from the host to the card
<sphalerite> why not just nix-store --store /mnt --verify --check-contents --repair ?
<clever> that will probably also work
<shad> samueldr: just tried "nix-store --realise /nix/store/ci96w9kxfkmlc7x2vwqiz4da0r6abxnq-nix-2.0" and it went through with much errors
<shad> (a warning at the end that seems "legit")
<samueldr> the warning would be normal, though I would definitely try what clever and sphalerite proposed, mounting the SD card on another computer and fixing the store using nix there
<shad> I'll do that in a minute. I'm popping from the stack of suggestions here. :-)
<shad> nix-store --repair-path on the xz directory didn't help much in getting xz to uncompress my "hard to uncompress" archive
<shad> I'll stop the system and do the clever trick (quite an easy pun)
<shad> sphalerite & clever: both your suggestion do not seem to pick up the path to my sdcard (I replaced /mnt with the real path to the root)
<clever> does the new host have nix 2?
<clever> and is the command being ran as root?
<shad> let me check
<shad> nix 2.0
<shad> I just tried root (I was "sudo -E" before, in order to pass the argument)
<shad> (it seems to pick up the argument, because it does not offer the same output when I change it)
<shad> I have hundreds of "error: getting attributes of path '/nix/store/syajplxha9904wzc2302ac0mni9wjz7a-libXau-1.0.8.drv': No such file or directory"
<clever> oh, wiat, one min
<shad> which is true, and "/media/sdg2/nix/store/syajplxha9904wzc2302ac0mni9wjz7a-libXau-1.0.8.drv" exists however
<clever> --verify doesnt obey the root
<shad> (so it's picking up something)
<clever> you need to run a copy of nix from master to have that work
<samueldr> 2.0.1 would include that fix I presume
<shad> That seems fine. But I'll have to do that tomorrow though.
<shad> My sleep time is already quite stretched.
<shad> Thank you a lot samueldr, clever and sphalerite !
<clever> yep
<samueldr> I learned about --realise recently, so in theory using `$(nix-store --realise /nix/store/2gk7rk2sx2dkmsjr59gignrfdmya8f6s-nix-2.0.1)/bin/nix` no need to figure out how to get that particular fixed nix?
<samueldr> (path taken from the updated fallback paths)
<clever> samueldr: that relies on the current nix being able to access a binary cache
<samueldr> yeah, that was assumed