nextcloudpi
nextcloudpi copied to clipboard
Docker build of older version on armhf always installs latest nc
When building the docker image for armhf
e.g. with tag v1.48.2
, nextcloud web page is inaccessible most probably due to somehow nextcloud is updated to the latest version (>=24) during the build process but 32bit architecture is only supported for nc version <24.
git clone -b v1.48.2 https://github.com/nextcloud/nextcloudpi.git
cd nextcloudpi
./build-docker.sh armhf
I would expect that when building a docker image from a tagged version from GitHub that the nc and ncp versions are installed which were specified in the code at that time.
It would be great if someone could help me to find out how to build a docker image myself that is still capable running on a 32bit raspberry.
Thanks in advance.
Why don't you use the latest image? armhf images are still being provided.
Unfortunately I can't really spent time on supporting builds for outdated versions of nextcloudpi
Building one of the latest tags (v1.49.0-v1.50.0) always fails somehow with this error
#8 [qemu 2/2] RUN apt-get update && DEBIAN_FRONTEND=noninteractive
apt-get install -y --no-install-recommends qemu-user-static
#8 sha256:981619b0b76599f41f480f7eff6caec79fcc394346523435e5a81b549
b4bd111
#8 2.364 exec /bin/sh: exec format error
#8 ERROR: executor failed running [/bin/sh -c apt-get update && DEB
IAN_FRONTEND=noninteractive apt-get install -y --no-install-recomme
nds qemu-user-static]: exit code: 1
------
> [qemu 2/2] RUN apt-get update && DEBIAN_FRONTEND=noninteractive
apt-get install -y --no-install-recommends qemu-user-static:
------
executor failed running [/bin/sh -c apt-get update && DEBIAN_FRONTE
ND=noninteractive apt-get install -y --no-install-recommends qemu-u
ser-static]: exit code: 1
That error appears when there is a mismatch between the host architecture and the container architecture
https://stackoverflow.com/questions/73285601/docker-exec-usr-bin-sh-exec-format-error
It can also appear if the entrypoint script is missing the shebang
You can pull the image from the registry on docker hub instead of building it yourself
pi@raspberrypi: ~/nextcloud/nextcloud_srv$ dpkg --print-architecture armhf pi@raspberrypi:~/nextcloud/nextcloud_srv$ uname -a Linux raspberrypi 5.10.103-v7+ #1529 SMP Tue Mar 8 12:21:37 GMT 2022 armv7l GNU/Linux
I assume that the issue is then related to the missing entrypoint script - how can I confirm that?
@kapsner Again, why do you want to build the image yourself? There are working images available. Just pull ownyourbits/nextcloudpi and run it.
Of course, if you really want to go through that hassle, you're welcome to build these images yourself. :)
@theCalcaholic well, I had best experiences building images myself so far when deploying software.
Regarding nextcloudpi, I was initially affected by https://github.com/nextcloud/nextcloudpi/issues/1237. Back then, I had to build v1.31.0 myself as the tag wasn't available from docker hub (currently, many tags aren't available as well, that was why I again tried to build images myself).
However, I was finally able to figure out the issue this time.
What messed up my data-folder is still unclear, however, I assume that building a new image and mounting the previous data-folder into the new image somehow altert some config-files including the version of nc.
Solution was to move the old data-folder to a new location (i.e. mv /media/usb/nextcloud/data /media/usb/nextcloud_old/data
) and letting a completely new data folder be initialized by the new image.
Then I copied all user-files from the previous install (i.e. mv /media/usb/nextcloud_old/data/nextcloud/data/user/files /media/usb/nextcloud/data/nextcloud/data/user/files
), executed the nc-fix-permissions
script from the admin-page and finally ran docker exec -it nextcloudpi bash -c "sudo -u www-data php /var/www/nextcloud/occ files:scan --all"
.
I also used the nextcloudpi-armhf:v1.49.1
tag from docker hub, so everything seems to work fine again.
Thanks for your help 🙏
@kapsner
Just to answer your question, you can confirm it by checking if the entrypoint script is present inside the container.
For the current multi-stage container it should be /run-parts.sh
If you want to build it yourself, do you want me to share the Dockerfile's I've been using when building it and testing?
@ZendaiOwl Thank you very much for your answer and the offer to share the Dockerfiles. However, for now I won't need them as the setup using the image from docker hub is finally working.
you can confirm it by checking if the entrypoint script is present inside the container. For the current multi-stage container it should be /run-parts.sh
This confuses me - the error message occurred when building the container, with e.g.
git clone -b v1.49.1 https://github.com/nextcloud/nextcloudpi.git
cd nextcloudpi
build/build-docker.sh armhf
so the script did not finish and the container wasn't built at all, so I wasn't able to check if the script was present inside the container.
Shouldn't users be able to build the container themselves with the commands above (which is also documented in the readme), and have all necessary files / Dockerfiles therefore provided with the git-repo?
Not straight out of the box, it will try to build and push to ownyourbits docker hub repository, which you can see in the script, which you don't have access to.
So it's normal for the build to fail unless you change that part 🙂
The readme page isn't fully updated at the moment, everyone's been so busy that page has become kinda neglected
The error you're getting is primarily due to an architecture mismatch