Bug 188220

Summary: freebsd-update(8) destroys installation
Product: Base System Reporter: jonas.bulow
Component: binAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed Overcome By Events    
Severity: Affects Only Me CC: emaste, grahamperrin
Priority: Normal    
Version: 10.0-RELEASE   
Hardware: Any   
OS: Any   

Description jonas.bulow 2014-04-03 10:40:01 UTC 
I have used freebsd-update to upgrade the system. After upgrade there are many mismatches with what is expected according to freebsd-update IDS.

# freebsd-update fetch install
Looking up update.FreeBSD.org mirrors... 5 mirrors found.
Fetching metadata signature for 10.0-RELEASE from update2.freebsd.org... done.
Fetching metadata index... done.
Inspecting system... done.
Preparing to download files... done.

No updates needed to update system to 10.0-RELEASE-p0.
No updates are available to install.
Run '/usr/sbin/freebsd-update fetch' first.
# freebsd-update IDS | wc -l
39485

More or less every file has the wrong SHA256.

Fix: 

Reinstall from scratch.
How-To-Repeat: Use freebsd-update to upgrade the system to 10.0-RELEASE.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2014-04-14 00:27:34 UTC 
Responsible Changed
From-To: freebsd-bugs->cperciva

Over to maintainer.
Comment 2 David Chisnall freebsd_committer freebsd_triage 2014-04-23 09:05:01 UTC 
This has also been my experience.  Of the four machines that I've =
updated from 9.x to 10.0 with freebsd-update, not one has ended up with =
a working 10 configuration.    I thought one had done, but it turned out =
that it only had a 10 kernel, but most of a 9.2 userland, which I only =
discovered as a result of pkg installing the wrong version kernel =
modules. =20

I've recovered a couple by doing the env UNAME_r=3D trick and forcing =
freebsd-update to run again, but this didn't work for two of them and =
I've ended up having to untar the files from the distribution sets.

Updating then to 10.0-RELEASE-p1 with freebsd-update then works fine, so =
it's just something about the 9->10 transition (and, yes, I did remember =
to do freebsd-update fetch / install / reboot first to make sure I had =
the latest version of freebsd-update).

Given that freebsd-update IDS can detect that it's failed to install =
some of the files, it would be nice if it could then fix them, rather =
than just giving you a long list of things that you have to fix =
manually...

David
Comment 3 Eitan Adler freebsd_committer freebsd_triage 2018-05-28 19:47:56 UTC 
batch change:

For bugs that match the following
-  Status Is In progress 
AND
- Untouched since 2018-01-01.
AND
- Affects Base System OR Documentation

DO:

Reset to open status.


Note:
I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.
Comment 4 Colin Percival freebsd_committer freebsd_triage 2019-03-12 22:59:51 UTC 
Drop freebsd-update PRs which were assigned to me.  I'm not working on this code any more.
Comment 5 Graham Perrin freebsd_committer freebsd_triage 2021-12-19 16:49:39 UTC 
(In reply to David Chisnall from comment #2)

> … just something about the 9->10 transition …

Might this bug be closed, overcome by events?
Comment 6 Graham Perrin freebsd_committer freebsd_triage 2022-05-21 04:21:47 UTC 
(In reply to jonas.bulow from comment #0)

Fast forward eight years. 

Please, have you encountered this bug with any currently supported RELEASE?
Comment 7 Glen Barber freebsd_committer freebsd_triage 2022-05-21 04:29:17 UTC 
The problem here is 10.0 was built against the tagged release/10.0.0, which had different RCS IDs in various files, i.e., $FreeBSD$.

This also happened during 10.1-RELEASE, which was built against releng/10.1, during which an upgrade from 10.0 would change the RCS IDs from "$FreeBSD ... blah... release/10.0.0$" to "$FreeBSD ... blah ... releng/10.1."

This can be closed as OBE.