Building EmbassyOS 2.17 on a Raspberry PI
Jon Staab
Posted on December 28, 2021
Start9 Labs' EmbassyOS is an exciting project, and I couldn't wait to try it - but I wasn't about to spend over $179 on the software. For true self-sovereignty, it should be free and open source, so I went that route. Unfortunately, I ran into a number of issues, enough to justify a blog post detailing what the errors were, and how I got past them.
For guidance, I am following the official build guide, supplemented by this unofficial guide.
Note that EmbassyOS 0.3.0 is coming out real soon now, so these tips will likely be obsolete by the time I publish them.
Building Stack
The bulk of my time was spent building version 2.5.1 of stack, since only version 2.1.3 is available for Raspbian.
The guide says to use stack build --stack-yaml=stack-ghc-84.yaml --system-ghc
to build stack, but it appears ghc 8.4 is no longer available for raspbian. 8.8.4 is the default ghc as of this writing. When I try to compile stack, I get the following error:
No setup information found for ghc-8.4.4 on your platform.
This probably means a GHC bindist has not yet been added for OS key 'linux-armv7', 'linux-armv7-ncurses6', 'linux-armv7-tinfo6'.
Supported versions: ghc-7.10.2, ghc-7.10.3, ghc-8.0.1, ghc-8.0.2, ghc-8.2.1, ghc-8.2.2, ghc-8.6.3, ghc-8.10.1, ghc-8.10.2, ghc-8.10.3, ghc-8.10.4, ghc-8.10.5, ghc-8.10.6, ghc-8.10.7, ghc-9.0.1
Luckily, stack has multiple configuration files! I was able to get stack to build by specifying the compiler thus: stack build --stack-yaml=stack-ghc-88.yaml --compiler ghc-8.8.4
to match my system version. Sady, the following install
command failed, possibly because 8.8.4 is not listed in compatible ghcs above?
At any rate, I next attempted using 8.6.3, which is listed as compatible, using stack build --stack-yaml=stack-ghc-86.yaml --compiler ghc-8.6.3
. This gave me some new errors, namely Error: selected processor does not support movt [...]
.
Following this issue I edited ~/.stack/programs/arm-linux/ghc-8.6.3/lib/ghc-8.6.3/settings
as suggested to force compiling for armv7:
("C compiler flags", "-marm -march=armv7-a")
("target arch", "ArchARM {armISA = ARMv7, armISAExt = [VFPv2], armABI = HARD}")
This seemed to work, although I got a new error that llvm wasn't available, Warning: Couldn't figure out LLVM version! Make sure you have installed LLVM ghc: could not execute: opt
. Stack wants llvm 6, but apt didn't have it so I used 9. I added llvm to my path as follows:
export PATH=/usr/lib/llvm-9/bin:$PATH
export CPLUS_INCLUDE_PATH=$(llvm-config --includedir):$CPLUS_INCLUDE_PAT
export LD_LIBRARY_PATH=$(llvm-config --libdir):$LD_LIBRARY_PATH
stack build
continued to yell at me about using a version of llvm other than 6, but it appears to have worked. Invoking stack install --stack-yaml=stack-ghc-86.yaml --compiler ghc-8.6.3
did the trick as well. Of course, you'll want to add ./local/bin
to your path once this completes, per the guide.
Building EmbassyOS
This step was much more straightforward, the one change that needed to be made to the build guide was to install nodejs 15 rather than the latest version due to engine compatibility. To do that, use nvm install 15
rather than nvm install node
.
Status
After that, my .img was ready to flash! I did, and it's running, but unfortunately the Embassy service is crashing with an error /usr/local/bin/agent: /lib/arm-linux/gnueabihf/libm.so.6: version GLIBC_2.29 not found
. I am still troubleshooting this one on Embassy's chat channel. Let me know if you find a way through that!
Update: the Embassy team told me 0.3.0 is nearly there, and much easier to build than 0.2.17. Onward!
0.3.0
This indeed was much smoother than 0.2.17, however I did still run into some small issues.
When running npm --prefix ui run build-prod
, I got an error when building angular: An unhandled exception occurred: Cannot find module 'webpack'
. Running npm --prefix ui install webpack
fixed this. npm install -g webpack
will also do the trick.
I also had trouble installing the buildx plugin, getting docker: 'buildx' is not a docker command.
even after installing it to ~/.docker/cli-plugins/docker-buildx
with the correct permissions. It seems this is because the version of docker installed by apt on Debian is Docker version 18.09.1, build 4c52b90
, while the buildx feature arrived in v19. Switching to Ubuntu 21.10 fixed the problem.
After clearing that up, everything built beautifully. The product key is in embassy-os/product_key.txt
. Don't delete the repository (or the VPS you used to compile it) until you put that and the eos.img somewhere safe.
At the time of writing, EmbassyOS 0.3.0 is not yet released, so there are a number of rough edges with getting it set up initially. It required a number of restarts before the embassy user was set up and it was able to connect to my LAN. Pro tip: check that your ethernet cable is actually an ethernet cable.
Now that I've gotten my embassy built and running, it's time for me to tear it down. Don't get me wrong — I'm very excited about the project, but it needs to be more stable before I trust it with all my data. In the meantime, I'm going to give NextCloudPi a shot, with an eye toward wrapping it for Embassy down the road if I like it.
Posted on December 28, 2021
Join Our Newsletter. No Spam, Only the good stuff.
Sign up to receive the latest update from our blog.