[CALL FOR TESTING] FreeBSD 10.2

[franco]

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

[JerTeske]

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

[franco]

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.

[weust]

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.

[Solaris17]

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?

[franco]

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?)

[franco]

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.

[weust]

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.

[franco]

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.

[weust]

Will give that a go tonight.

[domg]

Using a label or uuid could help when device name change.

[franco]

Yup, but the good old bsdinstaller we use supports neither (yet).

[weust]

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.

[weust]

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.

[Solaris17]

Not sure if this is the proper place been getting alot of constant IDS crashes. all saying the following.

Code: [Select]

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