[Risk Takers] Help us test 25.0.0 on NextcloudPi

Hello ncp gang with servers to spare and @bug-hunters ,

Please help us in testing NextcloudPi with the new 25.0.0 release update process. Please do note this is experimental and only recommended for those able to spin up a non-production instance for possible breakage. We could use more feedback and testing! If you run into zero problems, that is also good to know in regards to your specific installation method, but expect the worst when beta testing :smiley_cat:

Your help is greatly appreciated with testing the 25 migration on:

  • VM
  • SD card images
  • Curl script installation process

Send your feedback to our on-going thread on Github here if you are able to do this. Please do not test on a production instance you care about. Thank you for your consideration!

If you are still on a 32-bit instance please do not update while we sort out status of 32-bit support in 25.0.0 on Github.

1 Like

I upgraded my Debian Bullseye to the 64bit OS on my Rapsberry4. Nextcloud runs rockstable with a handful users, over 100k pictures (both Smartphone and pro Cameras with 100 mpx), a few thousand 4k movies (with up to 600Mbit streams), external 4TB USB HD mounted as nc_data, Documents, Shares and full access to the Internet via Fritzbox.

Made a simple install (not NCP, since I have some other services running on that Raspi, ie Pihole, Apache2 with Lychee and such), a bit optimizing the Mariadb, Memchaced and Redis, a bit PHP tuning, but nothing special. Works very fine for me, even better than on my Intel NUC (Core i3) with 12 GB of RAM.

In regards to 32bit architecture I have some unfortunate news which I laid out in this comment in the GitHub issue. I’ll copy and paste it here as well to give it some more visibility

As I am interested in the new RISC-V architecture and have purchased a development board with the new JH1100 CPU (still waiting on it to be shipped around February), I’ve been keeping an eye on the Wiki page from the Debian developers around this architecture and their Wiki page.

There is some unfortunate data on that page for all 32-bit users, the current Debian repository is slowly becoming unable to compile the 300,000+ packages available in the Debian package repository for the 32bit architecture.

Ultimately what this means is that 32bit architecture is slowly “dying” or fading away, since it isn’t even capable of compiling the tools anymore. Only around 30-35% of the current packages successfully compile on a 32bit architecture, and it has slowly been decreasing every month for a couple years now and getting to the point where it no longer is viable to keep trying to compile the packages for that architecture.

Note that it says x32 is high on the chart, but that is because the x32 ABI is no longer a pure “32bit” architecture, it is in fact a mix of 32bit and 64bit due to a request from Linus Torvalds in August 27, 2011. You can read a little bit about it on this Wikipedia page


QUOTE from RISC-V - Debian Wiki

What are the goals of this project in particular?

In this project the goal is to have Debian ready to install and run on systems implementing a variant of the RISC-V ISA:

  • Software-wise, this port targets the Linux kernel
  • Hardware-wise, the port targets the 64-bit variant, little-endian

This ISA variant is the “default flavour” recommended by the designers, and the one that seems to attract more interest for planned implementations that might become available in the next few years (development boards, possible consumer hardware or servers).

While 32-bit and 128-bit implementations are possible, there are problems with this:

In the context of RISC-V design, they have not been explored as deeply, and tools and resources (e.g. simulators, research cores) as not as well studied and adapted;

For general purpose computers, the focus shifted to 64-bit for many years already, and there isn’t a lot of interest in 32-bit architectures except for specific purposes;

32-bit ports in Debian already struggle to compile some large packages of the archive in the last few months/years, a problem that will become worse with time;

A 128-bit port is simply not realistic at this time.

Particularly this line:

32-bit ports in Debian already struggle to compile some large packages of the archive in the last few months/years, a problem that will become worse with time

What this means, in my interpretation, is that 32bit architecture doesn’t have much longer left for general use and will not remain as a viable option for that, much longer.

Edit: :pray: I’m talking in the context of years, which I interpret the meaning of the text on the wiki page also doing & underlying it using an image with data as an example

Do I think 32bit will go away completely?

No, but I do think it will only remain for specific use-cases (like industrial SOC’s/Embedded systems for simpler computing tasks) and not general use, and certainly not for general use as a home-server.

As such, it has become improbable to support 32bit when even the Debian maintainers are struggling to keep up, and if they drop that support, we will be unable to continue with a 32bit image, as we kind of already are in regards to Nextcloud 25 and PHP 8.0+.

So it’s unfortunate, but in my opinion, supporting 32bit architecture is becoming less and less of a viable option, in fact, it kind of already is non-viable with the amount of packages that doesn’t compile on it and the fact that almost none of us that write the code have a 32bit machine to test things out on to make sure they work.


Got some more news, 32bit support got extended for version 25 (specifically in 25.0.2), it will now officially be dropped in version 26

1 Like