Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.


Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Bookmarks
  • Search
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Brand Logo

Cloudron Forum

Apps | Demo | Docs | Install
  1. Cloudron Forum
  2. Discuss
  3. Cloudron on a Raspberry pi?

Cloudron on a Raspberry pi?

Scheduled Pinned Locked Moved Discuss
armraspberry-pi
133 Posts 17 Posters 53.2k Views 19 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • M Offline
      M Offline
      malvim
      wrote on last edited by
      #13

      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.

      1 Reply Last reply
      0
      • W will

        @malvim How about I ship you mine?

        M Offline
        M Offline
        malvim
        wrote on last edited by malvim
        #14

        @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?

        W 1 Reply Last reply
        0
        • M 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?

          W Offline
          W Offline
          will
          wrote on last edited by
          #15

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

          1 Reply Last reply
          0
          • girishG Do not disturb
            girishG Do not disturb
            girish
            Staff
            wrote on last edited by
            #16

            @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.

            M 1 Reply Last reply
            0
            • girishG 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.

              M Offline
              M Offline
              malvim
              wrote on last edited by
              #17

              @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.

              1 Reply Last reply
              0
              • girishG Do not disturb
                girishG Do not disturb
                girish
                Staff
                wrote on last edited by
                #18

                @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.

                M 1 Reply Last reply
                0
                • girishG 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.

                  M Offline
                  M Offline
                  malvim
                  wrote on last edited by
                  #19

                  @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.

                  1 Reply Last reply
                  2
                  • M Offline
                    M Offline
                    malvim
                    wrote on last edited by malvim
                    #20

                    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.

                    1 Reply Last reply
                    2
                    • M Offline
                      M Offline
                      malvim
                      wrote on last edited by
                      #21

                      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...

                      1 Reply Last reply
                      1
                      • M Offline
                        M Offline
                        malvim
                        wrote on last edited by
                        #22

                        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!

                        yusfY robiR 2 Replies Last reply
                        4
                        • girishG Do not disturb
                          girishG Do not disturb
                          girish
                          Staff
                          wrote on last edited by
                          #23

                          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

                          1 Reply Last reply
                          2
                          • M 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!

                            yusfY Offline
                            yusfY Offline
                            yusf
                            wrote on last edited by
                            #24

                            Stellar effort getting this far, @malvim! It’s sounds quite promising.

                            1 Reply Last reply
                            2
                            • M 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!

                              robiR Offline
                              robiR Offline
                              robi
                              wrote on last edited by
                              #25

                              @malvim arm64 is only available on the rPi 4 as far as I recall.
                              armhf is for the previous models as they are 32bit ARM chips.

                              It would be cool if both were supported and autodetected, but you should be aware of the arch differences between the different models.

                              Conscious tech

                              M 1 Reply Last reply
                              1
                              • robiR robi

                                @malvim arm64 is only available on the rPi 4 as far as I recall.
                                armhf is for the previous models as they are 32bit ARM chips.

                                It would be cool if both were supported and autodetected, but you should be aware of the arch differences between the different models.

                                M Offline
                                M Offline
                                malvim
                                wrote on last edited by malvim
                                #26

                                @robi Yeah, I don't know much about the different architectures, and at present I don't have access to any earlier armhf model, so I'll keep pushing with what I have for now. Maybe if we can suport the arm64 rPi 4 to start, some modifications (like explicitly handling architecture information, different boot locations and whatnot) will help us deliver cloudron to other models more easily.

                                1 Reply Last reply
                                1
                                • M Offline
                                  M Offline
                                  malvim
                                  wrote on last edited by
                                  #27

                                  Just keeping everything relating to the rpi setup in this thread:

                                  So I finished setting up, went to https://<ip> like cloudron-setup says, and started domain setup. As per the other thread, I set up my IP to the interface I'm using (wlan0). I'm using Amazon AWS as a domain provider, and set up the keys and such.

                                  So cloudron was able to create the DNS records (using a subdomain, like pi.mydomain.com, which should - and does - create an A record my.pi.mydomain.com pointing to my 192.168 internal IP).

                                  Afterwards, though, cloudron is never able to check for the records, as I cannot seem to resolve the my.pi domain from inside the pi.

                                  Other stuff that happens:

                                  • sudo always says sudo: unable to resolve host ubuntu, even though it does change user to root no problem; ubuntu is the default hostname on a bare ubuntu 18.04 install on the pi;
                                  • I can dig other domains that are already hosted on my zone, and get corret responses. dig- ing for the my.pi domain either times out with a "no server could be reached" message, or, when I do it RIGHT AFTER a successful dig to other domain, returns an "empty" response (with a line indicating 0 answers, like this: ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1)

                                  I'm a bit over my skill level on this, so if anyone could chime in, id'd be greatly appreciated. Either with an idea on what might be going on, or maybe something I could do/check/run to get mor info on what might be going on.

                                  Thanks!

                                  1 Reply Last reply
                                  0
                                  • nebulonN Offline
                                    nebulonN Offline
                                    nebulon
                                    Staff
                                    wrote on last edited by
                                    #28

                                    @malvim said in Cloudron on a Raspberry pi?:

                                    sudo: unable to resolve host ubuntu

                                    This is expected and has nothing to do with arm. To get over that you have to setup the hostname correctly. In your case the hostname is still set to the default ubuntu whereas following your example it has to be my.pi.mydomain.com

                                    M 1 Reply Last reply
                                    0
                                    • nebulonN nebulon

                                      @malvim said in Cloudron on a Raspberry pi?:

                                      sudo: unable to resolve host ubuntu

                                      This is expected and has nothing to do with arm. To get over that you have to setup the hostname correctly. In your case the hostname is still set to the default ubuntu whereas following your example it has to be my.pi.mydomain.com

                                      M Offline
                                      M Offline
                                      malvim
                                      wrote on last edited by
                                      #29

                                      @nebulon huh, that makes sense, but I thought this was supposed to be done by cloudron during setup? I don’t remember having to manually set the hostname in any other cloudron setup before, but I might just have forgotten...

                                      1 Reply Last reply
                                      0
                                      • girishG Do not disturb
                                        girishG Do not disturb
                                        girish
                                        Staff
                                        wrote on last edited by
                                        #30

                                        It looks like the blocking issue is the DNS does not work? Does host my.pi.mydomain.com and host my.pi.mydomain.com 127.0.0.1 work on the pi?

                                        1 Reply Last reply
                                        0
                                        • jamesgallagherJ Offline
                                          jamesgallagherJ Offline
                                          jamesgallagher
                                          wrote on last edited by
                                          #31

                                          If there's nothing private in it; could you post your /etc/hosts file?

                                          1 Reply Last reply
                                          0
                                          • M Offline
                                            M Offline
                                            malvim
                                            wrote on last edited by
                                            #32

                                            Yup, so I'm testing it again from scratch.

                                            @jamesgallagher, here's the entire contents of my /etc/hosts right after running cloudron-setup, but before setting up the domain in the browser:

                                            127.0.0.1 localhost
                                            
                                            # The following lines are desirable for IPv6 capable hosts
                                            ::1 ip6-localhost ip6-loopback
                                            fe00::0 ip6-localnet
                                            ff00::0 ip6-mcastprefix
                                            ff02::1 ip6-allnodes
                                            ff02::2 ip6-allrouters
                                            ff02::3 ip6-allhosts
                                            

                                            @girish, the record is already there with the previous IP, and right now I'm just after cloudron-setup, but before setupdns.html on the browser. I've ran a bunch of commands, here are the results:

                                            • host my.pi.<mydomain.com> - not found
                                            • host my.pi.<mydomain.com> 127.0.0.1 - not found
                                            • host www.google.com 127.0.0.1 - ok (huh, unbound seems to be somewhat working)
                                            • host code.<mydomain.com> 127.0.0.1 (gitea instance on production cloudron) - OK!
                                            • host my.<mydomain.com> 127.0.0.1 (production cloudron admin) - NOT FOUND! (wat?)

                                            And I ran host my.pi.<mydomain.com> on my local machine, outside the pi, and it works and returns the old record (192.168.0.109 from my previous attempt).

                                            I'm now setting up DNS in the browser, just to check what happens, I'll re-run the commands and post here.

                                            M 1 Reply Last reply
                                            0
                                            Reply
                                            • Reply as topic
                                            Log in to reply
                                            • Oldest to Newest
                                            • Newest to Oldest
                                            • Most Votes


                                              • Login

                                              • Don't have an account? Register

                                              • Login or register to search.
                                              • First post
                                                Last post
                                              0
                                              • Categories
                                              • Recent
                                              • Tags
                                              • Popular
                                              • Bookmarks
                                              • Search