rmurwin
December 3, 2020, 1:55am
37
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
rmurwin
December 3, 2020, 1:56am
39
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:
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.
A solution was to install the libc6:amd64 package manually using apt-get here:
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 w…
I ran sudo apt install libc6:amd64
and did the pihole install script using bash and it worked without any issue.
2 Likes
rmurwin
December 3, 2020, 12:29pm
42
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.
DL6ER
December 3, 2020, 8:01pm
43
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
).
rmurwin
December 3, 2020, 8:20pm
44
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 ?
pi-hole:development
← pi-hole:tweak/32bitOS_on_64bitCPU
opened 10:23AM - 24 Feb 18 UTC
**By submitting this pull request, I confirm the following:**
*please fill any… appropriate checkboxes, e.g: [X]*
- [x] I have read and understood the [contributors guide](https://github.com/pi-hole/pi-hole/blob/master/CONTRIBUTING.md), as well as this entire template.
- [x] I have made only one major change in my proposed changes.
- [x] I have commented my proposed changes within the code.
- [x] I have tested my proposed changes, and have included unit tests where possible.
- [x] I am willing to help maintain this change if there are issues with it later.
- [x] I give this submission freely and claim no ownership.
- [x] It is compatible with the [EUPL 1.2 license](https://opensource.org/licenses/EUPL-1.1)
- [x] I have squashed any insignificant commits. ([`git rebase`](http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html))
Please make sure you [Sign Off](https://github.com/pi-hole/pi-hole/wiki/How-to-signoff-your-commits.) all commits. Pi-hole enforces the [DCO](https://github.com/pi-hole/pi-hole/wiki/Contributing-to-the-project).
---
**What does this PR aim to accomplish?:**
Try to determine if the user is running a 32bit OS on a 64bit system. If so, download the 32bit binary as we cannot expect the 64bit libraries to be present.
Should fix #1998 and many others + some issues we saw on Discourse.
**How does this PR accomplish the above?:**
Try to detect architecture `dpkg` uses to install packages. This will only work on Debian-based systems, but not on Fedora, etc.
Unfortunately, I cannot really test this at the moment as droplets with 32bit OS return
```
$ uname -m
i686
```
(which already leads to downloading the 32 bit library)
---
* You must follow the template instructions. Failure to do so will result in your pull request being closed.
* Please respect that Pi-hole is developed by volunteers, who can only reply in their spare time.
The software on that ISO is still 32 bits i386
same as the armhf
architecture on Raspi's.
DL6ER
December 6, 2020, 7:55am
46
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!
rmurwin
December 7, 2020, 6:58pm
47
running sudo dpkg --print-architecture
results in i386
rmurwin
December 7, 2020, 9:19pm
49
running uname -m
results in x86_64
DL6ER
December 7, 2020, 10:53pm
50
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?
pi-hole:development
← pi-hole:tweak/32bitOS_on_64bitCPU
opened 10:23AM - 24 Feb 18 UTC
**By submitting this pull request, I confirm the following:**
*please fill any… appropriate checkboxes, e.g: [X]*
- [x] I have read and understood the [contributors guide](https://github.com/pi-hole/pi-hole/blob/master/CONTRIBUTING.md), as well as this entire template.
- [x] I have made only one major change in my proposed changes.
- [x] I have commented my proposed changes within the code.
- [x] I have tested my proposed changes, and have included unit tests where possible.
- [x] I am willing to help maintain this change if there are issues with it later.
- [x] I give this submission freely and claim no ownership.
- [x] It is compatible with the [EUPL 1.2 license](https://opensource.org/licenses/EUPL-1.1)
- [x] I have squashed any insignificant commits. ([`git rebase`](http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html))
Please make sure you [Sign Off](https://github.com/pi-hole/pi-hole/wiki/How-to-signoff-your-commits.) all commits. Pi-hole enforces the [DCO](https://github.com/pi-hole/pi-hole/wiki/Contributing-to-the-project).
---
**What does this PR aim to accomplish?:**
Try to determine if the user is running a 32bit OS on a 64bit system. If so, download the 32bit binary as we cannot expect the 64bit libraries to be present.
Should fix #1998 and many others + some issues we saw on Discourse.
**How does this PR accomplish the above?:**
Try to detect architecture `dpkg` uses to install packages. This will only work on Debian-based systems, but not on Fedora, etc.
Unfortunately, I cannot really test this at the moment as droplets with 32bit OS return
```
$ uname -m
i686
```
(which already leads to downloading the 32 bit library)
---
* You must follow the template instructions. Failure to do so will result in your pull request being closed.
* Please respect that Pi-hole is developed by volunteers, who can only reply in their spare time.
rmurwin:
i386
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
DL6ER
December 10, 2020, 10:56pm
53
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
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 ]]
rmurwin
December 11, 2020, 2:26am
55
I can set up a vm and do that if you tell me what to run