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
signature.asc
Description: OpenPGP digital signature