OPNsense Forum
Archive => 16.1 Legacy Series => Topic started by: franco on August 27, 2015, 10:17:58 am
-
Hi all,
preliminary tests are looking good, but proceed with caution:
(1) This is a development snapshot of our 10.2 branch, it may not work as expected.
(2) Firmware upgrades will trigger a reinstall of our latest 10.1 and force a reboot, even if it doesn't advertise it.
It doesn't change your actual OPNsense package and since 10.2 brings mostly improvements while changing little of the OS behaviour it can be used in a production setting given the necessary precautions (backups, snapshots, test setups). With that in mind, installation is pretty simple:
# opnsense-update -bkr 10.2 && reboot
("-b" means base update, "-k" means kernel update and "-r 10.2" means use the image named "10.2")
For a list of changes since FreeBSD 10.1 please consult this document:
https://www.freebsd.org/releases/10.2R/relnotes.html
-
Hey all,
Just wanted to throw some things out there. I first upgraded to 10.2 and rebooted, then I got the 824 update....which did revert me back to 10.1 p18. So tested and confirmed.
So make sure if your looking to upgrade, first start with 824 update than 10.2
-
This mechanism is a safety fallback in case upgrades went wrong to get back to a sane version all the time. This will probably change in the future to something more elegant, but it takes a proper use case and time to solve this.
-
I updated my x64/LibreSSL installation to 15.7.11, and then the upgrade to 10.2.
Same as before, a crash. Same Hyper-V 2012 R2 VM as always.
-
So just to be clear. If we "upgrade" to 10.2 we shouldn't "update" from within the firmware after the 10.2 "upgrade" or we will be "downgraded" back to 10.1?
-
Tom, can you grep the dmesg output for which disk is being assigned? Not that the newer 10.2 uses something else as the hard disk driver (Hyper-V specific maybe?)
-
So just to be clear. If we "upgrade" to 10.2 we shouldn't "update" from within the firmware after the 10.2 "upgrade" or we will be "downgraded" back to 10.1?
The latter: it will be downgraded back and reboot into safety. ;)
-
dmesg shows da0. The ada0 I have seen during setups, but not recently for some reason.
Always wondered why in a Hyper-V VM I'd have the choice of two disks, when I had only one VHD attached.
If for 10.2 it's changed to ada instead of da, that's fine. But I would have to do a full re-install I believe.
I can try and check it out this weekend with a new installation and see if I can choose ada0.
Will take screenshots then too.
-
If you flip /etc/fstab entries before the reboot after switching to 10.2, will that fix it?
Not a good fix, just trying to figure out if disks have indeed moved or are genuinely unreachable.
-
Will give that a go tonight.
-
Using a label or uuid could help when device name change.
-
Yup, but the good old bsdinstaller we use supports neither (yet). :)
-
I mentioned this to Fitch on IRC too, when I setup a FreeBSD 10 installation earlier this year, I did use the UUID as by Microsoft recommendations.
But as Fitch mentions, their bsdinstaller doesn't support this.
Will try to edit /etc/fstab tonight after the upgrade and before the reboot.
-
Done testing. Editing /dev/ada0 to /dev/da0 in /etc/fstab made it boot fine now.
But then the funkiness started.
WAN picked up a DHCP lease from my ISP just fine. LAN towards the box is fine too.
But DNS from my two DNS servers through the box to the internet is a no go.
The box also uses those two DNS servers for lookup, and setting the WAN interface to pick up ISP DNS servers using the DHCP lease made the box able to do lookups.
I looked in the System Logs in the Firewall section, and nothing is getting blocked coming from LAN to WAN.
Default rules are in place too, so everything from LAN is passed to WAN.
-
Not sure if this is the proper place been getting alot of constant IDS crashes. all saying the following.
Sep 6 00:22:20 configd.py: [0daa10b4-b6e2-4e2b-ac6b-cf20c6e5b88f] get suricata daemon status
Sep 6 00:22:20 configd.py: [ea761c06-aa4b-4b02-a69e-72460190be2f] request installable rules
Sep 5 23:22:47 kernel: re1: promiscuous mode disabled
Sep 5 23:22:47 kernel: re0: promiscuous mode disabled
Sep 5 23:22:47 kernel: pid 32781 (suricata), uid 0: exited on signal 11 (core dumped)
Sep 5 23:19:05 configd.py: [c87f1b6b-c33d-4cc3-97b5-844f2bc8a71e] query suricata alerts
Sep 5 23:19:05 configd.py: [96ec1983-3130-433f-a1e7-1830b03992b4] list available suricata alert logs
Sep 5 23:19:04 configd.py: [cb863a88-67e1-496a-b5c6-769245d6fef0] get suricata daemon status
Active Suricata definitions.
dshield
emerging-dns
emerging-dos
emerging-exploit
emerging-ftp
emerging-malware
emerging-mobile_malware
emerging-sql
emerging-telnet
emerging-tftp
emerging-trojan
emerging-worm
files
http-events
rbn-malvertisers
smtp-events
tor
I can maybe get 24 hours out of a run before the daemon crashes
-
Is upgrading to 10.2 after devel builds still useful or have you exhausted 10.2 testing? I noticed today going to 10.2 that it now read .obsolete. in this case should I be sticking with 10.1?
-
The .obsolete file contains entries that ought to be deleted after upgrading. This cleans up no longer needed files from the previous installation. Not to be confused with obsoleting of a particular version.
10.2 testing continues, I'll try to push the recent FreeBSD security and release engineering updates into the test version soon.
So far, we only have a couple of problems related to Hyper-V, as reported by weust.
-
Seems 10.2 is -RELEASE now, so stable, and I will build a VM using FreeBSD 10.2 and see whether that does work.
I would assume so (though assumption is the mother of all fuckups) as the release notes don't mention any weird stuff that might trigger OPNsense not the boot.
And by that I mean the FreeBSD part before OPNsense kicks in.
https://www.freebsd.org/releases/10.2R/relnotes.html#hardware-virtualization
https://svnweb.freebsd.org/base?view=revision&revision=283280
Won't be till the weekend, but testing should be quick.
-
should I manually go through the directories to delete them or is this an automated task of the installer?
-
no, opnsense-update knows what to do with the file :)
-
Hello,
Can someone give the version of the Intel igbt driver (gigabit Intel NIC driver for multiple chipsets including I210AT) used in the FreeBSD 10.2 version of Opnsense? Seems there is an unresolved hanging issue with 10.1 in which a watchdog timeout occurs (seems related to TSO) and it occurs (from Google searching) across platforms using FreeBSD 10.1 (pfsense, opnsense, FREENAS, etc).
The 10.1 driver seems to be 2.4.0 whereas Intel's latest (July of 2015) is 2.4.3.
I would be tempted to try the Opnsense 10.2 version if the driver is newer in hopes to solve the watchdog timeout issue on Intel NIC's.
Nevermind: Seems that this is still open and also occurs in version 10.2: https://forum.opnsense.org/index.php?topic=1319.0 . Seems the commit to fix this on the older Intel cards was just submitted (em) but not sure if the new stuff (igbt) will be fixed or not. Also not sure which version of FreeBSD it will appear in.
Sorry for the thread clutter... :(
-
I'm starting to think we'll probably skip 10.2 altogether. There is not much done in the networking area and 10.1 works really well. All the (network driver) goodness will be in FreeBSD 11 and I expect 10.3 will be lacking equally.