GNU bug report logs -
#30875
Garbage collector may leave empty files
Previous Next
Reported by: Marius Bakke <mbakke <at> fastmail.com>
Date: Tue, 20 Mar 2018 11:22:01 UTC
Severity: normal
Done: Marius Bakke <mbakke <at> fastmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 30875 in the body.
You can then email your comments to 30875 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-guix <at> gnu.org
:
bug#30875
; Package
guix
.
(Tue, 20 Mar 2018 11:22:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Marius Bakke <mbakke <at> fastmail.com>
:
New bug report received and forwarded. Copy sent to
bug-guix <at> gnu.org
.
(Tue, 20 Mar 2018 11:22:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello,
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
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#30875
; Package
guix
.
(Tue, 20 Mar 2018 23:10:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 30875 <at> debbugs.gnu.org (full text, mbox):
Hello,
Marius Bakke <mbakke <at> fastmail.com> 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’.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#30875
; Package
guix
.
(Wed, 21 Mar 2018 00:22:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 30875 <at> debbugs.gnu.org (full text, mbox):
ludo <at> gnu.org (Ludovic Courtès) writes:
> Marius Bakke <mbakke <at> fastmail.com> 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? :-)
The ext[234] filesystems are well known for leaving zero-length files
around after a crash. So far, I've never seen Btrfs do that, and I
wouldn't expect it to based on its design. That's partly why I switched
to it.
Mark
Information forwarded
to
bug-guix <at> gnu.org
:
bug#30875
; Package
guix
.
(Wed, 21 Mar 2018 20:34:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 30875 <at> debbugs.gnu.org (full text, mbox):
Mark H Weaver <mhw <at> netris.org> skribis:
> ludo <at> gnu.org (Ludovic Courtès) writes:
[...]
>> 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? :-)
>
> The ext[234] filesystems are well known for leaving zero-length files
> around after a crash. So far, I've never seen Btrfs do that, and I
> wouldn't expect it to based on its design. That's partly why I switched
> to it.
Sorry, I didn’t mean to imply that Btrfs is flawed. It’s just that I’ve
never experienced that with ext[234].
Ludo’.
bug closed, send any further explanations to
30875 <at> debbugs.gnu.org and Marius Bakke <mbakke <at> fastmail.com>
Request was from
Marius Bakke <mbakke <at> fastmail.com>
to
control <at> debbugs.gnu.org
.
(Tue, 12 Feb 2019 23:26:01 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Wed, 13 Mar 2019 11:24:11 GMT)
Full text and
rfc822 format available.
This bug report was last modified 5 years and 16 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.