[CALL FOR TESTING] FreeBSD 11.1, newer Realtek vendor driver and more

[interfaSys]

Found this in the logs today:

Code: [Select]

Fatal trap 12: page fault while in kernel mode
cpuid = 3; apic id = 06
fault virtual address = 0xc
fault code = supervisor read data, page not present
instruction pointer = 0x20:0xffffffff8070b1b4
stack pointer         = 0x28:0xfffffe0232213280
frame pointer         = 0x28:0xfffffe02322132a0
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 31124 (W#01-re0)
version.txt06000016713203656554  7630 ustarrootwheelFreeBSD 11.1-RELEASE-p2 #0 c967ed374(master): Tue Oct 17 20:39:21 CEST 2017
    root@sensey64:/usr/obj/usr/src/sys/SMP
Must be from when Suricata was enabled.

Full crash dump is herE:
https://paste.ubuntu.com/26014885/

[Lumpy]

Today it's showing 17.7.8 is newer than 18.1_b? Anything I've missed?

[phoenix]

Today it's showing 17.7.8 is newer than 18.1_b? Anything I've missed?

No, I'm guessing it's because you've updated all the packages apart from the kernel. I've just done the same upgrade and, obviously, it's showing the same thing.

[franco]

On opnsense-devel, there is an improvement that will show out of sync kernel and base sets. Any mismatch is shown there, 17.7.1 before, now 17.7.8, because that is our current release. That was the reason for "opnsense-update -L" and preventing the firmware to go back to its know good version.

You can either "opnsense-update -U" and go back to the latest FreeBSD 11.0 system or stay on 11.1, depending on your wariness for the two kernel issues that FreeBSD published (see our release notes).


Cheers,
Franco

[Lumpy]

I think I've got a problem with understanding what excatly you mean. I used

# opnsense-update -bkgr 18.1.b -n "snapshots\/beta"
# opnsense-update -L
# opnsense-update -t opnsense-devel
# /usr/local/etc/rc.reboot

I'm on "OPNsense 18.1.a_364-amd64" now, if I check for updates via the webinterafce I get two updates (see attachment). Is this the expected behaviour?

[phoenix]

What does it do/show if you run the following command:

Code: [Select]

opnsense-update -bkgr 18.1.b -n "snapshots\/beta"

[Lumpy]

Code: [Select]

Kernel locked at 18.1.b-amd64, skipping.
Base locked at 18.1.b-amd64, skipping.
Your system is up to date.

[phoenix]

There you go, that confirms that you're on the version you expect to be on.

[Lumpy]

Thank you Got a bit irritated though because I thought I've blocked the downgrade correctly. I didn't know that it won't work for the webinterafce.

[interfaSys]

I'm running the same system with 4GB of ram and did not experience any reboots.

Which BIOS are you running?

[Ren]

I'm running the same system with 4GB of ram and did not experience any reboots.

Which BIOS are you running?

The latest BIOS which is Version 2K170307
Link https://www.zotac.com/us/files/download/by_product?p_nid=501278&driver_type=238&os=All

[Julien]

I think I've got a problem with understanding what excatly you mean. I used

# opnsense-update -bkgr 18.1.b -n "snapshots\/beta"
# opnsense-update -L
# opnsense-update -t opnsense-devel
# /usr/local/etc/rc.reboot

I'm on "OPNsense 18.1.a_364-amd64" now, if I check for updates via the webinterafce I get two updates (see attachment). Is this the expected behaviour?

Yes, you are running opnsense-devel and I added kernel/base support there. But you can't install the 17.7.8 kernel and base because you locked them to stay at 18.1-BETA with "opnsense-update -L" so everything is as it should be.

[Lumpy]

And what should be done to upgrade to the neweset revision auf 18.1b? Which command should I use?

[franco]

Easy, there is no "neweset revision of 18.1.b". The next release will be 18.1-RC1.


Cheers,
Franco

[guywyers]

Hey guys,

Just started configuring OPNsense on a new hardware config and run into the problem documented here: https://forums.freebsd.org/threads/59627
It's not life threatening but annoying, because it means that every time you do a shutdown, the system hangs in the last phase of the power-off and requires a physical power-off/power-on cycle to get back in the normal state.
This is definitely a pain if you do reboots as a consequence of configuration changes.
As explained in the link above, the FreeBSD workaround is to use  shutdown -r now and they also mention that the problem is fixed in FreeBSD 11.1.

So, seeing that this beta contains FreeBSD 11.1, I installed it and indeed the problem is fixed. Just wanted to bring it up in case other people run in to this.

Cheers.