Dont need to lookup dependencies for the "cat" command.
Its the library "ld-linux-x86-64.so.2", the 64 bits version, what the pi-hole-FTL binary wants.
Could you post results for below ones ?
uname -r -m
dpkg --print-architecture
dpkg --print-foreign-architectures
dpkg -L libc6 | grep ld-linux
sudo find / -name *ld-linux*
apt-cache search ld-linux-x86-64.so.2
EDIT: Mind I altered the find command.
Sorry for the irrelevant tangent. Here are the results of the commands
Missed out an important one:
dpkg --print-architecture
Am not sure if you can run binaries intended for a 64 bit system on a 32 bit (i386) distro but dont think so.
What distro did you install and did you add that foreign architecture "amd64" and what for ?
Dont know if a 32 bit pi-hole-FTL version exists.
If its a fresh install, you could try re-install on the 64 bit version of that distro.
Maybe the @developers can shed some light ?
ok, thanks. Didn't know pi-hole was 64-bit only but more importantly I didn't know I had installed a 32-bit distro. I'll go back and get the right version of Stretch and try this all again.
Will report back the results shortly and confirm if this issue was tied to the wrong architecture.
Am not sure how that 64 bit binary got onto a 32 bit distro but maybe that foreign architecture "amd64" fooled the Pi-hole installer into believing it is a 64 bit system ???
Maybe it suffices to just remove that architecture and try re-install Pi-hole.
You can remove that "amd64" architecture with:
sudo dpkg --remove-architecture amd64
Or add it again with:
sudo dpkg --add-architecture amd64
I didnt say that and @Mcat12 just confirmed that a 32 bit version exists also.
Forget removing or adding amd64 architecture, it seems the installer decides on what system architecture is detected and doesnt look at distro architecture.
From the install script:
# Store architecture in a variable
machine=$(uname -m)
.
.
elif [[ "${machine}" == "x86_64" ]]; then
# 64bit
echo -e "${OVER} ${TICK} Detected x86_64 architecture"
# set the binary to be used
binary="pihole-FTL-linux-x86_64"
So the only fix left is try install the 64 bit distro version ... I think 
The installer script messes things up on my system (32bit). The script assumes a lot, while it simply should ask the user what they want. It currently blindly overwrites pihole-FTL with the wrong version.
I strongly disagree. Many users use Pi-hole as their first Raspberry Pi, sometimes even as their first Linux experiment. Even if we'd ask them which architecture they are running on, that might already be too much. The Pi-hole installer is constructed to make the installation as simple and straightforward as possible.
Please be more specific. Does that mean you are running a 32bit on 64bit capable hardware? If so, why? If not, what is the problem you are seeing?
I agree that it may be a bit of a stretch to cover it in the installer.
My setup is not really ordinary I guess:
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
I run Pi-hole on Xpenology in the Chroot environment, somehow some libraries are 32 bit forcing me to use the 32 bit FTL version.
Are you using a 64bit kernel? Maybe you can just install the missing 64bit ldd.
@llloydxmas & @bakman2 ,
FYI, we found solution to run the 64 bits pihole-FTL binary on a 32 bits distro if your running a 64 bits kernel:
Important bit is that "dpkg --print-foreign-architectures" is set for "amd64" and the repo in the "sources.list" file includes the "amd64" packages.
This is my output:
# dpkg --print-architecture
i386
# uname -m
x86_64
# dpkg --print-foreign-architectures
#
FYI my system uses an Intel Avoton.
I think the main problem is that the chroot environment was installed with 32-bit libraries as @DL6ER mentioned.
Not sure how to fix.
You can download the 32bit version (pihole-FTL-linux-x86_32) from here:
Then run
install -T -m 0755 /tmp/pihole-FTL-linux-x86_32 /usr/bin/pihole-FTL
(assuming you downloaded the file into /tmp)
Only disadvantage is that "pihole -up" to upgrade will install the 64 bits version again am I right ?
So got to remember everytime you upgrade Pi-hole, you need to manually pull the 32 bits binary from GitHub after and fire here up again.
Seems to be the same issue that I did encounter and did fix by manually installing the 64-bit library.
Is there a way to automatically detect such mix of architecture during the PiHole installation &/or update?
Relevant PR: