| 10 Aug 2023 |
 p14 | Furthermore, I actually see another process read 4781 bytes from /nix/store/cks0priigwh4vpbfd1p7gzy1h0jcpw0q-x86_64-unknown-linux-gnu-llvm-binutils-wrapper-15.0.7.drv.chroot/nix/store/9kaazhysw3pmzlrslpb1nsgy97hq8hlm-x86_64-unknown-linux-gnu-llvm-binutils-wrapper-15.0.7/nix-support/setup-hook. | 14:15:27 |
| p14 | So I'm left thinking that something corrupted the file as it was being put into the store | 14:15:42 |
| p14 | And --rebuild isn't doing what I would expect to detect/fix the corruption | 14:16:02 |
 trofi | I think --rebuild never replaces files already present in store. | 14:16:33 |
| p14 | But should it not compare them at least?# | 14:16:49 |
| p14 | If it's comparing them and saying everything is OK, that suggests the corruption may be happening before the compare and is reproducible | 14:17:02 |
| trofi | Ah, that's a good point. Yeah, file comparison should happen. | 14:17:03 |
| p14 | I'm not seeing evidence in the trace log of a comparison happening | 14:17:26 |
| 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 |
