Date: Thu, 15 Apr 2021 13:01:56 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 255091] freebsd-update should retry when encountering incorrect hashes Message-ID: <bug-255091-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D255091 Bug ID: 255091 Summary: freebsd-update should retry when encountering incorrect hashes Product: Base System Version: 13.0-STABLE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: misc Assignee: bugs@FreeBSD.org Reporter: timf@puroto.org Upgrading to 13.0-RELEASE has been a little slow because we often hit errors where one of the files that was phttpget'd was corrupt. Perhaps this= was a=20 problem with our ISP, we don't know. When hitting that error, we'd try again, hoping that this time we'd get a c= lean run, often failing again and having to manaully retry. The process of deciding which files to download isn't getting cached, so ea= ch time we retry, there's a lengthy calculation to do before we start the down= load attempt, which is unfortunate, but completely understandable (how would we do cache invalidation) Here's an example of the crash: root@puroto:/home/timf # freebsd-update --currently-running 12.2-RELEASE -b /space/jails/pupuru -r 13.0-RELEASE upgrade src component not installed, skipped Looking up update.FreeBSD.org mirrors... 3 mirrors found. Fetching metadata signature for 12.2-RELEASE from update1.freebsd.org... do= ne. Fetching metadata index... done. Fetching 1 metadata patches. done. Applying metadata patches... done. Fetching 1 metadata files... done. . . 7910....7920....7930....7940....7950....7960....7970....7980....7990....800= 0....8010....8020....8030....8040....8050....8060....8070....8080 done. Applying patches... done. Fetching 1842 files... ....10....20....30....40....50....60....70....80....90....100....110....120= ....1. . . 1740....1750....1760....1770....1780....1790....1800....1810....1820....183= 0....1840. 013ea614ef0dd0177d85c3699276a6f40a0071ded8c54d364bb342eacdedc306 has incorr= ect hash. root@puroto:/home/timf # Instead of just bailing out, it would be better if we instead saved the incorrect files to a list, then looped around until we have no more files l= eft. We worked on a fix for this at: https://github.com/freebsd/freebsd-src/compare/main...timfoster:freebsd-upd= ate-retry?diff=3Dsplit which seems to be doing the right thing here. We notice that 'portsnap' also has similar logic, bailing out on the first error, so this work could probably be extended. A few things we haven't yet considered in this fix: 1. does this deserve a new command line flag '--retries <number>' where <number> is the amount of retries, or they keyword 'infinite' (or 'always')= to always retry? 2. what should the default behaviour be? We're not sure why phttpget is downloading corrupted files, whether that's something in our network environment, ISP, or just heavy load upstream, but regardless of that, it would be nice if freebsd-update was more resilient. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-255091-227>