Firmware status check was aborted internally. Please try again.

[ManBat]

Hi,

Just an answer for a question in case you have the same problem I did. 

The kicker here is I have two gateways in a gateway group and one is down.

First error is the one above, firmware aborted.

Looking in System->Log files->Backend->

You see something like:
2020-06-20T21:08:48   configd.py: [a9b24ab8-c6e8-4258-8b39-fa198867b290] Show log
2020-06-20T21:04:08   configd.py: [06155d67-9587-4fcc-b545-096a7eefee37] retrieve upgrade progress status
2020-06-20T21:04:08   configd.py: [5b4c5b9a-1da4-455e-ace9-311c6d523094] Retrieving changelog index
2020-06-20T21:04:08   configd.py: [66aff237-681b-4f0a-91bf-b034e7335d62] view local packages
2020-06-20T21:04:08   configd.py: [b862b845-ad7b-4ded-893c-ceec4c3ab3f6] Script action failed with Command 'pkg rquery "%n|||%v|||%c|||%sh|||0|||%L|||%R|||%o"' returned non-zero exit status 74. at Traceback (most recent call last): File "/usr/local/opnsense/service/modules/processhandler.py", line 484, in execute stdout=output_stream, stderr=error_stream) File "/usr/local/lib/python3.7/subprocess.py", line 363, in check_call raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command 'pkg rquery "%n|||%v|||%c|||%sh|||0|||%L|||%R|||%o"' returned non-zero exit status 74.

If you shell onto the box to try to see if you can run this interactively, and do some more googling you might stumble upon some people remarking that the package server pkg.opnsense.org is down (I didn't believe this) so you try to ping it.   

Then you discover it is down.  So you go huh.  Then you try to ping some other things. 

root@firewall:/home/<dude># ping www.google.com
PING www.google.com (216.58.204.36): 56 data bytes
ping: sendto: Host is down
ping: sendto: Host is down
ping: sendto: Host is down

Now that *is odd*.  But your firewall is working?! And if you ping from diagnostics you get stuff fine and you can nslookup and so on.  People are accessing the internet through it and everything.

You do some more digging and you get "no route to host".  This is funny because clearly it does and the firewall can route stuff from itself out.

Then you run:
root@firewall:/home/<dude># route get www.google.com
   route to: ber01s14-in-f4.1e100.net
destination: default
       mask: default
    gateway: 192.168.50.1
        fib: 0
  interface: inf0
      flags: <UP,GATEWAY,DONE,STATIC>
 recvpipe  sendpipe  ssthresh  rtt,msec    mtu        weight    expire
       0         0         0         0      1500         1         0

At which point you now immediately know what's wrong.  Because 192.168.50.1 is gateway 1 of 2 and it is *offline* but not down.

I would attach a screenshot but the point is that both interfaces are shown as up although one is *offline*.  If you disable the interface that is offline and bring it down specifically, then the other one gets promoted to be the relevant route and voila.

It all starts to work.  Obvious really.

Therefore:

If you have *failing package updates*, with two gateways, 1 is offline but the interface is not down, bring it down properly for the purposes of your updates.  Then bring it up again so that it'll all work once it comes online again.

Hope this helps,

Cheers,
MB