OPNsense Forum
Archive => 19.1 Legacy Series => Topic started by: misterj on February 07, 2019, 02:12:30 pm
-
Hi all
I am running 18.7.10_4 and for some reason, I cannot get the upggade to 19.1 to work.
I've tried via the GUI and also via the raw console. In both cases I get a few reboots and then it boots back into 18.7.10_4. So I am assuming that the upgrade is failing somewhere.
What information can I provide or logs can I comb through to get some help?
Thanks
-
You will need to give some kind of error message or the output from the update console
-
That's just the problem. There is nothing that prints out.
I've watched from the raw console and it downloads the tar, them the txz, then it reboots to install and apply them, then it reboots again and back into 18.7.10_4.
Is there an update.log or something in Opnsense that might have the information?
-
When you unlock the upgrade, are you doing Update or Upgrade? Once you unlock it you have to hit the "Update" I believe it's the upper button and not the "Upgrade". So I would do the Unlock again if it's still there and then try Update not upgrade.
-
I'll give that a shot and see what difference it makes.
For what it's worth, I've tried typing in 19.1 from the raw console (not ssh) and I'm still not getting any joy.
I'll see how that goes. Thanks!
-
Nope, that doesn't work. Using Update Now instead of Upgrade Now after doing the unlock upgrade makes no difference.
I've found /var/log/bsdinstaller/ - is there anything that might have an error message in here?
This is really starting to get frustrating...
-
Please try the following:
Change the mirror, Save, Check for Updates
-
Didnt work either.
Changed to the Opnsense Amsterdam mirror from default.
I changed the mirror in settings, did an Check for updates, Update now, reboot, check for updates, unlock upgrade, upgrade now.
Still on 18.7.10_4.
I'm starting to wonder if this is something like hardware, EFI vs BIOS or something...
-
Unlikely, maybe space related ?
You didn't mention whether is a physical box (and specs) or a VM (which could be snapshoted) but your easiest bet would be grabbing the installer for 19.1 and importing the configuration in the process. Make sure you have a backup just in case.
Also, for a physical box, making sure you have the latest BIOS/Firmware would be generally helpful and highly recommended.
-
Physical box. It's not space related - the disk is 120Gb in size and logs are being rotated. UI says only 5Gb is being used.
Box is running an Intel 7th Gen Celeron with 4Gb of RAM which is probably overkill for what I need, but that's the specs.
Starting to think that this may be the case... (do an import of config afterwards).
-
My turn to chime-in.
I am having exactly this same issue. I started at 18.7.10_4, OpenSSL edition on the Protectli FW4A w/ 8GB:
https://i.imgur.com/GxDdDg2.png
From there, back at the release of 19.1 (not the now-changed 19.1.1), I followed ALL of the steps listed in order. Then I scoured the forums, and tried many different things. And I even took screenshots as I went along.
* Attempted to use the "Update" instead of the "Upgrade" button, makes no difference:
https://i.imgur.com/urtUglm.png
* Sometimes I'd get this message:
https://i.imgur.com/GNpTUU3.png
* Other times, I'd get this one:
https://i.imgur.com/ZsFO86I.png
* The system rebooted after actually showing it downloading the 19.1 images & kernel:
https://i.imgur.com/CE2eHvV.png
* No matter what, trying an upgrade looked like it was going to work, using "Unlock" and "Upgrade":
https://i.imgur.com/Wf5ebgx.png
Steps taken:
- Changed mirror from "default" to "Leaseweb", ran "updates", it DL'ed 18.7.10_4 (again), and rebooted:
**Note: lost this screenshot**
- Considered changing from "default" (currently "OpenSSL") over to "LibreSSL" but wasn't sure if it was HW-specific or just a choice:
https://i.imgur.com/XtyXW9s.png
I looked through all of the logs that made logical sense, looking for "fail"/"failure"/"warning" and all the other ones...; I tried updating from the console/CLI (using both "Y" and "19.1"); I dug through so many forum posts I fell asleep at my keyboard. I still haven't found the "right" or "wrong" thing I'm doing/not-doing so as to make this work.
I'm not really ready to take down the internet for half of a day just to reinstall my whole install. And while I have an ESXi server, it'll still take half of a day to get a new VM up and then re-route the networking.
Does ANYONE know what's going on or causing this problem? :'( ... HELP! ...
-
Can you try selecting OpenSSL, Save, check for updates, 12 and confirm with 19.1 ?
Note that a few reboots will happen automatically and you should be on 19.1.1 at the end
-
No change with changing to OpenSSL either.
In the end, I got tired of pissing about and just did the reinstall and a reupload of my config which... doesnt reinject your plugins yay!
So I am going through that process now.
Pretty disappointed with this upgrade experience to be honest.
I think I have spent more time pissing about trying to get it to work properly than the upgrade took (something like maybe 8 minutes in total including the reupload of the config?)
-
The worst thing about it is that the devs have no error logs about what went wrong, and while the best assumption right now would likely go towards a regression on the BSD side of things we'll never really know...
As for the upgrade experience overall, I wouldn't pin an opinion on a failed upgrade and for what it's worth given the extent of the changes in 19.1 and the addition of HBSD thanks to the great work put in by lattera and his team I would say that overall it's been quite stellar, with a few minor glitches and regressions that were at the end of the day to be expected given time and resources.
Glad it all worked out for you though.
-
The worst thing about it is that the devs have no error logs about what went wrong, and while the best assumption right now would likely go towards a regression on the BSD side of things we'll never really know...
I'm thinking I should log a feature request for this, because honestly it's a 100% requirement. I would have been happy to self diagnose if there was a log provided.
The only things that I can think of as to the failure would be one of the messages I saw on the raw console. I could see the message "Install Opnsense 19.1.txz" followed by "Please reboot" and it would reboot... into 18.7. So clearly either the install failed (which failed very quickly as the time between the Install message and reboot was less than 30 seconds) or there was an issue writing to disk or something. Any log would have been fine.
As for the upgrade experience overall, I wouldn't pin an opinion on a failed upgrade
The upgrade from 18.1 to 18.7 was really smooth. I barely noticed it. The point updates have always been really good. I really like Opnsense's development model and that the team develops regularly. That's half of why I moved to Opnsense - because of the pace of development and delivery of bug fixes and the like.
And this is where the disappointment is born from. I'm sure 19.7 will be a lot smoother, but right now I am just annoyed, mostly, at the lack of logs rather than the upgrade failing.
-
now I am just annoyed, mostly, at the lack of logs rather than the upgrade failing
Hear hear. Logs are the first place I went looking for clues, to no avail. Other FOSS applications I use (even https://dietpi.com/ (https://dietpi.com/)) have a straightforward and easy-to-use "here's the error log, go to this address _____ and submit a report". You'd think a competitive product like OPNsense would as well.
-
For reasons of perspective let me chime in here:
The worst thing is that users modify their installs in unknown ways, not include this in their "steps to reproduce" and then also don't provide console output on the upgrade (serial capture, VGA video with a mobile phone) as we always suggest supervised upgrades and we're left to guess what went wrong while also workarounds are mentioned elsewhere in the forum.
Anyone can complain, anyone can add logging, but it won't solve complaints and unless there is a time machine nothing will change about the current situation.
-
You are correct, to a point.
For example, I - for one - don't "modify" something like OPN as I have no programmatic knowledge. As I stated in my earlier posts, not only did I follow the rules as laid out for us but I also scoured the forums for the knowledge to save myself before even asking for help.
I'm certain there are plenty of people who visit the forums once, make loud complaints to anyone involved, and then never respond or post again. In that sense, I am not one of those people. I posted asking for assistance and agreed with another user's point (while also making a suggestion for an enhancement that would allow an end-user to find the answers they need).
It would seem you took it as criticism. And not even as constructive criticism. Perhaps a PM or other format to ask your audience what they mean ... instead of publicly posting a complaint which makes no headway in an end user's (or two) issue(s).
-
I'm not taking it as criticism. I merely question the rationale behind it.
We do not need logging changes for a system that was in place since end of 2016 that now "suddenly" breaks. The likelihood of an external source for this behaviour is high so I'd like to know this first before deciding how useful logging really is.
I've asked for serial console output for a number of times now, I got nothing. I have hints of how to reproduce, but it would take a few hours of time that nobody is going to be sponsoring so I would rather like to spend it on something more productive for the project like shipping fixes that already exist for 19.1.2 in a timely fashion.
Cheers,
Franco
-
PS: The workaround described here https://forum.opnsense.org/index.php?topic=9521.msg51688#msg51688 is more effective than any discussion on the matter so far. We have yet to hear from someone saying this didn't work.
-
Franco (and others),
I too am having this same issue. For me it is a physical and for evaluating purposes so it is not in production. As for the console output I can confirm there isn't any. No errors, no real responses, just what has been mentioned, downloading, installing and reboot. I can film it if you like.
Now to that end is there any options to run the upgrade command from a prompt with a switch(s) set to get debug commands piped to a file? Although the work around to install and restore the config exists, if there is a bug lurking somewhere it would be great to find it now instead of it possibly showing up later in a uglier/widespread way.
As for my setup it is a stock install with three interfaces: Inside, Outside and Management. I can even upload my config if you like. Like I said nothing in the box, no rules other than what is needed to get the management interface to work.
It may take me a few days to test things but am happy to try and help.
-
Here is the upgrade output from the command line:
root@OPNsense:~ # opnsense-update -Vur 19.1
+ [ -n '' ]
+ [ '' '=' -T ]
+ [ -z '' ]
+ DO_KERNEL=-k
+ DO_BASE=-b
+ DO_PKGS=-p
+ [ -n '' ]
+ [ -n '' ]
+ [ -n '' ]
+ [ -z '' ]
+ [ -n -k -a -n '' -a -z -u ]
+ [ -n -b -a -n '' -a -z -u ]
+ [ -n '' ]
+ [ -n '' ]
+ [ -n '' ]
+ [ -n '' ]
+ [ -n '' ]
+ [ -z 19.1 ]
+ [ -b '=' -B ]
+ [ -p '=' -P ]
+ [ -n '' ]
+ [ -p '=' -p -a -z -u ]
+ FLAVOUR=Base
+ [ -n '' ]
+ [ -f /usr/local/bin/openssl ]
+ /usr/local/bin/openssl version
+ awk '{ print $1 }'
+ FLAVOUR=OpenSSL
+ PACKAGESSET=packages-19.1-OpenSSL-amd64.tar
+ KERNELSET=kernel-19.1-amd64.txz
+ BASESET=base-19.1-amd64.txz
+ mirror_abi
+ sed -n 's/^[[:space:]]*url:[[:space:]]*\"pkg\+\(.*\/${ABI}\/[^\/]*\)\/.*/\1/p' /usr/local/etc/pkg/repos/OPNsense.conf
+ MIRROR='http://mirrors.nycbug.org/pub/opnsense/${ABI}/18.7'
+ opnsense-verify -a
+ ABI=FreeBSD:11:amd64
+ [ -n '' ]
+ eval 'MIRROR=http://mirrors.nycbug.org/pub/opnsense/${ABI}/18.7'
+ MIRROR=http://mirrors.nycbug.org/pub/opnsense/FreeBSD:11:amd64/18.7
+ echo http://mirrors.nycbug.org/pub/opnsense/FreeBSD:11:amd64/18.7
+ MIRROR=http://mirrors.nycbug.org/pub/opnsense/FreeBSD:11:amd64/18.7/sets
+ [ -n '' ]
+ [ -z '' ]
+ [ 19.1 '=' 18.7.10 -a -n -k ]
+ [ 19.1 '=' 18.7.10 -a -n -b ]
+ [ -z -k-b-p ]
+ [ -p '=' -p ]
+ fetch_set packages-19.1-OpenSSL-amd64.tar
+ STAGE1='opnsense-fetch -a -T 30 -q -o /var/cache/opnsense-update/50494/packages-19.1-OpenSSL-amd64.tar.sig http://mirrors.nycbug.org/pub/opnsense/FreeBSD:11:amd64/18.7/sets/packages-19.1-OpenSSL-amd64.tar.sig'
+ STAGE2='opnsense-fetch -a -T 30 -q -o /var/cache/opnsense-update/50494/packages-19.1-OpenSSL-amd64.tar http://mirrors.nycbug.org/pub/opnsense/FreeBSD:11:amd64/18.7/sets/packages-19.1-OpenSSL-amd64.tar'
+ STAGE3='opnsense-verify -q /var/cache/opnsense-update/50494/packages-19.1-OpenSSL-amd64.tar'
+ [ -n '' ]
+ [ -n '' ]
+ echo -n 'Fetching packages-19.1-OpenSSL-amd64.tar: .'
Fetching packages-19.1-OpenSSL-amd64.tar: .+ mkdir -p /var/cache/opnsense-update/50494
+ opnsense-fetch -a -T 30 -q -o /var/cache/opnsense-update/50494/packages-19.1-OpenSSL-amd64.tar.sig http://mirrors.nycbug.org/pub/opnsense/FreeBSD:11:amd64/18.7/sets/packages-19.1-OpenSSL-amd64.tar.sig
.+ opnsense-fetch -a -T 30 -q -o /var/cache/opnsense-update/50494/packages-19.1-OpenSSL-amd64.tar http://mirrors.nycbug.org/pub/opnsense/FreeBSD:11:amd64/18.7/sets/packages-19.1-OpenSSL-amd64.tar
...+ [ -n -V ]
+ opnsense-verify -q /var/cache/opnsense-update/50494/packages-19.1-OpenSSL-amd64.tar
+ echo ' done'
done
+ [ -b '=' -b ]
+ [ -z '' -o -n -u ]
+ rm -f /usr/local/opnsense/version/base.lock
+ fetch_set base-19.1-amd64.txz
+ STAGE1='opnsense-fetch -a -T 30 -q -o /var/cache/opnsense-update/50494/base-19.1-amd64.txz.sig http://mirrors.nycbug.org/pub/opnsense/FreeBSD:11:amd64/18.7/sets/base-19.1-amd64.txz.sig'
+ STAGE2='opnsense-fetch -a -T 30 -q -o /var/cache/opnsense-update/50494/base-19.1-amd64.txz http://mirrors.nycbug.org/pub/opnsense/FreeBSD:11:amd64/18.7/sets/base-19.1-amd64.txz'
+ STAGE3='opnsense-verify -q /var/cache/opnsense-update/50494/base-19.1-amd64.txz'
+ [ -n '' ]
+ [ -n '' ]
+ echo -n 'Fetching base-19.1-amd64.txz: .'
Fetching base-19.1-amd64.txz: .+ mkdir -p /var/cache/opnsense-update/50494
+ opnsense-fetch -a -T 30 -q -o /var/cache/opnsense-update/50494/base-19.1-amd64.txz.sig http://mirrors.nycbug.org/pub/opnsense/FreeBSD:11:amd64/18.7/sets/base-19.1-amd64.txz.sig
.+ opnsense-fetch -a -T 30 -q -o /var/cache/opnsense-update/50494/base-19.1-amd64.txz http://mirrors.nycbug.org/pub/opnsense/FreeBSD:11:amd64/18.7/sets/base-19.1-amd64.txz
................................+ [ -n -V ]
+ opnsense-verify -q /var/cache/opnsense-update/50494/base-19.1-amd64.txz
+ echo ' done'
done
+ [ -k '=' -k ]
+ [ -z '' -o -n -u ]
+ rm -f /usr/local/opnsense/version/kernel.lock
+ fetch_set kernel-19.1-amd64.txz
+ STAGE1='opnsense-fetch -a -T 30 -q -o /var/cache/opnsense-update/50494/kernel-19.1-amd64.txz.sig http://mirrors.nycbug.org/pub/opnsense/FreeBSD:11:amd64/18.7/sets/kernel-19.1-amd64.txz.sig'
+ STAGE2='opnsense-fetch -a -T 30 -q -o /var/cache/opnsense-update/50494/kernel-19.1-amd64.txz http://mirrors.nycbug.org/pub/opnsense/FreeBSD:11:amd64/18.7/sets/kernel-19.1-amd64.txz'
+ STAGE3='opnsense-verify -q /var/cache/opnsense-update/50494/kernel-19.1-amd64.txz'
+ [ -n '' ]
+ [ -n '' ]
+ echo -n 'Fetching kernel-19.1-amd64.txz: .'
Fetching kernel-19.1-amd64.txz: .+ mkdir -p /var/cache/opnsense-update/50494
+ opnsense-fetch -a -T 30 -q -o /var/cache/opnsense-update/50494/kernel-19.1-amd64.txz.sig http://mirrors.nycbug.org/pub/opnsense/FreeBSD:11:amd64/18.7/sets/kernel-19.1-amd64.txz.sig
.+ opnsense-fetch -a -T 30 -q -o /var/cache/opnsense-update/50494/kernel-19.1-amd64.txz http://mirrors.nycbug.org/pub/opnsense/FreeBSD:11:amd64/18.7/sets/kernel-19.1-amd64.txz
...........+ [ -n -V ]
+ opnsense-verify -q /var/cache/opnsense-update/50494/kernel-19.1-amd64.txz
+ echo ' done'
done
+ [ -k '=' -k ]
+ echo '!!!!!!!!!!!! ATTENTION !!!!!!!!!!!!!!!'
!!!!!!!!!!!! ATTENTION !!!!!!!!!!!!!!!
+ echo '! A critical upgrade is in progress. !'
! A critical upgrade is in progress. !
+ echo '! Please do not turn off the system. !'
! Please do not turn off the system. !
+ echo !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
+ [ -p '=' -p -a -n -u ]
+ echo -n 'Extracting packages-19.1-OpenSSL-amd64.tar...'
Extracting packages-19.1-OpenSSL-amd64.tar...+ rm -rf '/var/cache/opnsense-update/.sets.pending/packages-*'
+ mkdir -p /var/cache/opnsense-update/.sets.pending/packages-19.1
+ pkg-static clean -qya
+ tar -C/var/cache/opnsense-update/.sets.pending/packages-19.1 -xpf /var/cache/opnsense-update/50494/packages-19.1-OpenSSL-amd64.tar
+ echo 19.1
+ [ -n '' ]
+ echo ' done'
done
+ [ -b '=' -b -a -n -u ]
+ echo -n 'Extracting base-19.1-amd64.txz...'
Extracting base-19.1-amd64.txz...+ rm -rf '/var/cache/opnsense-update/.sets.pending/base-*'
+ mkdir -p /var/cache/opnsense-update/.sets.pending
+ mv /var/cache/opnsense-update/50494/base-19.1-amd64.txz /var/cache/opnsense-update/.sets.pending
+ echo 19.1
+ echo ' done'
done
+ [ -k '=' -k ]
+ install_kernel
+ KLDXREF='kldxref /boot/kernel'
+ [ -n -u ]
+ KLDXREF=:
+ echo -n 'Installing kernel-19.1-amd64.txz...'
Installing kernel-19.1-amd64.txz...+ mkdir -p /boot/kernel /boot/kernel.old /usr/lib/debug/boot/kernel
+ rm -r /boot/kernel.old /usr/lib/debug/boot/kernel
+ mv /boot/kernel /boot/kernel.old
+ tar -C / -xpf /var/cache/opnsense-update/50494/kernel-19.1-amd64.txz
+ :
+ echo ' done'
done
+ [ -n -b -a -z -u ]
+ [ -p '=' -P -a -z -u ]
+ [ -z '' ]
+ rm -rf /var/cache/opnsense-update/50494
+ echo 'Please reboot.'
Please reboot.
Did a reboot and still on version 18.
-
I had the same issue. Just the base files and kernel have been installed. Once rebooted version was still 18.7.10.
I exported configuration, made a fresh install with 19.1 and used the importer during setup to restore configuration. The update from 19.1 to 19.1.1 worked without any problems.
-
hbc,
I am aware of that work around. However I am willing to do this in a effort to find the root cause. At the moment it is only affecting a small number of people but at a future juncture it could be a problem that affects a large group or everyone. Or it may never happen again. Since I have a setup that is exhibiting the symptoms and I am not in production and I am willing to do some testing and digging to find the root cause, I put the offer out there. If there is no interest then so be it.
I look at problems like this: You are using a metal detector. It goes off during a search. No one else had their detector go off. Until you dig it up and find out what it was you have no way of knowing if it was a piece of scrap or a landmine. Where is was at could be on a obscure spot or in what will become the main path. There is no way to know what will happen until you know what it was and where it is.
I am just offering my time and the use of my setup to test. If there is no interest then so be it, I will move on but if the powers to be want to dig in then I am willing. I know just enough to be dangerous. Franco said that he had seen no screen shots and had no feedback so I was looking to provide that. I am new to this platform and have a bit of Linux experience (enough to be dangerous) so I am not a complete idiot (just a partial one, just ask my wife). I did some digging and read the man page for opnsense-update and found the -V option. So I decided to provide that output. Did you see any issues in the output that were significant?
-
After running the command from a couple post back, today I logged back into the firewall and went to the upgrade page. I found the page as shown in the attached picture. It shows the current kernel as 19.1 and the upgrade as 18.7.10. Why would that be? It looks like it is going to roll it back. Could this have something to do with the failed upgrade?
-
Here is the upgrade output from the command line:
root@OPNsense:~ # opnsense-update -Vur 19.1
------
.+ opnsense-fetch -a -T 30 -q -o /var/cache/opnsense-update/50494/packages-19.1-OpenSSL-amd64.tar http://mirrors.nycbug.org/pub/opnsense/FreeBSD:11:amd64/18.7/sets/packages-19.1-OpenSSL-amd64.tar
...+ [ -n -V ]
------
Did a reboot and still on version 18.
I re-did a V18 setup in a Virtualbox-VM and updated it from command line like you, then I diff'ed the command line output. The only differences were
- the '/var/cache/opnsense-update/85548' folder.
I assume the folder-name/-number here is random
and this here:
.+ opnsense-fetch -a -T 30 -q -o /var/cache/opnsense-update/85548/packages-19.1-OpenSSL-amd64.tar http://mirrors.nycbug.org/pub/opnsense/FreeBSD:11:amd64/18.7/sets/packages-19.1-OpenSSL-amd64.tar
........................................................................+ [ -n -V ]
I have a lot more dots. Now I don't know if they signify the size of the file or just the time it took to download.
If I do a
wget http://mirrors.nycbug.org/pub/opnsense/FreeBSD:11:amd64/18.7/sets/packages-19.1-OpenSSL-amd64.tar
at my Linux CLI the file that's downloaded is
'Length: 494723072 (472M)'
How big is yours ?
I rebooted the VM rebooted and it came back up with V19.1.1.
-
You're one step away from 19.1.2 which is $current. ;-)
-
newsense
He is testing to compare to my output.
Bonkerton
My setup does not have wget but I was able to use fetch and pull down the package. I get the same size as you did. The man page indicated that the dots were time related, they just let you know it is doing something "whistle while you work" and are not related to size. My pipe is around 500Meg and it took 1m32s to download.
Thanks for testing.
-
Continuing to poke around and got this output which agrees with the screenshot I got before:
root@OPNsense:/var/cache/opnsense-update # uname -a
FreeBSD OPNsense.vw.edu 11.2-RELEASE-p8-HBSD FreeBSD 11.2-RELEASE-p8-HBSD 31af16db12b(stable/19.1) amd64
So it appears the kernel is actually on 19.1 but the OPNSense package did not upgrade? Or am I reading this wrong?
-
The -u switch will do the major upgrade and then it won't update again.
Did you install any ports manually? From FreeBSD packages? Sensei plugin maybe?
On the box do this:
# opnsense-update -fp -n "19.1\/latest"
...and reboot.
Cheers,
Franco
-
Okay, so prior to running the command you sent I had did a manual install of kernel from the GUI and it rolled the kernel back to 18.7. After running your command the firewall is now at 19.1 but the kernel and base are reporting 18.7. That is exactly opposite of what I had before.
Should I apply the updates of the base and kernel now or do you want/need any thing else before I do?
Attached are the screenshot of the update page after the command was run and the SSH log of the command being run.
Also the only added item was Sensei. Everything else was stock out of the box. I did a clean install, setup the interfaces and added Sensei. Nothing else added or installed that I can recall.
-
Yes, Sensei install can cause this. We'll work together with Sunnyvalley to avoid similar problems in the 19.7 upgrade.
Not sure how you got back on the base and kernel, but applying the updates is a good idea and the issue will be resolved.
Cheers,
Franco
-
Franco,
So I finally got back to this and after applying the updates all is well in OPNsense land.
As for reverting back it appeared that the update was stuck in a loop. The base and kernel would update but OPNsense would not. When the firewall would come back up after the update and check it would see the 18.7 as an update to 19.1 and then revert the kernel and base back to 18.7. Then after the reboot it would see the 19.1 as the update... rinse lather repeat......
Performing the update using the command you gave forced the 19.1 OPNsense to install on the 18.7 kernel and base and then after a reboot the kernel and base was seen as needing the update to 19.1 and applied as expected. I am now on 19.1.3. Hopefully you can find a fix. Now there is an in place workaround for those who do not want to reload the firewall from scratch or can't due to access restrictions.
Thanks,
Doug