Messages

Ok, I guess I will reinstall.  ::) >:(

Good day,

After upgrading 24.1.10_8 via the UI to 24.7 my firewall will not complete a full startup. I am getting the above subject line output when the system is starting up and then a "Enter full pathname of shell or RETURN for /bin/sh:". Typically this /bin/sh appears when "Launching the init system". Sometimes a "Bus error (core dumped)" follows the php core dump.

This was done on my secondary firewall. The primary is still running 24.1.10_8.

Tried to perform a "opnsense-update" from the command line but receive a "Mirror read failed" most likely due to the system not getting the proper configuration.

Any clues, except a reinstall, on what might be wrong?

In using the DHCP service on OPNsesne, when I was spinning up a Nexus v9000 I was getting a message that the lease time was under 3600 which it was not accepting.

Upon research using the packet capture diagnostics, I noticed the dhcp service was, in fact, handing out the 600 second value under option 51 - Attached snip (dhcp-offer.png) and the DHCP Discover package was asking for 538705920 seconds - Attached snip (dhcp-discover.png)

After many retries (about 180 seconds after the initial discover) the correct dhcp lease is offered to the devices.

Everything is defaulted to 7200 and 86400 and the /var/dhcpd/etc/dhcpd.conf file shows those same values as the default and in the pools.

I spun up a quick dhcp-server (version 4.3.6) under CentOS 8 and copied the above dhcpd.conf to the /etc/dhcpd directory and it served out the correct lease times to the devices.

Currently using OPNsense 20.7.4-amd64 with LibreSSL-3.1.4 and the packages shows a isc-dhcp44-server version of 4.4.2_1.

Hi,

I am running OPNSense 19.1.x on Proxmox VE 5.4-x without issues...but I am using Intel-based processors on the hosts. Possible you can screenshot the Hardware and Options and post them.

I have a variety of setups using SeaBIOS/OVMF, SCSI/VirtiIO but all use the Para Virt for network. I have used E1000 but opted for the VirtIO (Paravirt) network adapter.

Yesterday, I also booted a Bare Metal Dell Optiplex 9020 using the HBSD-11-2019-03-26 ISO CD and was successful with the boot. I did a F12 for the boot menu and selected a UEFI boot from the CD.

This machine has a Intel Core i5-4680 @ 3.4GHz with 8Gb RAM. Firmware is at A24, 2018-10-24.

Also, had a successful boot with HBSD-11-2019-03-26 ISO CD on a Dell Latitude E5540. Intel Core i5-4310U @ 2.00GHz and 4Gb RAM. Firmware is A23, 2018-10-08.

-Waz

Screenshots attached.

Can you post a screenshot of the panic?

I apologize, this does not effect 9.1.4 at this time. I was just trying to use the original 9.1 upgrade and ISO to see if a new version of UEFI would fix the issue.

Sorry for the confusion but if you still need it is 9.1-netmap version ok?

-Waz

[Are OVMF releases fully UEFI compliant?]

Tired a new OVMF Firmware on the Proxmox or QEMU/KVM to see if that might fix the kernel panics and it did NOT. I had high hopes that the panics might have been because of old OVMF firmware (UEFI).

The project is based at https://github.com/tianocore/tianocore.github.io/wiki/edk-ii and by https://www.tianocore.org.

Actual builds are based at https://www.kraxel.org/repos/  You can extract the running code on any RPM service and replace the OVMF_CODE.fd and OVMF_VARS.fd with the OVMF_CODE-pure-efi.fd and OVMF_VARS-pure-efi.fd to just have the newest code. Mine was dated on Nov 2016. The new code did give me the ability to PXE boot via HTTP which was a big bonus for me.

One thing note with the issue at hand from the FAQ...
https://github.com/tianocore/tianocore.github.io/wiki/OVMF-FAQ#are-ovmf-releases-fully-uefi-compliant
Are OVMF releases fully UEFI compliant?

While the goal is to be as fully UEFI compliant as possible, you should not assume that an OVMF release is fully UEFI compliant unless the particular release states full compliance.

For virtual machines, there are some challenging areas in achieving full UEFI compliance. For example, UEFI 'non-volatile' variables may be difficult to fully support in some virtual machine environments if a flash memory device is not emulated.

This could be an issue with the previous change to the kernel and VM based UEFI.

Hope this helps.

-Waz

Oh, I posted this in the wrong thread, see below.

@bimmeldriver yes please, installer may hang but CTRL+C should work around it ok.

So this is the preliminary amd64 ISO for 19.1.4. It can be used in production and upgrades normally...

https://pkg.opnsense.org/FreeBSD:11:amd64/snapshots/OPNsense-19.1.4-OpenSSL-dvd-amd64.iso.bz2

All images, checksums and the announcement follow next week when we will have wrapped up testing image integrity for all other images (it takes about 2 days in total to do that).


Cheers,
Franco

Franco/Lattera,

I will dedicate a few VM's on my side to test upgrades and installs for 18.7 to 19.1 and 19.1 to 19.7 on the QEMU/KVM platform. Willing to help out as much as I can.

Let me know if the upgrade images are ready for 18.7 to 19.1.4 and I will test that also.

Not sure I have any "baremetal" equipment to use in testing except some old Dell's.

Thanks again.

-Waz

19.1.4 will be out tomorrow... can publish a test image the day after. Official images next week...


Cheers,
Franco

Upgraded to 19.1.4 on a BIOS and UEFI firmware boot without issues.

Great job and thanks again, OPNsense Team.

-Waz

Good, thank you for testing this so quickly. The core team discussed this internally and we have an accelerated plan of action for 19.1.4 next week:

1. Release the bad commit revert in a new kernel to restore the previous behaviour for everyone.
2. Change the upgrade paths to the new 19.1.4 for the 18.7 major upgrades one or two days after the 19.1.4 release.
3. Release new images based on 19.1.4 in the following week.
4. Rework the bad patch further to make it work for everyone and release it in a subsequent 19.1.x update together with the Netmap rework. This will require new test image runs with user participation. The time frame for this is very roughly April/May.

All further confirmations or new problem reports arising from the test image are welcome.

I hope this episode shows that we don't always get it 100% right but with a reasonable amount of patience and a level head we can move past almost anything together. :)


Cheers,
Franco

You tell me where the ISO's are or what to use to update for testing and I will test them on my VM's...well the best I can. I am using Proxmox VE 5.3 which is KVM/QEMU based on Debian distro with modified Ubunta LTS kernel. Also running ZFS over iSCSI to FreeNAS if you need something tested there.

I have two VM's in a HA configuration...one with UEFI and the other is BIOS with LibrsSSL, IPS and VIRTIO enabled.

I have two other VM's waiting to install from ISO with UEFI and BIOS.

-WAZ

Here's an ISO snapshot based on the following commit: https://github.com/opnsense/src/commit/060d54597

https://pkg.opnsense.org/FreeBSD:11:amd64/snapshots/OPNsense-201903080927-OpenSSL-dvd-amd64.iso.bz2

All feedback is welcome. Other types of images can be requested if needed. The image is for testing, we don't recommend production use just yet.


Thank you,
Franco

Downloading it now. Will let you know in a few minutes.

;D Success  ;D

ISO image booted without issues.

Clean install and a boot from EFI firmware to HDD without issues.  ;D

Well done team!!!

- Waz

Here's an ISO snapshot based on the following commit: https://github.com/opnsense/src/commit/060d54597

https://pkg.opnsense.org/FreeBSD:11:amd64/snapshots/OPNsense-201903080927-OpenSSL-dvd-amd64.iso.bz2

All feedback is welcome. Other types of images can be requested if needed. The image is for testing, we don't recommend production use just yet.


Thank you,
Franco

Downloading it now. Will let you know in a few minutes.

lattera,

Booted the ISO and received the panic on Proxmox VE.

Copied the kernel from your tarball from the "other" thread and it worked without issues.

Thanks for your continuous work.

Kev a.k.a. TheGrandWazoo

Hi,

I've spend more than a day trying to replicate the issue and tracking it's origin, since it doesn't occur on all EUFI boot systems.
Virtualbox for example boots without issues in UEFI mode, on Parallels (osx) I was able to find the crash as well .

Code Select Expand


fpuinit_bsp1 () at /usr/src/sys/amd64/amd64/fpu.c:241
fpuinit () at /usr/src/sys/amd64/amd64/fpu.c:277
0xffffffff810adb3b in hammer_time (modulep=<optimized out>, physfree=<optimized out>) at /usr/src/sys/amd64/amd64/machdep.c:1801
0xffffffff80316024 in btext () at /usr/src/sys/amd64/amd64/locore.S:79


Let me make one thing very clear, none of our systems suffer from this issue, a lot of people where actively involved during the beta stages up to 19.1 using all kinds of hardware.

I've seen a couple of people complaining, nagging, not being to **any** help to anyone.
I understand you have an issue, we all do, but... there are always alternatives, using other types of setups, being involved earlier and actively helping improving the system.
Don't forget, if your setup fails and you have done nothing to prevent that from happening, it's still your issue.... nobody got paid to solve it for you.

The patch [1] available might not be the final fix, nor will it fix all issues in the world, but it looks promising.

I would like to thank Franco, Shawn and anybody involved in actually pinning this issue down.

A kernel with debug options enabled is available on our website [2], but if Franco has some time available he can probably move it to a better spot, maybe build some iso with kernel.


Best regards,

Ad

• https://github.com/HardenedBSD/hardenedBSD-stable/commit/77a10c68ac3bf9cd0da50bd537dab858462c07f7
• https://pkg.opnsense.org/FreeBSD:11:amd64/snapshots/sets/kernel-19.7.a_25-amd64.txz

UPDATE: I copied the 19.7 kernel mentioned above in the #2 link to the /boot/kernel/kernel of the 19.1.2 install (well mine it 19.1-netmap) and all is well in the world. Boots with NO issues with EFI or BIOS firmware.

Thank you guys. Let me know if I can continue to help.

Kev