Cloudron on a Raspberry pi?

[yusf]

@girish said in Cloudron on a Raspberry pi?:

Can one build docker ARM images on x86

Sure seems like it.

By the way, ubuntu image is already multi-arch.

ARM support would be immensely useful in combination with the upcoming fleet-like multi-Cloudron dashboard feature.

[malvim]

Thanks for the replies, guys. I'll take a stab at it, tomorrow or on Friday, and see what it looks like. I don't have a Raspberry Pi 4, but I'm willing to even "rent" one for a month to see where I can get to with this.

Thanks a lot!

[mehdi]

@malvim It would not work right now, as cloudron container images are not built as multi-arch, but everything else may just work out of the box

[girish]

Yeah, as @mehdi said, I suspect installation, setup and everything will work fine. Just you can install any apps. But I will be curious to know if those things work fine, if you get around to it. Maybe we should just setup the CI/CD system to build app images which we have been planning for a while.

[rmdes]

This post is deleted!

[iamthefij]

I've build and maintain a bunch of multi-arch images myself for some of my smaller projects.

You can definitely build on an x86 system by using emulation. I used to install qemu and then use build args to ensure that the right base image was being pulled (eg library/ubuntu for x86 vs armv7/ubuntu for armv7) because otherwise, by default, an x86 machine would pull the x86 image. After building and pushing I generate a manifest and push that so that each platform pulls the right image. This is probably the simplest example I have of that since it's a single Python file.

All that said... there is now an experimental feature of Docker available via the docker buildx command.

Here's a recent (April) blog post from Docker about the new method. It's far simpler, so if you can get that working, it'd be ideal. I haven't taken the time to switch over myself just yet.

[malvim]

@girish I've already started and had some minor issues when using ubuntu 18.04, but running now on ubuntu 20.04 (step by step, following the install script so I can debug), and it seems to be going fine.

As for apps, I'll follow @yusf's link and @iamthefij's advice to package one of my own custom apps, which is VERY simple, and see how it goes!

[will]

@yusf THIS!

"Gathers fleet of Rpi's for cloudron to eat"

[will]

@malvim How about I ship you mine?

[malvim]

Yeah, it seems mysql-server-5.7 is not available (though there's a later version that is), and I wasn't able to get past installing linux-generic as well, since it seems kernel patching is not exactly the same under arm...

Also, I saw the script downloads a specific version of nginx, which is amd64 as well. I'll keep trying, but I've been having network problems which I think have to do with the provider I chose. I'll get back when I have more news.

[malvim]

@will Man, I'd REALLY love to, but my guess is we don't live in the same country heheh... I'm from Brazil!

If you can get it on a network with an ubuntu 20.04 version, maybe I can access it via ssh and fiddle for a bit?

[will]

@malvim Yeah man, PM me what you want on it, and I'll reimage it soonest and beam over creds.

[girish]

@malvim Yeah, you can adjust that apt line as needed. Essentially, you have to make the https://git.cloudron.io/cloudron/box/-/blob/master/baseimage/initializeBaseUbuntuImage.sh script succeed. You can make the script standalone, it does not require any args.

nginx ARM packages - http://nginx.org/packages/ubuntu/pool/nginx/n/nginx/

Node ARM packages - https://nodejs.org/dist/v10.18.1/

Docker ARM packages - https://download.docker.com/linux/ubuntu/dists/bionic/pool/stable/

Also, I saw you are testing in Focal. One issue I hit (even on x86) was that collectd has issues with the python3 plugin. I haven't gotten around to fix that.

[malvim]

@girish Yeah, I'll try bionic again, it just crashed on something related to initramfs-tools, and focal still does when i try to install linux-generic, which I assume has something to do with kernel images and the like? This stuff is a bit above my current knowledge, so I'm not exactly sure what I'm doing heheh.

[girish]

@malvim Cloudron doesn't really use any of the packages like linux-kernel, initramfs etc directly. I think it's just added there for completeness. Feel free to remove them.

[malvim]

@girish great! I was already commenting out these lines to see where it went.

So it seems I'm losing name resolution after installing unbound. Installation of resolvconf is not a problem, but as soon as I install unbound, lots of names stop resolving and I can't install anything anymore.

Not sure how unbound works, might have to go into it a bit more, but my guess is maybe the problem is inside my provider. I'll check with @will later to see if we can try it in his device, and see if the problem persists.

[malvim]

Just to keep you guys updated on what's going on: I commented out unbound just to go through (and probably have to come back to it later, but still).

I also switched to installing nginx from the repos instead of downloading a specific package with curl manually, as their version is arm64 and it seems the rpi I'm on is armhf, which I know nothing about but some nginx-arm64 dependencies were not being met.

I switched node to the armv7l package and it went ok.

I switched docker packages to armhf, they intalled okay, but it seems I don't have the overlay kernel module loaded and have NO IDEA how to load it heheh. A few google searches still got me kinda stuck, I'll try again tomorrow.

[malvim]

Alright, so I learned how to load kernel modules, and the problem now is that the / partition in this particular provider is over nfs, and overlay is not supported.

So, as this is not a problem with cloudron on a rasberry pi, and is particular to this provider, I'm thinking of trying to change the docker driver tomorrow, just to see how far I can get to...

[malvim]

Hey, yall.

So my Raspberry Pi finally arrived, and I could start testing cloudron on it without the hassles I was having with the hosting company. So here are some thoughts and the current bump on the road I'm trying to overcome:

• I was able to install cloudron pretty easily with just a few changes to the cloudron-setup script itself, and to initBaseImage.sh and installer.sh inside the cloudron package that is downloaded from the internet by cloudron-setup
• The changes in cloudron-setup were just not upgrading the kernel (not installing linux-generic, like I talked to @girish about earlier in this thread), and not downloading the cloudron package from the website, instead using my modified version so I coud change things and test.
• The changes inside the package were pretty much just changing amd64/x64 strings to arm64 in all the downloaded packages
• Another important change is the boot part, where cloudron changes grub files, and I had to switch things to the /boot/firmware files
• I was able to keep unbound untouched, I guess it was a problem with the hosting company

So that was what I had to do, and here are the things I'm currently thinking about this:

• It would be good to have the current architecture in a variable, say arch, but there's a few questions to answer, like:
  • The rpi I was using in the hosting company was not arm64 architecture, but armhf, I think. If there's different architectures for different models, we'd have to test it on others. I currently own an arm64 rpi 4 model B.
  • Some downloaded packages use x64 instead of amd64 in their names, and stuff like armv7l for armhf architecture, it seems. We'd have to map these package names to their architectures in a more explicit way, I think.
• We'd have to extract the boot configuration (grub vs /boot/firmware confs) somewhere

I'm now facing ANOTHER problem, which is: it seems my ISP doesn't allow me to forward low ports like 80 and 443, so I can't really host cloudron from inside my home at the moment. I'm starting another thread asking for ideas with that, but I can't test cloudron apart from the installation process (which went smoothly all the way to the domain setup, but then I can't access it because of port forwarding restrictions).

So there it is, this is were I'm at currently regarding installing cloudron on an rpi, I'd greatly appreciate any input, thoughts, ideas, whatever you guys have.

Cheers!

[girish]

That's fantastic news I replied here about the port forwarding - https://forum.cloudron.io/topic/3324/testing-from-home-without-nat-port-forwarding-capability