Hello, Marius Bakke <[email protected]> skribis:
> Recently I've seen a couple of instances like these: > > exporting path > `/gnu/store/mi1rbw8fdsbi4bc4pndbb6smq39722vm-baobab-3.26.1.tar.xz' > guix offload: error: build failed: hash of path > `/gnu/store/mi1rbw8fdsbi4bc4pndbb6smq39722vm-baobab-3.26.1.tar.xz' has > changed from > `4223b4813b2253e68ea2b824d0d0e284ff75714ad0faf5a33d65a78df6b65915' to > `77ac62e2629d8e45f624589c0c8bf99e24b3a722349bf1e79bc186008534e246'! > cannot build derivation > `/gnu/store/jbx6a4n1d55dpydr87d11m7xwapm3pcx-gnome-3.24.3.drv': 1 > dependencies couldn't be built > > Without the build hook, it manifests as: > > starting phase `unpack' > tar: This does not look like a tar archive > xz: (stdin): File format not recognized > tar: Child returned status 1 > tar: Error is not recoverable: exiting now > > There was another instance on help-guix recently with a user having > empty .drv files in the store. > > There is a bug lurking here somewhere, but I'm not sure where to start > looking. > > $ find /gnu/store/ -maxdepth 1 -size 0 | grep -v '\.lock$' | wc -l > 24 Are we sure this is a Guix issue and not a disk or file system corruption issue? The relevant code in guix-daemon hasn’t changed in ages. What file system are you using? Btrfs? :-) Thanks, Ludo’.
