pihole-FTL i386 crashes upon upgrade from v5.18.4 to v6

[noyp22]

Versions

alix@debian-alix:~$ pihole -v
Could not find /etc/pihole/versions. Running update now.
[✗] The Pi-hole command requires root privileges, try:
sudo pihole updatechecker
/opt/pihole/version.sh: 25: .: cannot open /etc/pihole/versions: No such file

Platform

PC Engines Alix 2d13

[✓] Distro: Debian
[✓] Version: 11
[✓] dig return code: 0
[i] dig response: "Raspbian=11,12 Ubuntu=20,22,23,24 Debian=11,12 Fedora=40,41 CentOS=9"
[✓] Distro and version supported

Architecture: i586
CPU op-mode(s): 32-bit
Byte Order: Little Endian
Address sizes: 32 bits physical, 32 bits virtual
CPU(s): 1
On-line CPU(s) list: 0
Thread(s) per core: 1
Core(s) per socket: 1
Socket(s): 1
Vendor ID: AuthenticAMD
CPU family: 5
Model: 10
Model name: Geode(TM) Integrated Processor by AMD PCS
Stepping: 2
CPU MHz: 498.038
BogoMIPS: 996.07
L1d cache: 57 KiB
L1i cache: 57 KiB
L2 cache: 128 KiB

Expected behavior

Actual behavior / bug

from syslog

debian-alix kernel: [ 1422.473094] traps: pihole-FTL[12698] trap invalid opcode ip:80c15cd sp:bff2bdd0 error:0 in pihole-FTL[8049000+429000]

alix@debian-alix:~$ sudo file /usr/bin/pihole-FTL
/usr/bin/pihole-FTL: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, BuildID[sha1]=89ef2ba99a3919eba70bb8d8d8834d00290eb5d0, with debug_info, not stripped

Steps to reproduce

Steps to reproduce the behavior:

pihole -up

Debug Token

[- URL: https://tricorder.pi-hole.net/Hdvnw5z4/]

Screenshots

If applicable, add screenshots to help explain your problem.

Additional context

Add any other context about the problem here.

[DL6ER]

The invalid opcode is something we have not seen before on x86 binaries and it it also seems your Pi-hole has picked the correct binary. Which CPU do you have exactly (lscpu) ? Could you please also run an integrity check on FTL (pihole-FTL verify)?

[noyp22]

alix@debian-alix:~$ lscpu
Architecture: i586
CPU op-mode(s): 32-bit
Byte Order: Little Endian
Address sizes: 32 bits physical, 32 bits virtual
CPU(s): 1
On-line CPU(s) list: 0
Thread(s) per core: 1
Core(s) per socket: 1
Socket(s): 1
Vendor ID: AuthenticAMD
CPU family: 5
Model: 10
Model name: Geode(TM) Integrated Processor by AMD PCS
Stepping: 2
CPU MHz: 498.038
BogoMIPS: 996.07
L1d cache: 57 KiB
L1i cache: 57 KiB
L2 cache: 128 KiB
Vulnerability Gather data sampling: Not affected
Vulnerability Itlb multihit: Not affected
Vulnerability L1tf: Not affected
Vulnerability Mds: Not affected
Vulnerability Meltdown: Not affected
Vulnerability Mmio stale data: Not affected
Vulnerability Reg file data sampling: Not affected
Vulnerability Retbleed: Not affected
Vulnerability Spec rstack overflow: Not affected
Vulnerability Spec store bypass: Vulnerable
Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2: Mitigation; Retpolines, STIBP disabled, RSB filling, PBRSB-eIBRS Not affected
Vulnerability Srbds: Not affected
Vulnerability Tsx async abort: Not affected
Flags: fpu de pse tsc msr cx8 sep pge cmov clflush mmx mmxext 3dnowext 3dnow cpuid 3dnowprefetch vmmcall

alix@debian-alix:~$ pihole-FTL verify
Illegal instruction

syslog:
Feb 21 15:12:27 debian-alix kernel: [10511.982717] traps: pihole-FTL[16941] trap invalid opcode ip:80c15cd sp:bfd8c600 error:0 in pihole-FTL[8049000+429000]

[noyp22]

any idea how to revert back to v5.18.4 for the mean time

[DL6ER]

Reverting is, unfortunately, not really possible, that's why we asked in the release notes and the blog post to make a backup of the existing installation first. Your config files are stored in a separate directory in /etc/pihole so they are not lost. However, as you are the only one I have seen so far experiencing this, I have not much hope we'd be able to fix this without your help. I don't really see why this is happening here and I am surprised your lscpu does not provide a specific CPU model. Would sudo lshw -c cpu tell anything more?

But I found this which seems related: https://gitlab.alpinelinux.org/alpine/tsc/-/issues/35#note_238502

So basically your CPU is considered too old by the underlying Alpine system as it does not have SSE2 support. I will check if there is an exception we could make for the x86_32 build.

[DL6ER]

First experiments with -mno-sse suggest that the system-provided libraries still use SSE2 so it seems we - unfortunately - cannot make this work for you on this machine you are using due to this Alpine decision :-( Sorry for not having better news.

[noyp22]

Reverting is, unfortunately, not really possible, that's why we asked in the release notes and the blog post to make a backup of the existing installation first. Your config files are stored in a separate directory in /etc/pihole so they are not lost. However, as you are the only one I have seen so far experiencing this, I have not much hope we'd be able to fix this without your help. I don't really see why this is happening here and I am surprised your lscpu does not provide a specific CPU model. Would sudo lshw -c cpu tell anything more?

But I found this which seems related: https://gitlab.alpinelinux.org/alpine/tsc/-/issues/35#note_238502

So basically your CPU is considered too old by the underlying Alpine system as it does not have SSE2 support. I will check if there is an exception we could make for the x86_32 build.

alix@debian-alix:~$ sudo lshw -c cpu
*-cpu
product: Geode(TM) Integrated Processor by AMD PCS
vendor: Advanced Micro Devices [AMD]
physical id: 1
bus info: cpu@0
version: 5.10.2
size: 500MHz
width: 32 bits
capabilities: fpu fpu_exception wp de pse tsc msr cx8 sep pge cmov clflush mmx mmxext 3dnowext 3dnow cpuid 3dnowprefetch vmmcall

[noyp22]

First experiments with -mno-sse suggest that the system-provided libraries still use SSE2 so it seems we - unfortunately - cannot make this work for you on this machine you are using due to this Alpine decision :-( Sorry for not having better news.

Does SSE2 just got introduced in v6? Pihole V5.18.4 i386 works on my alix2d3d lx800 geode cpu.

[PromoFaux]

This may not be a helpful suggestion, but want to suggest it anyway!

Does your system support docker? Our docker image supports linux/386 in theory, I've never tried it - but I've never heard that it doesn't work...

[DL6ER]

Does SSE2 just got introduced in v6?

Yes, because Pi-hole v6.0 switched the extremely difficult to maintain CI infrastructure to Alpine which enforces SSE2 for all x86 platforms.