26.7.1_1 -> 26.7.2 Boot loop

[you]

I just updated an intel nic only device w/o any problem too. And yes: services widget looks nice now :D

[bluescreen154]

This is only true for the main mirror at the moment: if you want to force a reinstall use this:

# opnsense-update -fbkr 26.7.2

The realtek plugin should work again afterwards.  But still curious there was a second panic unrelated to realtek...


Cheers,
Franco

hi,

i did that and enabled the realtek plugin. box is booting but no ip adresses are given to the 2 realtek nics. even after adding new ip adresses via shell, they still remain empty and box is unreachable. any hints?

regards
ralf

[oldRaven]

I too had the boot loop and was able to disable an onboard Realtek (it was enabled but not in use).  I had removed the Realtek plugin before this attempt and still had the boot loop.  I've been using a dual Intel NIC as my primary card.  This did allow a successful boot; however, the interface names had changed and the IP changed.  A quick reconfiguration by adding the IP I had originally and deleting/reconfiguring the DHCP which had the wrong interface name got everything going.  Reviewing everything now to see if all else is OK...
Edit - Using Intel(R) PRO/1000 82576 Dual NIC

[lmoore]

There is no spin lock message in @axsdenied panic - probably because 'ifconfig' wasn't trying to bring up the interface.

opnsense-update -fbkr 26.7.2

Performed this update - it took quite a while to download.

Rebooted and then installed the os-realtek plugin and then rebooted again.

There is no kernel panic and nor does the Realtek plugin driver work.

Some observations with the Realtek plugin:

- During initialisation the Realtek interface (re0) link state change is not reported

Initializing..........done.
igb0: link state changed to UP
igb1: link state changed to UP
igb2: link state changed to UP
igb3: link state changed to UP
em0: link state changed to UP
Starting device manager...acpi_wmi0: <ACPI-WMI mapping> on acpi0

- I don't know what [egress only] really means.

setup igb3
setup igb1
setup re0 [egress only]
Network UPS Tools upsdrvctl - UPS driver controller 2.8.5 release

[Update] The Realtek plugin driver doesn't support 'Promiscuous' mode;
tcpdump -ni re0
tcpdump: WARNING: re0: That device doesn't support promiscuous mode
(BIOCPROMISC: Unknown error: 166225792)


For now, the os-realtek plugin is unusable.

[franco]

Does it work when doing the following?

# opnsense-revert -r 26.7.1 realtek-re-kmod


Cheers,
Franco

[lmoore]

# opnsense-revert -r 26.7.1 realtek-re-kmod

It appears for this to work the Realtek driver needs to already be installed. This is the NIC which connects me to the Internet, which means I won't have connectivity to the internet to revert the driver.

Can I perform an off-line installation of the driver?

[bluescreen154]

# opnsense-revert -r 26.7.1 realtek-re-kmod

this worked for me

[lmoore]

Code Select Expand

% sudo opnsense-revert -r 26.7.1 realtek-re-kmod
Package 'realtek-re-kmod' is not installed

I can't establish an Internet connection using the plugin. The command above was issued after removing the plugin and establishing a connection to the Internet using the FreeBSD version of the Realtek driver.

[lmoore]

Does it work when doing the following?

# opnsense-revert -r 26.7.1 realtek-re-kmod

Thanks Franco.

I've managed to revert the driver and I'm back up and running.

Just one other observation when I power off my system, I am getting this EFI related message on the serial console.

Code Select Expand

EFI RT fault general protection fault


Fatal trap 9: general protection fault while in kernel mode
cpuid = 0; apic id = 00
instruction pointer     = 0x20:0x1
stack pointer           = 0:0xfffffe00d34febc0
frame pointer           = 0:0xfffffe00d34fec30
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         = 16656 (halt)
rdi: 0000000000000000 rsi: 0000000000000000 rdx: 000000000000000f
rcx: 0000000000000000  r8: 0000000000000000  r9: 0000000000000000
rax: 00000000cbd4bb13 rbx: 0000000000000000 rbp: fffffe00d34fec30
r10: 0000000000000000 r11: 000000005f42535f r12: 0000000000000000
r13: 0000000000000002 r14: 0000000000004008 r15: fffff800011114a8
trap number             = 9
acpi0: Powering system off
Cheers,
Larry.

[franco]

I've never seen this one before.  Not sure if this is known upstream.

I'll replace the kmod packages in the 26.7.2 build later today so the plain install for the realtek plugin will work without pointing it to 26.7.1 specifically.

I'm glad we caught this quickly. Thanks to everyone helping out here. I'll try to let FreeBSD know.


Cheers,
Franco

[lmoore]

Not sure if this is known upstream.

There are a couple of articles, though not quite what I'm seeing:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=291193
https://forums.freebsd.org/threads/fatal-trap-9-general-protection-fault-while-in-kernel-mode.77530/

My test machine is fundamentally identical and I get the same message on it when it is shutdown and powered off. No message appears when a reboot is issued, i.e., the reboot is normal.

The latest BIOS for my machine is already installed.

[meyergru]

If a previous boot keeps the machine from crashing, I would still update the boot loader just for testing. AFAIU, the old one created memory corruptions.

[lmoore]

The boot loaders were updated on both machines after installing 26.7.1_1. However, my test machine was rolled back to an earlier snapshot of 26.1.11_1 and then rolled forward to the 26.7.1_1 prior to upgrading to 26.7.2.

The md5's of the boot loaders are the same as in /boot so it appears they are okay. I also took a back-up of the original files before updating and I can see the difference in size of the old and the new as well as the timestamps.

Retrospectively, the simplest approach to have dealt with this problem earlier would have been to change then line in /boot/loader.conf;

from

Code Select Expand

if_re_load="YES"
to

Code Select Expand

if_re_load="NO"
reboot and then perform the revert before re-enabling it.

[Patrick M. Hausen]

The boot loaders are not part of the ZFS root file system - neither for EFI nor for legacy boot. They reside in their own dedicated partitions. So rolling back to a previous snapshot does not affect the boot loaders in any way.

BTW: this is the reason why they must be updated manually for the time being. I hope FreeBSD will come up with a simple and mostly foolproof tool soon.