Solved The update metadata is correctly signed, but failed an integrity check

formaltux

formaltux

Hi,

I upgraded to 10.3 from 9.3 couple of weeks ago using buildworld, buildkernel, installkernel, installword.

Now I cannot binary update:

Code: 
root@somehost:~ # uname -a
FreeBSD some.host.com 10.3-RELEASE FreeBSD 10.3-RELEASE #0 r297672: Thu Apr  7 18:32:59 CEST 2016     root@some.host.com:/usr/obj/usr/src/sys/GENERIC  i386

Code: 
root@somehost:~ # freebsd-update fetch
Looking up update.FreeBSD.org mirrors... none found.
Fetching metadata signature for 10.3-RELEASE from update.FreeBSD.org... done.
Fetching metadata index... done.

The update metadata is correctly signed, but failed an integrity check.
Cowardly refusing to proceed any further.

I've tried to empty /var/db/freebsd-update but this had no effect.

How to fix this?

Thanks.
 
Last edited by a moderator:
I upgraded from 10.2 to 10.3 recently, now I think the first patch may have been released.
I'm getting the same error as yourself, re: failed an integrity check when running freebsd-update fetch

n.b. In my case freebsd-update fetch install returns the same error (i.e. everything was previously correctly installed and system rebooted).
 
Last edited by a moderator:
I have the same problem (upgrade from 10.2 to 10.3 -amd64 with freebsd-update).
Code: 
freebsd-version -ku
10.3-RELEASE
10.3-RELEASE
 
Same here.

First, I upgraded from my 10.2-RELEASE-p14 to 10.3-RELEASE successfully, but from there I got the error described here. I did make sure to run freebsd-update fetch install first---the message from the security team announcing 10.2-RELEASE-p15 just reached me after my upgrade to 10.3-RELEASE. I rolled back to 10.2-RELEASE-p14, updated to 10.2-RELEASE-p15, and now I get the error on every freebsd-update -r 10.3-RELEASE upgrade.

Code: 
[root@myhost ~]# freebsd-version -ku
10.2-RELEASE-p14
10.2-RELEASE-p15
[root@myhost ~]# uname -a
FreeBSD myhost 10.2-RELEASE-p14 FreeBSD 10.2-RELEASE-p14 #0: Wed Mar 16 20:46:12 UTC 2016  root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64

Code: 
[root@myhost ~]# freebsd-update -r 10.3-RELEASE upgrade
Looking up update.FreeBSD.org mirrors... 4 mirrors found.
Fetching metadata signature for 10.2-RELEASE from update6.freebsd.org... done.
Fetching metadata index... done.
Inspecting system... done.

The following components of FreeBSD seem to be installed:
kernel/generic world/base world/doc world/games world/lib32

The following components of FreeBSD do not seem to be installed:

Does this look reasonable (y/n)? y

Fetching metadata signature for 10.3-RELEASE from update6.freebsd.org... done.
Fetching metadata index... done.

The update metadata is correctly signed, but
failed an integrity check.
Cowardly refusing to proceed any further.
 
Attempting to freebsd-upgrade 10.3 also gives me

Code: 
The update metadata is correctly signed, but
failed an integrity check.
Cowardly refusing to proceed any further.
 
Same here, bump !


Code: 
root@mx001:~ # freebsd-update fetch
src component not installed, skipped
Looking up update.FreeBSD.org mirrors... 4 mirrors found.
Fetching metadata signature for 10.3-RELEASE from update4.freebsd.org... done.
Fetching metadata index... done.
Fetching 2 metadata patches.. done.
Applying metadata patches... done.
Fetching 2 metadata files... done.

The update metadata is correctly signed, but
failed an integrity check.
Cowardly refusing to proceed any further.
 
Same issue here on fresh FreeBSD 10.3 amd64.

Last time I see that (10.0), after maintainers remade the package the issue was gone.
 
I can confirm this issue as well and on a nearly clean base system, because iI am using jails for everything.
 
Last edited by a moderator:
If anyone cares, I too am experiencing this.

I actually was installing FreeBSD 10.3 so I could post an ongoing journal for the triumphs and failures I encounter while installing and using it. Guess I'll have to put it off until this silliness is resolved. o_O
 
Whew. At least it's not just me!

I've been in the process of updating systematically from 9.3 to 10.0 to 10.1 to 10.2 to 10.3...not sure if you're supposed to bother doing it that way, but it's a test system and I wanted to give it the most stress possible before upgrading a real system.

Anyway, I made it to 10.2-RELEASE, and then started getting the "cowardly" error message. I tried a few things (including catching up on the latest ntp patch), then rolled back a little at a time, and the issue didn't go away. I rolled all the way back to 10.0-RELEASE, which is now EOL, so I couldn't get to a decent patch level from there. I moved forward again, and am now safely holding at 10.1-RELEASE-p32, waiting until the issue is resolved.

I must say, I'm extremely impressed with the rollback system. I expected it to be a lot buggier, but it really does let you time travel fairly effectively. Kudos to the FreeBSD team for that.

If anything, this has been a productive learning experience, although I hope the fix is worked out soon.
 
This has been resolved now. I hope a short note will be published clarifying what broke by secteam@ at some point.
 
I can upgrade now, just noticed one thing though, after I upgraded, I checked the version:
Code: 
www:~ # freebsd-version

10.3-RELEASE-p1
Great, I was on the new release, as a check, ran the fetch again:
Code: 
www:~ # freebsd-update fetch

Looking up update.FreeBSD.org mirrors... 4 mirrors found.

Fetching metadata signature for 10.3-RELEASE from update6.freebsd.org... done.

Fetching metadata index... done.

Inspecting system... done.

Preparing to download files... done.



No updates needed to update system to 10.3-RELEASE-p0.
Note, it reports 10.3-RELEASE-p0 not p1, When I check the version again:
Code: 
www:~ # freebsd-version

10.3-RELEASE-p1

The version seems fine, but the update still reports no updated to p0 instead of p1. I'm not exactly going to lose sleep over it, but thought I'd mention it.
 
Perhaps the present issue is fixed, but the fix introduced a new problem, namely as MichaelL noted, the repository thinks 10.3-RELEASE is on patch level 0, but actually we are on p1 since mid of March. And people who are running a custom kernel do see the following now:
Code: 
Files on mirror (10.3-RELEASE-p0) appear older than what
we are currently running (10.3-RELEASE-p1)!
Cowardly refusing to proceed any further.
 
You must log in or register to reply here.
Back
Top