I followed exactly these intructions this morning on a native OS install that went along very smooth - no error messages.
The services just started fine from what I could follow from the installation process, and then with any of my web browers, I'm getting this picture
and this picture
The same after rebooting the deivces
I used as OS the latest Raspbian Stretch image of November 2017.
I've tried the installation of Pi-Hole on the lite and on a full OS image, however no luck, and am digging mysefll through this forums and other posts to figure out on how to troubleshoot further
OK, instead of using an Raspberry Pi device and flashing the Raspbian OS image every time, I went ahead and installed the Debian with Raspberry Pi Desktop OS on my PC, and am getting during the Bash Script installation, the following error message on the screen:
main: line 1870: /usr/bin/pihole-FTL: No such file or directory
And firing the script again, am getting the following output:
pihole-FTL: no process found
/opt/pihole/updatecheck.sh: line 56: /usr/bin/pihole-FTL: No such file or directory
Thus, not sure how robust the installation process is...
Just to make sure I can reproduce the same observations, I reinstalled the PC again with the Raspberry Pi Desktop OS from its DVD image file.
And then launched the PiHole installation script, and the installation went just fine confirming with the semi-last line "Pi-hole blocking is Enabled" and providing the last output line:
pihole-FTL: no process found /opt/pihole/updatecheck.sh: line 56: /usr/bin/pihole-FTL: No such file or directory
Firing the command "uname -a" provides the following output:
Following the exchanges on another post, further info can be provided.
Output of "strings /usr/bin/pihole-FTL | head":
/lib64/ld-linux-x86-64.so.2
Output of "dpkg -S ld-linux-x86-64.so.2":
dpkg-query: no path found matching pattern *ld-linux-x86-64.so.2*
Output of "stat ld-linux-x86-64.so.2":
stat: cannot stat 'ld-linux-x86-64.so.2': No such file or directory
Output of "whereis ld-linux-x86-64.so.2":
ld-linux-x86-64.so.2:
Thus, from above steps, to me it looks like a library is missing...
However, when firing the command "sudo apt-get install libc6" as suggested with another post, I'm getting the following output:
Reading package lists... Done
Building dependency tree
Reading state information... Done
libc6 is already the newest version (2.24-11+deb9u1).
0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
That is how to install the 32 bit "libc6" package.
If you run the 64 bit "pihole-FTL" binary (file /usr/bin/pihole-FTL) , on a 32 bit distro (dpkg --print-architecture), with a 64 bit kernel (uname -r) , on 64 bit capable hardware (uname -m), it will need the 64 bit version of that "libc6" package.
You could try to install the 64 bits version of that package with below one:
sudo apt install libc6:amd64
This will only work if the "amd64" packages are included in "/etc/apt/sources.list" file.
What do you have now in "/etc/apt/sources.list" ?
EDIT: Am curious now which distro is mixing 32 with 64 bits out of the box.
Which distro did you install ? Do you have a download link ?
The distribution is a native Debian Stretch 9.x Linux OS taylored for use with Raspberry Pi deskop. You can download its DVD Image file with this hypertext download link.
Your a patient man
I would have tried already
Check if that missing 64 bits library is installed now before go ahead and try install again:
whereis ld-linux-x86-64.so.2
stat /lib64/ld-linux-x86-64.so.2
But I wouldnt have installed this "Debian Stretch with Raspberry Pi Desktop" on an Intel/AMD machine except maybe if your a developer for Raspberry Pi things.
I would have installed the regular Debian stretch distro ... a pure 64 bits version.
And without a desktop if you dont need it.
I have reinstalled Raspberry Pi deskop (Debian Stretch Linux for the Intel platform) from its DVD Image on an Intel based platform recognised as x86_64 (output of "uname -r") and i386 (output of "dpkg --print-architecture") architecture.
Have updated the OS with the usual "sudo apt-get update ; sudo apt-get -y upgrade" commands and, right after, manually installed the libc6:amd64 package with the command "sudo apt install libc6:amd64".
After all that, I fired the PiHole installation process with the known commands, and everything just worked fine - the installation process ran smooth - no errors; the UNIX processes are all running fine upon installation completion including the intially failed pihole-FTL process.
I now have access to the admin page after its installation.
Sweet!
Nice you found a solution for this issue as there seems to be more people trying to install Pi-hole on a mixed 32/64 bits distro that is a bit hard to detect for the Pi-hole installer.
It threw me off completely at first.
I am still curious though why one would install a 32/64 bit distro instead of a pure 64 bits one?
The only reason I can think of is if your into developing for Raspberry Pi which has a 32 bits architecture (uname -m).
Or need to run very old software that only has binaries available for 32 bits.
You can test from a client PC now with the nslookup command:
nslookup pi.hole <PIHOLE_IP_ADDRESS>
If that works, configure your router to push the Pi-hole IP address as a DNS server to its clients through DHCP:
If settings lacking on your router to push DNS through DHCP, Pi-hole has a solution for that too:
Whenever changing DHCP settings, remember to renew the DHCP leases on the clients by either disconnecting & reconnecting them from network or reboot them!
When everything configured as it should, the nslookup command, run on a client PC, should also work now if you leave out the "<PIHOLE_IP_ADDRESS>" bit eg:
The only explanation I can find is indeed having a x86 platform to connect directly to the Raspberry Pi devices and do some development with them when hooked up on your PC.
The PiHole application is now working fine under the Raspberry Pi Desktop, and am using this kind of setup as a use case for teaching purposes.
This said, thank you for your support and hints provided sofar on this post.
