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>
(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>
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 ?
<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
<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"
<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