Re: files/dd7c394c9c9ddf4b97f1b14c676f370adc259b2c7a4b8346eba0788a431db398.gz not found -- snapshot corrupt.

From: Olivier Smedts <olivier_at_gid0.org>
Date: Sun, 14 Aug 2011 15:08:35 +0200
2011/8/14 Alexander Best <arundel_at_freebsd.org>:
> On Sun Aug 14 11, Niclas Zeising wrote:
>> On 2011-08-13 12:08, Roland Smith wrote:
>> > On Sat, Aug 13, 2011 at 09:51:41AM +0200, Hartmann, O. wrote:
>> >> On 08/13/11 09:26, Roland Smith wrote:
>> >>> On Sat, Aug 13, 2011 at 12:43:52AM +0200, Hartmann, O. wrote:
>> >>>> On 08/12/11 22:54, Roland Smith wrote:
>> >>>>> On Fri, Aug 12, 2011 at 08:44:07PM +0200, Hartmann, O. wrote:
>> >>>>>>>> files/dd7c394c9c9ddf4b97f1b14c676f370adc259b2c7a4b8346eba0788a431db398.gz
>> >>> Does this file actually exist if you extract the snapshot? And are the
>> >>> permissions et cetera OK?
>> >>>
>> >>> Roland
>> >>
>> >> No, it does not.
>> >>
>> >> What I did so far over night:
>> >>
>> >> I deleted /var/db/portsnap as well as /usr/ports/. Then I tried again.
>> >> Again failure.
>> >> After that it got the ports tree via CVS (make update in /usr/ports).
>> >> Everything seems
>> >> all right. I tried portsnap again. portsnap compalins about a
>> >> non-portsnap-created /usr/ports
>> >> and please me to use 'extract'. I do ... but then I run into the very
>> >> same failure:
>> >>
>> >> (portsnap fetch extract:)
>> >> /usr/ports/devel/cccc/
>> >> /usr/ports/devel/ccdoc/
>> >> /usr/ports/devel/ccrtp/
>> >> /usr/ports/devel/cdash/
>> >> files/dd7c394c9c9ddf4b97f1b14c676f370adc259b2c7a4b8346eba0788a431db398.gz not
>> >> found -- snapshot corrupt.
>> >
>> > I've been looking at the portsnap shellscript. This error message is generated
>> > by the shell's built-in test command, specifically '[ -r'. It is looking for a
>> > file that was extracted with tar. So the place to look for the bug is IMO
>> >
>> > 1) the portsnap script itself (differences between 8.2 and 9?)
>> > 2) the sh(1)'s built-in test command (ditto)
>> > 3) tar (ditto)
>> >
>> > When you run 'portsnap fetch' it downloads a tgz archive and unpacks it with
>> > tar(1). What you could try is to comment out the line 'rm ${SNAPSHOTHASH}.tgz'
>> > in portsnap, and test if the tgz file extracts differently using an
>> > 8.2-RELEASE tar and the 9-CURRENT tar.  If so, that would be a bug!
>> >
>> > Roland
>>
>> Just a "me too!". It happens for me on a recently updated 9-current
>> virtual machine, built with clang.
>
> same here:
>
> /usr/ports/databases/gigabase/
> /usr/ports/databases/godis/
> files/39644d98f9e9b9d9a362cbfc075a996683e8a611a4362d883247c9a2e2fa2658.gz not found -- snapshot corrupt.
>
> running r224841 on amd64 built with base clang.

Aparently fixed with latest HEAD *kernel* :

# svn log -v -r224842
------------------------------------------------------------------------
r224842 | rwatson | 2011-08-13 18:03:40 +0200 (sam 13 aoû 2011) | 10 lignes
Chemins modifiés :
   M /head/sys/kern/vfs_syscalls.c

When falloc() was broken into separate falloc_noinstall() and finstall(),
a bug was introduced in kern_openat() such that the error from the vnode
open operation was overwritten before it was passed as an argument to
dupfdopen().  This broke operations on /dev/{stdin,stdout,stderr}.  Fix
by preserving the original error number across finstall() so that it is
still available.

Approved by:    re (kib)
Reported by:    cognet

------------------------------------------------------------------------

You won't be able to buildworld with the buggy kernel, but you can
buildkernel and reboot on the new kernel. No problems with portsnap
after that (don't know if you have to clean the old portsnap files, I
did it).

-- 
Olivier Smedts                                                 _
                                        ASCII ribbon campaign ( )
e-mail: olivier_at_gid0.org        - against HTML email & vCards  X
www: http://www.gid0.org    - against proprietary attachments / \

  "Il y a seulement 10 sortes de gens dans le monde :
  ceux qui comprennent le binaire,
  et ceux qui ne le comprennent pas."
Received on Sun Aug 14 2011 - 11:08:37 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:16 UTC