New install on Raspberry Pi OS on ESXi Virtual Machine fails to install correctly

Okay,

hash -d pihole-FTL

and then

which pihole-FTL
pi@raspberry:/usr/bin $ hash -d pihole-FTL
pi@raspberry:/usr/bin $ which pihole-FTL
/usr/bin/pihole-FTL

And one last try to pihole-FTL -vv

pi@raspberry:/usr/bin $ pihole-FTL -vv
-bash: /usr/bin/pihole-FTL: No such file or directory

I don't think I have any tricks left to throw at it...

@DL6ER is there any possibility output is coming from pihole-FTL?

I found a fix for this issue after dealing with the same setup using the Raspberry desktop OS on an esxi VM.

if you run uname -r -m and dpkg --print-architecture you will most likely get 4.19.0-12-amd64 x86_64 and i386 as discussed in this article:

A solution was to install the libc6:amd64 package manually using apt-get here:

I ran sudo apt install libc6:amd64 and did the pihole install script using bash and it worked without any issue.

2 Likes

Yes, this has fixed it.
I ran

sudo apt install libc6:amd64

and then

curl -sSL https://install.pi-hole.net | bash

and went through the install as normal and everything is working as expected.

It comes from the linker, but that already seems to have been clarified.

For which architecture is this ISO? Not for x86_64, right? Looking at this discussion, it very much looks like your virtualization is telling Pi-hole that it is an x86_64 device, however, the operating system isn't able to execute x86_64 code (you made that now possible by installing the amd64 version of libc6).

The ISO download claims it's for x86.
Here's where I got it from: https://www.raspberrypi.org/software/raspberry-pi-desktop/

The VM was setup to run Debian GNU/Linux 10 (64-bit). It's very possible that when those options are selected that it's virtualizing something that doesn't match up with the ISO out of the box?

I hate to admit that I don't know how to tell exactly what ESXi is doing behind the pretty GUI, but just slightly less than I hate pretending like I know more than I actually do.. especially on the internet.

I believed this was resolved with below ?

The software on that ISO is still 32 bits i386 same as the armhf architecture on Raspi's.

Ah yes x86 (not x86_64) will be 32 bit. This is also what @deHakkelaar.

Well, apparently not, he surely tried to install the latest version, however,

@rmurwin Could you tell us the output of the command below so we can look at fixing this in the future?

sudo dpkg --print-architecture

Thanks!

running sudo dpkg --print-architecture results in i386

And uname -m please?

running uname -m results in x86_64

Well, in this case, the 32 bit binary should have been selected. @DanSchaper do you see an issue with the logic I added in the referenced PR?

Looks like the logic is fine, can try using =~ instead of == for checking against i386 at pi-hole/automated install/basic-install.sh at 4a75566a3b4701d8d984e13d50c969bc97eb5553 · pi-hole/pi-hole · GitHub, I can do a quick diff patch or a test branch and have @rmurwin curl in that raw.githubusercontent.com that will be created for the branch?

dan@Viking-1:~$ bash -x b.sh
+ get_binary_name
+ local machine
++ uname -m
+ machine=x86_64
+ local 'str=Detecting architecture'
+ echo -ne '   Detecting architecture...'
   Detecting architecture...+ [[ x86_64 == \a\r\m* ]]
+ [[ x86_64 == *\a\a\r\c\h* ]]
+ [[ x86_64 == \p\p\c ]]
+ [[ x86_64 == \x\8\6\_\6\4 ]]
+ local dpkgarch
+ dpkgarch=i386
+ [[ i386 =~ i386 ]]
+ echo -e '   Detected 32bit (i686) architecture'
   Detected 32bit (i686) architecture
+ binary=pihole-FTL-linux-x86_32

That'd be awesome. Is there any benefit in using =~ here? I'm asking because a fix I do not understand doesn't really feel like a fix to me :wink:

It's a regex match instead of a straight string comparison. Without seeing the actual output from the string comparison I can't really say if it's an improvement or not but something is causing the comparison to fail.

The better test would be to set up a new VM and then run:

curl -sSL https://install.pi-hole.net -o /tmp/install.sh
sudo bash -x /tmp/install.sh

With the intent that we capture the actual comparison like:

+ [[ x86_64 == *\a\a\r\c\h* ]]
+ [[ x86_64 == \p\p\c ]]
+ [[ x86_64 == \x\8\6\_\6\4 ]]

I can set up a vm and do that if you tell me what to run