Hello,
during every upgrade I see several segmentation faults like in this extract:
[39/104] Installing brotli-1.1.0,1...
[39/104] Extracting brotli-1.1.0,1: .......... done
Segmentation fault
[40/104] Upgrading nspr from 4.35 to 4.36...
[40/104] Extracting nspr-4.36: .......... done
Segmentation fault
[41/104] Upgrading py311-numexpr from 2.10.1 to 2.10.2...
[41/104] Extracting py311-numexpr-2.10.2: .......... done
[42/104] Upgrading libltdl from 2.4.7 to 2.5.4...
[42/104] Extracting libltdl-2.5.4: .......... done
Segmentation fault
[43/104] Upgrading oniguruma from 6.9.9 to 6.9.10...
[43/104] Extracting oniguruma-6.9.10: .......... done
Segmentation fault
[44/104] Upgrading php82-session from 8.2.23 to 8.2.27...
[44/104] Extracting php82-session-8.2.27: .......... done
Should I be worried? Maybe not related but during upgrade to the last 24.x version the upgrade hung during this phase. Subsequent upgrades finished though.
> Should I be worried?
Yes, check dmesg output.
Cheers,
Franco
pid 86448 (ld-elf32.so.1), jid 0, uid 0: exited on signal 11 (no core dump - bad address)
pid 98965 (ld-elf32.so.1), jid 0, uid 0: exited on signal 11 (no core dump - bad address)
pid 12770 (ld-elf32.so.1), jid 0, uid 0: exited on signal 11 (no core dump - bad address)
pid 22219 (ld-elf32.so.1), jid 0, uid 0: exited on signal 11 (no core dump - bad address)
pid 31720 (ld-elf32.so.1), jid 0, uid 0: exited on signal 11 (no core dump - bad address)
pid 38510 (ld-elf32.so.1), jid 0, uid 0: exited on signal 11 (no core dump - bad address)
pid 62016 (ld-elf32.so.1), jid 0, uid 0: exited on signal 11 (no core dump - bad address)
pid 75000 (ld-elf32.so.1), jid 0, uid 0: exited on signal 11 (no core dump - bad address)
pid 88570 (ld-elf32.so.1), jid 0, uid 0: exited on signal 11 (no core dump - bad address)
pid 97221 (ld-elf32.so.1), jid 0, uid 0: exited on signal 11 (no core dump - bad address)
pid 7282 (ld-elf32.so.1), jid 0, uid 0: exited on signal 11 (no core dump - bad address)
pid 17994 (ld-elf32.so.1), jid 0, uid 0: exited on signal 11 (no core dump - bad address)
pid 32113 (ld-elf32.so.1), jid 0, uid 0: exited on signal 11 (no core dump - bad address)
pid 31038 (pkg-static), jid 0, uid 0, was killed: failed to reclaim memory
pid 8123 (ld-elf32.so.1), jid 0, uid 0: exited on signal 11 (no core dump - bad address)
pid 16784 (ld-elf32.so.1), jid 0, uid 0: exited on signal 11 (no core dump - bad address)
pid 36473 (ld-elf32.so.1), jid 0, uid 0: exited on signal 11 (no core dump - bad address)
pid 91092 (pkg-static), jid 0, uid 0, was killed: failed to reclaim memory
Run memtest, check temperatures, check power supply ... almost certainly hardware related issues.
If you are running a fairly modern CPU did you install the microcode update plugin matching your architecture (AMD or Intel)?
> was killed: failed to reclaim memory
Looks like RAM was depleted and/or SWAP exhausted.
Basically what above was said + please provide what HW config do you have?
Regards,
S.
It's a VM. I do have plugin installed, but
CPU microcode: no matching update found
CPU: AMD EPYC 7571 (2199.99-MHz K8-class CPU)
Will try with more RAM.
You don't need the microcode in the VM.
Cheers,
Franco
I added 1GB RAM and removed the microcode plugin. During removal again Segmentation fault and dmesg:
pid 61978 (ld-elf32.so.1), jid 0, uid 0: exited on signal 11 (no core dump - bad address)
So this is a VM? Would have helped if you had stated that in the first post.
Did you install the current microcode update on the hypervisor host? What hypervisor are you using?
Sorry, I do not have control over the hypervisor. It's a cloud VM.
Then open a support ticket with the cloud vendor. Obviously at least with the current settings they are not 100% compatible with FreeBSD.
How much RAM does it have now, maybe that's a better way to start?
Now it has 2GB, Lobby dashboard says 31% utilization.
The installer minimum requirement is 3 GB (although it can be ignored at one's own peril). 4 GB doesn't hurt, especially if you're doing something with it after installation.
Cheers,
Franco
OK, I switched VM from AMD EPYC to Intel Xeon with 4GB RAM and tried installing some small plugin (microcode-intel):
Number of packages to be installed: 6
The process will require 23 MiB more space.
[1/6] Installing pciids-20250309...
[1/6] Extracting pciids-20250309: ..... done
[2/6] Installing cpu-microcode-rc-1.0_2...
[2/6] Extracting cpu-microcode-rc-1.0_2: .... done
[3/6] Installing libpci-3.13.0...
[3/6] Extracting libpci-3.13.0: .......... done
Segmentation fault
[4/6] Installing x86info-1.31.s03_1...
[4/6] Extracting x86info-1.31.s03_1: ....... done
[5/6] Installing cpu-microcode-intel-20250211...
[5/6] Extracting cpu-microcode-intel-20250211: .......... done
[6/6] Installing os-cpu-microcode-intel-1.1...
[6/6] Extracting os-cpu-microcode-intel-1.1: .. done
Reloading firmware configuration
Ignoring invalid metadata: /usr/local/opnsense/version/opnsense
Writing firmware settings: FreeBSD OPNsense
Writing trust files...done.
Then uninstalled:
Number of packages to be removed: 5
The operation will free 23 MiB.
[1/5] Deinstalling x86info-1.31.s03_1...
[1/5] Deleting files for x86info-1.31.s03_1: ....... done
[2/5] Deinstalling libpci-3.13.0...
[2/5] Deleting files for libpci-3.13.0: .......... done
Segmentation fault
[3/5] Deinstalling cpu-microcode-intel-20250211...
[3/5] Deleting files for cpu-microcode-intel-20250211: .......... done
[4/5] Deinstalling pciids-20250309...
[4/5] Deleting files for pciids-20250309: ..... done
[5/5] Deinstalling cpu-microcode-rc-1.0_2...
[5/5] Deleting files for cpu-microcode-rc-1.0_2: .... done
***DONE***
Patrick was suggesting the VM is wonky and I tend to agree because none of this makes sense:
> Ignoring invalid metadata: /usr/local/opnsense/version/opnsense
Cheers,
Franco
The file contains just
18.7.1_3-445ae2139
Quote from: zemanek on April 24, 2025, 02:34:59 PMOK, I switched VM from AMD EPYC to Intel Xeon with 4GB RAM and tried installing some small plugin (microcode-intel):
You cannot perform a microcode update from inside a VM. If a microcode update is necessary it must be performed in the hypervisor host.
If your cloud provider is worth anything the probably have all of this in place. I made this suggestion (microcode update) initially because I assumed you were running on bare hardware.
So: what hypervisor is the provider using? KVM? Can you set the machine type to "q35" and the CPU type to "host"?
QuoteSo: what hypervisor is the provider using? KVM? Can you set the machine type to "q35" and the CPU type to "host"?
I don't know, I have no access to the hypervisor.
Anyway, I don't have any issues with these instances while they are running (VPN stable, ha-proxy working, ...) - well, for
NOW -, just the upgrade/plugin installation is suspicious.
Quote from: zemanek on April 24, 2025, 02:42:42 PMThe file contains just
18.7.1_3-445ae2139
Ok, that looks like a remnant that wasn't deleted in 2018 then.