Upgrade fail

Started by temporal-agent, February 01, 2019, 01:00:10 AM

Previous topic - Next topic
Upgrading from 18.7.10_3 to 19.1 via GUI.
System halts at MOUNTROOT> prompt.
Not sure what to do next.

There is one extra update before 19.1. You should go to 18.7.10_4 and then to 19.1.

Is your system stuck there? Have you tried the old kernel? When you first boot, on the initial screen press the space bar to pause and then select option 5, which will switch to the old kernel.

I have a similar problem, but I'm not sure if they are related. I have a box with an old Athlon II X2 processor. It refuses to boot using the FreeBSD 11.2 kernel. I tried both from the HDD and from a 19.1 install DVD and the box does not boot.

The strange thing is that it will boot OK from a FreeBSD 11.2 install disk. I read about some issues with older processors with the upgrade from 11.1 to 11.2, but the workarounds given do not work for me, so I think I might need to get a new box to run OPNsense.

SecAficionado, try booting with the vm.pmap.pti tunable set to 0.

Updated our 18.7 to latest 18.7 before updating to 19.1! Stucked with boot loop on our firewall that is a HPE Microserver N54L...

Did a clean install of 18.7, updated it from the Update from console to latest 18.7 and then 19.1 with the same result!  :o ???

So the 19.1 is a no go on a Microserver N54L at this moment, dunno what's causing the boot loop of the server. :/

Running also OPNsense on a Microserver Gen8 at home, so will try this weekend to update it from the console to see if that works!

Same problems with an R415,

AMD cpu issue perhaps?

Quote from: lattera on February 01, 2019, 03:41:07 PM
SecAficionado, try booting with the vm.pmap.pti tunable set to 0.
Thanks @lattera! That fixed the issue!

It did not even occur to me that the Meltdown fix that had bricked a bunch of AMD Windows PCs might affect my OPNSense box!

@gh0st: your server has an AMD cpu, so this will likely fix your problem as well.

More info about the issue:
FreeBSD's speculative execution page: https://wiki.freebsd.org/SpeculativeExecutionVulnerabilities
AMD's statement: https://www.amd.com/en/corporate/security-updates

February 02, 2019, 12:11:56 AM #7 Last Edit: February 02, 2019, 12:28:33 AM by temporal-agent
Quote from: SecAficionado on February 01, 2019, 03:34:00 AM
There is one extra update before 19.1. You should go to 18.7.10_4 and then to 19.1.

Yea, it was 18.7.10_4 and not _3.

I was able to "rescue" the system from inside the 19.1 installer by loading the on-disk config.  I couldn't find a way to make the live system permanent. So I backed up the config (from the GUI) and did a fresh install.  This went fine until the reboot where it died before boot menu where it couldn't find the kernel.

I reverted to 18.7, loaded my config (which works despite being saved from 19.1), and it's up and running fine now.

Maybe it's because it's an i386 cpu...
QuoteVersions   OPNsense 18.7.10_4-i386
FreeBSD 11.1-RELEASE-p18
LibreSSL 2.7.5

sysctl -a | egrep -i 'hw.machine|hw.model|hw.ncpu'
hw.machine: i386
hw.model: Intel(R) Pentium(R) 4 CPU 3.00GHz
hw.ncpu: 2
hw.machine_arch: i386


dmesg | grep -i cpu
CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (3014.55-MHz 686-class CPU)
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
SMP: AP CPU #1 Launched!
cpu0: <ACPI CPU> on acpi0
cpu1: <ACPI CPU> on acpi0


Edit: It helps to SSH into the correct host...

Quote from: SecAficionado on February 01, 2019, 11:54:25 PM
Quote from: lattera on February 01, 2019, 03:41:07 PM
SecAficionado, try booting with the vm.pmap.pti tunable set to 0.
Thanks @lattera! That fixed the issue!

Awesome! Good to hear!

To give a little bit of background, FreeBSD implemented PTI, but created some detection logic to disable it for CPUs that don't technically need it. We at HardenedBSD feel that it's a really good security feature to keep enabled across-the-board, so we've disabled that detection logic and enabled it by default.

This means that some CPUs, especially older AMD CPUs, can have issues with the feature. For those edge cases, we instruct impacted users simply to disable PTI. I know it can cause some headaches, but I feel it's a good reminder to those with older CPUs to perhaps upgrade to newer CPUs that can take advantage of newer security features. :)

Sorry for the hassle, but I'm glad we found the issue. :)

Setting vm.pmap.pti tunable to 0 not helping me. After unlocking 19.1 and hit upgrade router boots normally, but version stays on 18.7.10_4.
My instance runs as VM on Proxmox 5.3-7. All 4 cores of i5-4570 are fully exposed to VM in 'host' mode.
Ask if some logs are needes.
Proxmox enthusiast @home, bare metal @work.

Will replace the N54L at work with another server tomorrow that has a Intel proc...

Quote from: Antaris on February 02, 2019, 09:57:40 AM
Setting vm.pmap.pti tunable to 0 not helping me. After unlocking 19.1 and hit upgrade router boots normally, but version stays on 18.7.10_4.
My instance runs as VM on Proxmox 5.3-7. All 4 cores of i5-4570 are fully exposed to VM in 'host' mode.
Ask if some logs are needes.

This should have been a new thread.

Try the following:

For OpenSSL:

# opnsense-update -fp -n "19.1.1\/latest"

Or LibreSSL:

# opnsense-update -fp -n "19.1.1\/libressl"

newsense, I know you're trying to help, but what you posted is incorrect. There is no "19.1.1/latest" and libressl variant...

https://forum.opnsense.org/index.php?topic=9521.msg51688#msg51688

Argh, I thought you need to specify the current major version number and patch level. That post came out before 19.1.1 if memory serves... Sorry about that.