Messages

Just took the time to update to the latest release (15.1.9.1), now it works wonderfully well but I did not test it with 15.1.9... according to the changelog for the 15.1.9.1 release  it should work as well under 15.1.9 :-)

Maybe I am guessing wrong but...  on a firewall you are not supposed to install nothing absolutely anything but the absolute minimalistic mandatory software to route/filter/audit and eventually manage from the inside and nothing else. Extra services should be located on a dedicated and separate machine... 

Well indeed it was for "I install, I set the DNS then I upgrade" but yes I agree it is a bit unnecessary because I can manually edit /etc/resolv.conf from the shell then run an update after a fresh install. The interest is quite limited in fact...   :o

Confirmed, the installation went fine at 1G. Thank you franco! :)  I would suspect something that reserves RAM or something that uses more RAM (file decompression ? Archive size ?) at first glance. Has the kernel configuration changed between versions?

Would it be possible to specify the DNS servers from the console menu? At worst we can open a shell and edit /etc/resolv.conf.

I use OPNsense-15.1.9-cdrom-amd64.iso, I will be able to test it on a real machine not a VM. Will also try a compete reboot of my own host in case of. Using OPNsense-15.1.8-cdrom-amd64.iso brings absolutely no troubles.

Seems the exact explanation, I tried twice with the console updater and everything went as intended and opnsense is correctly upgraded including kernel. Will try again through the Web interface to see if I can reproduce this.  ???

Hum I did a fresh install again and updated to 15.1.9 (15.1.9.3505b0423) issue seems to have gone (glitch somewhere when I did the update ?). Let's close this issue now, if I can pinpoint an exact condition that trigger the bug I will document it here. :)

Yes the checksum is correct. This is the message I have in the BSD Installer log with no more details, is there a way to have access to a shell? I could try by hand and see what happens.

Steps to reproduce:  create a VirtualBox  machine VM with 512 MB of RAM and 10 GB of hard disk, try to install opnsense.

For the record, here is how I test opnsense: two virtual machines. Each has a 10GB HDD, 512MB of memory and 3 vnics configured in virtio:
- vnic0 is the WAN side and is set as a "bridge" interface over a physical Ethernet interface
- vnic1 is the LAN side and is set as an "internal network" (name "net1")
- vnic1 is the OPT1 interface and is set as an "internal network" (name "net2"), this is the interface used for pfsync

Really important: enable the promiscuous mode on vnic0 and vnic1 else you won't be able to use a VIP failover through CARP.

I set a minimalistic network configuration on the LAN interface, then from a third VM that shares the virtual network "net1", I configure each my opnvpn nodes.

The installation ends in the middle with an error 1 at around 32% :

/usr/local/bin/cpdup -vvv -I -o /usr/include /mnt/usr/include

FAILED with a return code of 1

Trying to skip but I get the same error for the rest...

Perfectly reproducible inside VirtualBox with settings for a FreeBSD machine.

Fresh install using 1.5.8 boot media + update to 1.5.9 = issue still present :(

Well, perfectly normal for something "young" to have angles to be polished. It will improve over time, thank you for your good work and continuous efforts :)

Is it supposed to be fixed in 15.1.8.4? I did a fresh install then a direct update to 15.1.8.4 and the kernel panics as soon as the second CARP VIP is applied...

The only advantage is rolling back unsuccessful upgrades. Other than that (which shouldn't happen anyway  ;)) there's no other reason to do it.

Not only unsuccessful upgrades but it is the sysadmin insurance policy in case of a regression or any serious issue would happen. Rebooting and rolling back in seconds can avoid extremely painful re-installation and  downtimes. The cost to pay in return is more memory  but any machine nowadays has several gigabytes of memory.