Failed install on Raspberry pi 3/4 32bit

[chazragg]

as requested in #33 i have created a new ticket for this issue.

when using this role to install to a raspberry pi 3/3 on the "Ensure Debian Repo is present" step you get the following error.

{"changed": false, "msg": "apt cache update failed"}

running in debug mode produces the following.
The full traceback is: File "/tmp/ansible_apt_repository_payload_nycaw82d/ansible_apt_repository_payload.zip/ansible/modules/packaging/os/apt_repository.py", line 548, in main File "/usr/lib/python3/dist-packages/apt/cache.py", line 589, in update raise FetchFailedException(e) fatal: [192.168.0.200]: FAILED! => { "changed": false, "invocation": { "module_args": { "codename": null, "filename": "gluster", "install_python_apt": true, "mode": null, "repo": "deb [trusted=yes] https://download.gluster.org/pub/gluster/glusterfs/LATEST/Debian/buster/armhf/apt buster main", "state": "present", "update_cache": true, "validate_certs": true } }, "msg": "apt cache update failed" }

performing an apt update on the rpi manually provides no error and multiple other roles also update the cache. after doing some investigation i can see that in this step it adds the glusterFS repository and searches for the following.

https://download.gluster.org/pub/gluster/glusterfs/LATEST/Debian/buster/armhf/

but armhf does not exists and only builds for arm64 and amd 64.

this could be a side issue as ansible is reporting an apt update error but this is the only thing i could see wrong.

Hope this helps.

[stale]

This issue has been marked 'stale' due to lack of recent activity. If there is no further activity, the issue will be closed in another 30 days. Thank you for your contribution!

Please read this blog post to see the reasons why I mark issues as stale.

[geerlingguy]

It used to work (e.g. https://centos.pkgs.org/7/centos-armhfp/glusterfs-6.0-37.el7.armv7hl.rpm.html), so I wonder if at some point Gluster decided to drop 32-bit ARM support and only support 64-bit?

I know for myself, I'm usually running the 64-bit beta of Pi OS, or Ubuntu 20.04 for Pi 64-bit, so these issues don't always bite me.

[stale]

This issue is no longer marked for closure.

[EnochPrime]

I am running into the same issue with my RPi4 running Pi OS. Seems like a work-around repo would be to use the PPA.

[EnochPrime]

I looked into this further and, yes, apparently 32-bit was dropped a long time ago. Also is you are running arm64, unfortunately the packages beyond 7.5 are currently not available due to hardware issues.

#gluster/glusterfs#1301

[stale]

This issue has been marked 'stale' due to lack of recent activity. If there is no further activity, the issue will be closed in another 30 days. Thank you for your contribution!

Please read this blog post to see the reasons why I mark issues as stale.

[eyduh]

I ran into this issue on a home cluster spread across some amd64 hosts and some arm64 hosts, naturally the arm64 hosts failed due to this issue with the repos not containing arm64 binaries after 7 and the IP of the repo host being offline.

However, after installing the appropriate libraries it compiled & installed fine on DietPi 7 (debian buster based) on an Odroid HC4. I'm considering packaging it into a deb and setting it up on my Rpi4 as well but wanted to try the ansible playbook first.
How would I set the use apt variable on an architecture basis? Alternatively, how would I change the order of the checks? In other words, if clusterfs client & server are installed from "make install" instead of from apt how would I set up ansible to detect if a recent version is installed and skip the apt checks?

Edit: spoke too soon, ran
glusterfs --version and was greeted with

glusterfs: error while loading shared libraries: libglusterfs.so.0: cannot open shared object file: No such file or directory

[stale]

This issue is no longer marked for closure.

[eyduh]

Edit: spoke too soon, ran
glusterfs --version and was greeted with

Odd. Came back a few days later when I had time for this again and glusterfs --version returned a proper response (maybe due to a reboot?)

# glusterfs --version
glusterfs 10dev
Repository revision: git://git.gluster.org/glusterfs.git
Copyright (c) 2006-2016 Red Hat, Inc. <https://www.gluster.org/>
GlusterFS comes with ABSOLUTELY NO WARRANTY.
It is licensed to you under your choice of the GNU Lesser
General Public License, version 3 or any later version (LGPLv3
or later), or the GNU General Public License, version 2 (GPLv2),
in all cases as published by the Free Software Foundation.

Now the ansible playbook fails on task "Ensure debian repo is present" which doesnt work due to the aforementioned armhf/arm64 repo being poopy. Since it's only one node in my setup I'll just set it up manually for now but would be nice to have the "if installed, warn about missing repo but continue tasks" kind of behaviour. c:

[stale]

This issue has been marked 'stale' due to lack of recent activity. If there is no further activity, the issue will be closed in another 30 days. Thank you for your contribution!

Please read this blog post to see the reasons why I mark issues as stale.

[stale]

This issue has been closed due to inactivity. If you feel this is in error, please reopen the issue or file a new issue with the relevant details.