| 10 Aug 2023 |
 p14 | Though I'm only tracing daemon side.. | 14:17:32 |
| p14 | No evidence of files being opened client side either. | 14:19:14 |
| p14 | So I think --rebuild is not functioning as I'd expect(?!) | 14:19:23 |
 trofi | It should compare narHash: https://github.com/NixOS/nix/blob/master/src/libstore/build/local-derivation-goal.cc#L2640 | 14:20:08 |
| trofi | Which means you probably build the result as expected, but on disk /nix/store path is corrupted on disk. But it's hash is never calculated and is fetched from database instead. | 14:26:01 |
| trofi | Does nix store verify --all (or at least ./result) succeed for you? | 14:26:57 |
| p14 | You got it -- verify shows incorrect hash. | 14:27:46 |
| trofi | \o/ | 14:27:57 |
| p14 | So, uhm, how'd this happen and why doesn't --rebuild protect me against this? | 14:28:16 |
| trofi | What filesystem is that? ext4 likes to zero files it was not sure to complete write on crash. | 14:28:17 |
| p14 | btrfs | 14:28:38 |
| trofi | Hm, that is expected to behave better. | 14:28:59 |
| trofi | Does nix store repair ./ fix it? | 14:29:54 |
| trofi | * Does nix store repair ./result fix it? | 14:30:02 |
| p14 | So, I haven't rebooted. Since I've been building these paths. | 14:30:04 |
| p14 | I've found three bad paths:
path '/nix/store/9kaazhysw3pmzlrslpb1nsgy97hq8hlm-x86_64-unknown-linux-gnu-llvm-binutils-wrapper-15.0.7' was modified! expected hash 'sha256:00fr4fvkwihh37ch61hwiqswn2d451n3d0blqdlzrwxj7xwl76jj', got 'sha256:0x2klzdyhmyivgqnppll5a7jj41vzxjb5lb5a9gs534541vsw0kp'
path '/nix/store/czfw2i8z6yhga8f5397wn4l9d5iivvyh-x86_64-unknown-linux-gnu-llvm-binutils-wrapper-15.0.7' was modified! expected hash 'sha256:02f8fa37y745ww8wh07i74abhgr2p1hr6m5xwkiyqvh4nzx00agr', got 'sha256:1d33lzfsnb8b20cs6lgdy9r8nn7xkar25ynz6wm1dbj4q74vzq34'
path '/nix/store/wpgi1r8dhhlay7x5wbswwqzxhh4mwdyf-llvm-16.0.1-dev' was modified! expected hash 'sha256:0sjbx0sszj4pfrkzpk8ca4n0sfwdbjwfdqa1034q8ics9fh1fbwz', got 'sha256:0k6gy7skgvjqvd448fa1h71rdcf9dzrv5y5wcz9yr1b52vh49d9r'
| 14:30:24 |
| p14 | I think those two gnu-llvm-binutils would have been built at different times. | 14:30:43 |
| p14 | nix store repair says, e.g.:
path '/nix/store/9kaazhysw3pmzlrslpb1nsgy97hq8hlm-x86_64-unknown-linux-gnu-llvm-binutils-wrapper-15.0.7' is corrupted or missing!
| 14:31:12 |
| p14 | I started building these this morning and my uptime is more than 2 days, so I guess it's not bad FS-or-device-behaviour-under-crash | 14:31:52 |
| p14 | Could sigquitting nix build explain it in principle? It's a keyboard shortcut I know...# | 14:32:14 |
| p14 | * Could sigquitting nix build explain it in principle? It's a keyboard shortcut I know... (not saying I know I used it) | 14:32:20 |
| trofi | I would hope nix-daemon is atomic in face of most stops. Especially when it comes to calculating the checksum of a finished build. But maybe there are bugs. | 14:33:37 |
| p14 | I'm hitting the problem of nix store delete ignore liveness not working | 14:34:30 |
| trofi | Worth running a scrub in the filesystem and running a memtest just in case there is a possibility of a hardware fault. | 14:34:35 |
| p14 | I have run memtest looking for hardware faults. scrub's a good idea | 14:34:52 |
| trofi | It's interesting that you got 2 different store paths with ...-llvm-binutils-wrapper-15.0.7 broken. Those ought to be independent failures unless you use auto-optimise-store = true (Or other deduplication methods) and corruption happened afterwards. | 14:37:11 |
| p14 | No auto optimizing or dedup | 14:37:33 |
| p14 | Currently trying to delete it from the store and see if it repros. | 14:37:44 |
| p14 | Though putting the daemon under strace seems to have broken it. Now running nix as a normal user I get 'error: opening a connection to remote store 'daemon' previously failed
' | 14:38:07 |
| p14 | I've done systemctl start nix-daemon, and it's running, but seem to have this sticky error | 14:38:28 |
