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



## rtwingfield (Mar 11, 2017)

While executing `freebsd-update -r 11.0-RELEASE upgrade`
Well, what can be done about this?


```
Fetching metadata signature for 11.0-RELEASE from update.FreeBSD.org... done.
Fetching metadata index... done.
Fetching 1 metadata patches. done.
Applying metadata patches... done.
Fetching 1 metadata files... done.

The update metadata is correctly signed, but failed an integrity check.
Cowardly refusing to proceed any further.
```
I have tried `rm -rf /var/db/freebsd-update/*`
followed by `freebsd-update fetch`
. . .then `freebsd-update -r 11.0-RELEASE upgrade` . . .yet again.

No joy!  What to do?  how to get the coward to show some courage?


----------



## gkontos (Mar 11, 2017)

Make sure that you are in the latest patchset  revision of your current FreeBSD version. So, you need to first go over:

`#freebsd-update fetch`
`#freebsd-update install`

Then reboot if it is required and continue with the upgrade to 11-RELEASE


----------



## rtwingfield (Mar 12, 2017)

gkontos said:


> Make sure that you are in the latest patchset  revision of your current FreeBSD version. So, you need to first go over:
> 
> `#freebsd-update fetch`
> `#freebsd-update install`
> ...


Well, did this, but the upgrade still crashed.  I have no idea where it was in the process . . .something about rebooting and running the upgrade again.  It seemed to finish but the OS v10.3 is still there, bootable but severely damaged.   Several things seem to be missing or out of place.  Attempts to execute `ifconfig` result in ifconfig: shared object "libpix.so.5" not found required by "ifconfig".  It's just gone from the system.

Additionally several services, such as apache, ssh, ntp, sendmail, etc. fail to start.  It issues messages such as (from a system call) limits: setrlimit kqueues:  invalid argument.  I have no idea what this means or what to do to fix it.  I'm at the point of recovering current versions of configuration files and installing FreeBSD v11.0 from a fresh FreeBSD-11.0-RELEASE-i386-bootonly.iso CD, and rebuilding the applications from the ports.

Any suggestions?   . . .anyone?


----------



## gkontos (Mar 13, 2017)

I am not sure what you did exactly but it looks like you have partially upgraded your system. At this point maybe `freebsd-update rollback` would work but since I don't know exactly where the problem occurred I am not certain.


----------



## rtwingfield (Mar 13, 2017)

gkontos said:


> I am not sure what you did exactly but it looks like you have partially upgraded your system. At this point maybe `freebsd-update rollback` would work but since I don't know exactly where the problem occurred I am not certain.


Ran it and seemed to work; commands such as `tar` and `ifconfig` work once again however, the file, libpix.so.5, is still not found on the system, but the `ifconfig` command (now working) does not issue the message, ifconfig: shared object "libpix.so.5" not found required by "ifconfig".  Strange???

And still, the system call, limits: setrlimit kqueues: invalid argument is failing and I don't know what to do to resolve the problem.  This is preventing most services from starting, eg.  apache24, hald and dbus.

Is this something _broken_ in the kernel?   In other words,  "limits: setrlimit kqueues: invalid argument"
. . .*where*?   . . .what is _invalid_?

What to do?


----------



## rtwingfield (Mar 14, 2017)

*MAJOR UPDATE!*



> . . . the system call, limits: setrlimit kqueues: invalid argument _was_ failing and I don't know what to do to resolve the problem.  This is preventing most services from starting, eg.  apache24, hald and dbus.



This problem apparently and mysteriously "_fixed_" itself.  I have no idea how.  I segued to another problem . . .installing a Logitech USB wireless mouse.  Last evening and this morning, I rebooted the system several times, but the same error message (from a system call) 
	
	



```
limits: setrlimit kqueues: invalid argument
```
 . . .persisted; however, for some freeky reason, while trying different rc.conf arguments for the moused (daemon). the problem went away, hald and dbus loaded and the _mouse_ started working as advertised.

I'd still like to know what the invalid argument _thing_ was all about.

All I know is that the httpd(apache24), sshd, ntpd and other services are running and working.  I'm almost reluctant to reboot the system again.  

. . .and just successfully rebooted!  So strange.


----------



## rtwingfield (Mar 15, 2017)

*What actually happened:
*


> This problem apparently and mysteriously "_fixed_" itself.  I have no idea how.


for some unknown reason, during the modification and test of the 
	
	



```
moused (port, type)
```
 specs in /etc/rc.conf,  the system actually rolled-back from *v10.3* to *v7.2 RELEASE p8*.  This has resulted in loss of configuration files, e.g., apache24 back to apache22.  Not sure about other installed ports . . .haven't had time to check, mysql databases for example.

How could this have happened?  This is just awful . . .and strange.  Apparently the rollback _explains_ the fix of the system call error msg., limits: setrlimit kqueues: invalid argument.  A more-or-less working version of the OS was restored.  But how back to v7.2 ????

I'm thinking of a major fresh install of v11.0 and restoration/rebuild of all ports, data, etc.


----------

