On 08/10/2017 11:27, Dr. Nikolaus Klepp wrote:
> Hi!
> 
> My notes suggest for this case:
> 
> pkg clean                     # cleans /var/cache/pkg/
> rm -rf /var/cache/pkg/*       # just remove it all
> pkg update -f                         # forces update  of repository catalog
> rm /var/db/pkg/repo-*.sqlite  # removes all remote repository catalogs
> pkg bootstrap -f              # forces reinstall of pkg
> 
> Do NOT delete /var/db/pkg/local.sqlite! It contains the database with your 
> installed packages. If you remove it the system will think you have nothing 
> installed. 
> 
> Nik
> 
> Am Sonntag, 8. Oktober 2017 schrieb Dr Josef Karthauser:
>> Hi,
>>
>> I’m having trouble upgrading a 10.3 machine to 10.4: looks like something is 
>> corrupt:
>>
>> Fetching metadata signature for 10.4-RELEASE from update4.freebsd.org... 
>> done.
>> Fetching metadata index... done.
>> Fetching 1 metadata patches. done.
>> Applying metadata patches... done.
>> Fetching 1 metadata files... done.
>> Inspecting system... done.
>> Fetching files from 10.3-RELEASE for merging... done.
>> Preparing to download files... done.
>> Fetching 38573 
>> patches.....10....20....30....40....50....60....70....80....90....100....110....120....130....140…
>> [cut]
>> Applying patches... done.
>> Fetching 9266 files...
>> gunzip: (stdin): unexpected end of file
>> efb4027db1ae440353955aa1bcfc9c69d1cafbdb53b4bfc6584d64b1e1bfd209 has 
>> incorrect hash.
>>
>> Has anyone else also seen this?
>>
>> Cheers,
>> Joe
>> — 
>> Dr Josef Karthauser
>> Chief Technical Officer
>> (01225) 300371 / (07703) 596893
>> www.truespeed.com <http://www.truespeed.com/>
>>   / theTRUESPEED <http://www.facebook.com/theTRUESPEED> 
>>   @theTRUESPEED <https://twitter.com/thetruespeed>
>>  
>> This email contains TrueSpeed information, which may be privileged or 
>> confidential. It's meant only for the individual(s) or entity named above. 
>> If you're not the intended recipient, note that disclosing, copying, 
>> distributing or using this information is prohibited. If you've received 
>> this email in error, please let me know immediately on the email address 
>> above. Thank you.
>> We monitor our email system, and may record your emails.

How exactly does blowing away your package cache or destroying your
package DB help with sorting out freebsd-update(8)?  That is fixing the
wrong problem...

To answer the OPs actual query -- yes, something is wrong with at least
one of the patches you have downloaded with freebsd-update(8).  You
should be able to find that broken patch file by name somewhere under
/var/db/freebsd-update -- simply removing that patch file and trying
again with 'freebsd-update fetch' _should_ get you an uncorrupted copy
of that particular patch.  In principle you can check all the patches
for correctness as the patch filename is the SHA hash of the contents,
although you'll have to work out exactly which SHA variant is being
used, and whether the checksum has been calculated on the compressed
patch as downloaded or on the de-compressed content.

With luck you've only got a problem with that one patch file, but if the
corruption is much wider, then moving aside your existing
/var/db/freebsd-update and starting again from scratch is probably a
good idea.

If you consistently get broken patch files from whichever of the update
servers you get directed to, that probably means that update server
needs some TLC.  Please do report that to clusteradm@... While waiting
for them to sort out the problems, you can play with the 'ServerName'
parameter in /etc/freebsd-update.conf to point yourself towards some
other server.

        Cheers,

        Matthew

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to