Add arm32v7 builder

[gleich]

Create a new file called arm.Dockerfile that allows you to run it on arm32v7 CPUs such as the Raspberry Pi's CPU.

[nhooyr]

@aptalca Thank you so much! That will be incredibly useful. Currently our CI only installs an extension and confirms that worked but the screenshot approach is far more robust.

[aptalca]

Sure, let us know if we can help in any way. You can pop into our discord to discuss further or if you have questions: https://discord.gg/YWrKVTn

[Rathna-K]

Hi @aptalca @nhooyr trying to pull a docker image for coder to run RPi4. Where should I go for an “official image” ? Meaning one will be supported in the future? is it Linux Server io? Or something else? I saw a lot of threads around this in here but still unclear on which one to use. Oh also, if I use Linuxserver.io image how can I use port 80 as I have a reverse proxy already. I see you expose 8443 so I am assuming you are adding self signed cert? TIA

[aptalca]

@Rathna-K linuxserver.io is third party, not official. If your pi is running a 64 bit OS, you can use either image. But if it is running a 32 bit OS like the stock raspbian image, then linuxserver one is your only choice for docker image at the moment.

The container port for the linuxserver one is 8443 because we published that image before code-server changed their default port from 8443 to 80. We didn't want to break anything for our existing users so we kept it as 8443. But you can map that port to whatever port you like on your host anyway since it's docker. It serves http by default and we recommend a reverse proxy like this one: https://github.com/linuxserver/docker-letsencrypt it comes with a preset proxy conf that you can easily enable: https://github.com/linuxserver/reverse-proxy-confs/blob/master/code-server.subdomain.conf.sample

One cool thing about the linuxserver image is the list of mods we provide, that install popular dev packages in the container: https://mods.linuxserver.io/?mod=code-server They are enabled by a simple env var when creating the image and thus are persistent through container recreation unlike things that are manually installed inside a running container (they disappear along with the container during update/recreation)

[nhooyr]

Yes, in terms of an arm32 docker image, your only choice at the moment is linuxserver.io.

For an officially supported solution you can use the NPM package and follow our setup guide. https://github.com/cdr/code-server/blob/master/doc/guide.md

[tidux]

The Pi 4 has full aarch64 support coming with Raspbian, and it already exists via Ubuntu and Gentoo, so it might be easier to just replace the hardware.

[nhooyr]

Yea but most users will still be using arm32v7 so we'll be sure to add a builder in the next few weeks.

[sr229]

If it helps you @nhooyr, Docker has native cross building support in Beta, so you just need to install the Edge version to use the BuildKit project.

[nhooyr]

I gave that a shot a few weeks ago @sr229

Unfortunately, qemu's user mode emulation kept erroring out when building code-server :(

Don't remember the specifics right now. I'll give it a shot again at some point.

[imgmatt]

Ya'll can test the npm package: yarn global add code-server. 🎉

Hey, apologies for the bump... not sure if I'm being a complete bozo but this has me stumped. Tried this a few times on my Pi 3B + running node v12 and all dependencies. I'm getting a successful install (success Installed "code-server@3.4.1" with binaries) but code-server doesn't run. Not sure the install even did anything, even with --unsafe-perm added.

[code-asher]

Does it give any errors? If it's something like "command not found" then you might just need to add the yarn binary directory to your PATH environment variable. I think by default it's ~/.yarn/bin.

[imgmatt]

Does it give any errors? If it's something like "command not found" then you might just need to add the yarn binary directory to your PATH environment variable. I think by default it's ~/.yarn/bin.

That worked, thanks! code-server is now running without throwing any errors in terminal but getting 'refused to connect' in the browser when loading the default address. Seems like default Raspbian install might need some firewall/port forward updating.

[code-asher]

Are you connecting directly to code-server? If that's the case you might need to add --host 0.0.0.0. By default it listens on localhost which is not accessible externally.

[imgmatt]

Are you connecting directly to code-server? If that's the case you might need to add --host 0.0.0.0. By default it listens on localhost which is not accessible externally.

I'm connecting from another machine on my local network, but it was running @ 127.0.0.1:8080. Also tried 0.0.0.0 but still refused.

If I VNC into the Pi, I can connect to code-server in that browser though - not ideal.

[code-asher]

Hmm yeah if you're just accessing from another local machine via the ip then 0.0.0.0 will be necessary. But if that's still not working then it could definitely be a firewall issue.

[code-asher]

I'm not super familiar with Raspbian but a cursory search seems to suggest it doesn't have a firewall enabled by default. Have you enabled iptables or ufw or something?

[sr229]

I think we should still supply prebuilt binaries and have postinstall download them (fallback to compilation if cannot find a prebuilt) to save time for them.

[7HE-W0R1D]

My process for cobbling together builds is as follows:

1. Build Code Server on aarch64 docker container on a X86_64 host using qemu-aarch64-static via binfmt (linking needs ~12GB of RAM; impossible on a 32-bit arch which can address a max of 4GB per process)
2. Shipping the compiled directory to a native arm6 system (steps are the same for arm32v7); in my case an RPi Zero W / RPi 2
3. Going into code-server-*-built and running npm rebuild on everything (node arm6 unofficial build needed)

That produces something that can be run via the node arm6 unofficial build via node ./build/code-server*/out/vs/server/main.js --auth none

The packing can't be done on a RPi2(1GB), because build.ts is trying to pass the entire packed binary to fs.writeFile as a buffer which easily exceeds the 1GB; from what I've read it should be possible to use streams to reduce that footprint to something more sane (streams -> https://medium.com/dev-bits/writing-memory-efficient-software-applications-in-node-js-5575f646b67f)

I'm not sure if streams could also help with the 12GB ram footprint of the build phase; I don't even know where to start investigating that one as build has way more going on.

Thanks for your package @deftdawg! In fact it is the only one that runs on my pi zero w. However, I'd like to try the latest build of code-server but I'm totally new to docker and binfmt. I tried googling for results but cannot find the right way to go. Could you elaborate a bit more on how to "Build Code Server on aarch64 docker container on a X86_64 host using qemu-aarch64-static via binfmt"? I'm on a windows 10 64bit laptop with docker and qemu installed, but I cannot figure out what to do next :( Thanks in advance!

[deftdawg]

@7HE-W0R1D - Going from memory as my machine died; waiting for a NUC11 replacement to come in a few weeks hopefully.

You need a Linux machine (or VM) running X86_64 intel kernel with lots of RAM. Trying to do this with a docker/VM on Windows is probably going to be painfully slow (though it should be possible if you are able to allocate tonnes of memory to docker).

On your linux machine/VM, you need to install qemu-user-static and possibily qemu-user-binfmt if it doesn't install as a dep.

What it does is essentially register some scripts with the binfmt kernel module that when it sees an ARM executable (by looking at the magic line of the file) it automatically emulates arm64.

Then run an ARM64 distro using qemu-aarch64-static and then follow the build steps to compile code-server.

It's not worth the effort tbqh... Like what would you plan to do (development wise) on a Pi Zero that a newer version of VS Code is going to make any difference?

[7HE-W0R1D]

@7HE-W0R1D - Going from memory as my machine died; waiting for a NUC11 replacement to come in a few weeks hopefully.

You need a Linux machine (or VM) running X86_64 intel kernel with lots of RAM. Trying to do this with a docker/VM on Windows is probably going to be painfully slow (though it should be possible if you are able to allocate tonnes of memory to docker).

On your linux machine/VM, you need to install qemu-user-static and possibily qemu-user-binfmt if it doesn't install as a dep.

What it does is essentially register some scripts with the binfmt kernel module that when it sees an ARM executable (by looking at the magic line of the file) it automatically emulates arm64.

Then run an ARM64 distro using qemu-aarch64-static and then follow the build steps to compile code-server.

It's not worth the effort tbqh... Like what would you plan to do (development wise) on a Pi Zero that a newer version of VS Code is going to make any difference?

Thanks for the timely reply! Well the last line is real good question, I guess I will give the VM/Docker a shot but if it fails(probably will) I'll stick to your prebuild package.

[7HE-W0R1D]

@deftdawg also I saw someone saying https://github.com/cdr/code-server/issues/1337#issuecomment-622457413 this yarn add command can do the thing. I tried it and it does build the package successfully, like for 2000 or 3000 seconds. But when I run code-server, the welcome password screen appears and then there will be a 500 error with no extra messages. Does that mean its impossible to use the yarn install (or yarn addnow) on rpi or it is something that is fixable?

[RobertCNelson]

I've kinda just jumped into this project for beagleboard.org , we had been shipping "cloud9" for the last 5 or 6 years as our default ide.. It's been un-maintined for last few years with me just hacking on it keep it building on debian's default version of nodejs.

So i started looking at this project last week.. I've been successful on building it a Raspberry Pi 4 8GB model running in armhf mode. Currently 3.8.1/3.9.0 run great on our BeagleBone Blacks' (AM335x) Cortex-A8 with 512MB of ram..

Only 2 patches are required..

First there is an arfifcal stop in ci/lib.sh:

https://github.com/cdr/code-server/blob/v3.9.0/ci/lib.sh#L37-L50

arch() {
  case "$(uname -m)" in
  aarch64)
    echo arm64
    ;;
  x86_64 | amd64)
    echo amd64
    ;;
  *)
    echo "unknown architecture $(uname -a)"
    exit 1
    ;;
  esac
}

I just added an armhf option, it's not really used anywhere, more then likely to just stop the build with an exit 1..

From 51644af7dbe139d3f8db4170c7a6da18e2072051 Mon Sep 17 00:00:00 2001
From: Robert Nelson <robertcnelson@gmail.com>
Date: Wed, 10 Feb 2021 10:20:51 -0600
Subject: [PATCH] bbb.io: ci/lib.sh lets not stop when detecting armv7l

Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
---
 ci/lib.sh | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/ci/lib.sh b/ci/lib.sh
index 96a413f1c..179c27688 100755
--- a/ci/lib.sh
+++ b/ci/lib.sh
@@ -42,6 +42,9 @@ arch() {
   x86_64 | amd64)
     echo amd64
     ;;
+  armv7l)
+    echo armhf
+    ;;
   *)
     echo "unknown architecture $(uname -a)"
     exit 1

Second, there is a gulp call in lib/vscode/package.json that requires 8GB of memory for JavaScript, i backed this down to 6GB which allows it to run on the 8GB Pi 4.. While watching a build in TOP, i'm really wondering what the point of this 8GB setting was..

https://github.com/cdr/code-server/blob/v3.9.0/lib/vscode/package.json#L32

"gulp": "gulp --max_old_space_size=8192",

From 00cf8a3d8a5d95183e7fd251d65cbd368e8c0c3e Mon Sep 17 00:00:00 2001
From: Robert Nelson <robertcnelson@gmail.com>
Date: Wed, 10 Feb 2021 12:35:22 -0600
Subject: [PATCH] bbb.io: lib/vscode/package.json: limit memory from 8gb to 6gb

Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
---
 lib/vscode/package.json | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/vscode/package.json b/lib/vscode/package.json
index d4efccba3..4e4e5060f 100644
--- a/lib/vscode/package.json
+++ b/lib/vscode/package.json
@@ -29,7 +29,7 @@
     "kill-watch-extensionsd": "deemon --kill yarn watch-extensions",
     "mocha": "mocha test/unit/node/all.js --delay",
     "precommit": "node build/hygiene.js",
-    "gulp": "gulp --max_old_space_size=8192",
+    "gulp": "gulp --max_old_space_size=6144",
     "electron": "node build/lib/electron",
     "7z": "7z",
     "update-grammars": "node build/npm/update-all-grammars.js",

anyways to build i grabbed nodejs' armv7l build from: https://nodejs.org/dist/latest-v12.x/ (as debian buster's nodejs is v10...)

Installed yarn 1.22.5 with nodejs's npm/nodejs build, then just ran (and waited about an hour..)

yarn
yarn build
yarn build:vscode
yarn release
yarn release:standalone

Here are my packaged build i'm testing for BeagleBoard.org, they do require a pure Debian userspace for armhf (ARMV7-A..)

https://rcn-ee.net/repos/debian/pool/main/b/bb-code-server/

These can be run as:

/opt/code-server/app/bin/code-server --auth none --bind-addr 0.0.0.0:3000

I'm still working on our *.deb package ^, as I'm hacking on a systemd socket startup.. (only 512MB of ram on our boards..) and tuning it for our default first user (debian: user 1000), along with a list of pre-installed extensions..

For reference here is my full tree: https://github.com/rcn-ee/code-server/tree/v3.9.0-bbb.io (i nuked a few git calls as i'm building it in a debian sbuild with no git installed..)

Regards,

[eh8]

Are there still any plans to release the armhf binaries to accompany x86 and arm64 in the future via GitHub? The linuxserver docker images are neat but I'm hoping for a bare metal installation if possible.

[sr229]

Are there still any plans to release the armhf binaries to accompany x86 and arm64 in the future via GitHub? The linuxserver docker images are neat but I'm hoping for a bare metal installation if possible.

There isn't that large demand if you ask me, plus most of the development happens in ARM64 or x86_64 hosts, so there won't be any demand for this.

[eh8]

There isn't that large demand if you ask me, plus most of the development happens in ARM64 or x86_64 hosts, so there won't be any demand for this.

I can't speak beyond my own circumstances, but as I understand there many use Raspberry Pi/ODroid/etc either as standalone units or in k8'ed configuration as build servers which would suit code-server. It would be a presupposition to discount these platforms for lack of computing power/memory simply because there are small Raspberry Pis that exist.

It also looks like @RobertCNelson was able to tweak the build scripts trivially to produce viable 32-bit ARM builds, so I would hope that code-server can reproduce the builds officially.

[jsjoeio]

If it's trivial to add + maintain, then we'd be happy to support this.

@eh8 we'd happily review a PR if you submitted one (same goes to you @RobertCNelson). You two probably more than we do (or me at least).

Otherwise, we can try and take a look at this in the near future.

[sr229]

There isn't that large demand if you ask me, plus most of the development happens in ARM64 or x86_64 hosts, so there won't be any demand for this.

I can't speak beyond my own circumstances, but as I understand there many use Raspberry Pi/ODroid/etc either as standalone units or in k8'ed configuration as build servers which would suit code-server. It would be a presupposition to discount these platforms for lack of computing power/memory simply because there are small Raspberry Pis that exist.

It also looks like @RobertCNelson was able to tweak the build scripts trivially to produce viable 32-bit ARM builds, so I would hope that code-server can reproduce the builds officially.

This is a valid reason though it's pretty hard to compile for ARMv32 considering there aren't any more public builders offering this, and the fact it's a little hard to configure the CI to do the compile steps for it (only for it to break really horribly).

[oxy]

Now that we have arm64-on-x64 cross compile, it should be fairly simple to also do armv7-on-x64 builds; if there's no PRs for this, I'll look into it in the future, but there are currently other issues that are higher priority.