search

volumio / Build

Buildscripts for Volumio System
GNU General Public License v2.0
113 stars 102 forks source link

[volumioOS branch] build failure for raspberry #436

Closed xipmix closed 3 years ago

xipmix commented 3 years ago

I tried this

# ./build.sh -b arm -d raspberry -v buster

and got a fair way but it falls over here

[ ---- ] Using a compatible nodejs version for all pi images  
[ -- ] Removing previous nodejs installation from /usr/bin/node  
[ ---- ] Removing Node v8.17.0 arm_version: 6  
...
dpkg: error: cannot access archive '/volumio/customNode/nodejs_*-1unofficial_armv6l.deb': No such file or directory
[ error ] Imagebuilder script failed!! 
[ -- ] Cleaning up image_tmp mounts  
[ -- ] Unmounting chroot temporary devices at /mnt/volumio/rootfs  
[ .. ] Cleaning loop device /dev/loop3 [ /dev/loop3: [2049]:9204885521 (/data/mevolumio/forks/Build/Volumio-buster-2021-01-10-raspberry.img) ] 
[ .. ] Deleting image file

build.sh seems not to have populated /volumio/customNode. The code in build.sh uses the variables USE_NODE_ARMV6 and the first element of the NODE_VERSION variables to decide if it's going to do that. The version is 8.17.0 so the last criterion matches. I set DEVICE to raspberry so the first criterion matchies, But USE_NODE_ARMV6 is a bit of a puzzle.

It gets defaulted to yes in build.sh if it is not set, but it seems to also be defaulted to yes in recipes/devices/raspberry.sh. I notice it uses NODE_VERSION directly there, so the two decisions are potentially inconsistent with each other.

After a bit of inspection it seems that one has to manually download the relevant .deb and save it in a local directory. Questions:

ashthespy commented 3 years ago

I should clean up (and document all these flags scattered around..), but the USE_NODE_ARMV6 was added as Node v12 onwards have dropped official support for the armv6 architecture, so I have been packaging the unofficial nodejs builds (#402 ) manually.

After a bit of inspection it seems that one has to manually download the relevant .deb and save it in a local directory. Questions:

  • why doesn't the script do this? Lots of other custom .debs get downloaded in this way.

It can, you can set a path to the deb installer in config.sh, and build.sh fetches them. On looking again at it, its a bit naive as just blindly fetches things and isn't specific to a particular arch. I am not sure how much we want to improve that - I would instead prefer to just have a proper deb repo instead of reinventing the package manager wheel here.. Specific to the nodejs stuff -- Since we are using the official node Debian repo to keep up to date on node minor and patch versions, they don't run on the Pi1,1+ and zero (armv6). To maintain the "one image to rule all pies, we have to use our own bundled binaries". I'd prefer keeping abreast with node versions (currently Volumio uses v8.11.1, while upstream is v8.17.0.. ) So I created the deb installers for all the versions of Node we need, but it hasn't been uploaded to the Volumio repo yet. Once that is done, we can fetch it and install it as usual..

  • I was wanting to build an image for rpi4, which I understand uses an armv8 processor. But if I try to run
./build.sh -d raspberry -b armv8 -v buster

raspberry.sh overrides that, unconditionally. Theres a note about 'refactoring' the script, can someone expand on what that means?

Hmm, for other devices, it quite easy to switch by just setting the BUILD in the device template and it should work. We could also just directly link that with the -b base flag in most cases. With the pi, I am not so sure.. We currently delete the v8+ kernel. Also not sure what other bits we will have to get, as the armv8 base is pulled entirely from Debian repos. I am guessing we would need the raspi-firmware and maybe other patches to get it working with our current armv8 base.

xipmix commented 3 years ago

We could also just directly link that with the -b base flag in most cases.

I was thinking it might be sufficent to just stick with whatever BUILD has been set to, if it is already set? e.g in raspberry.sh

# Base system
- BASE="Raspbian"
- ARCH="armhf"
- BUILD="arm"
+ BASE="${BASE:-Raspbian}"
+ ARCH="${BASE:-armhf}"
+ BUILD="${BASE:-arm}"

but given the v8+ kernel gets removed, then it would seem it's more complex than that. I think I'll let this lie a bit until those node .debs can get uploaded.

Standing back a bit, I wonder if it would help to have some centralised platform notes that explain what the status of each platform is, that people could update as they make progress or find problems. A wiki page, or maybe even in the repo; maybe just some 'official' comments in the top of each plaform script would do it.

ashthespy commented 3 years ago

I think I'll let this lie a bit until those node .debs can get uploaded.

If you are not targetting pi0, then you could get away with USE_NODE_ARMV6=no ./build.sh -d raspberry -b arm -v x.yyy

I was thinking it might be sufficent to just stick with whatever BUILD has been set to, if it is already set? e.g in raspberry.sh

# Base system
- BASE="Raspbian"
- ARCH="armhf"
- BUILD="arm"
+ BASE="${BASE:-Raspbian}"
+ ARCH="${BASE:-armhf}"
+ BUILD="${BASE:-arm}"

After thinking about it more, I am not sure if it makes sense to have so much flexibility -- one could always change the value in the template to test out armv8 - arm64 vs arm - armhf stuff.
Otherwise I see a lot strange errors cropping up, that would be related to the input flags invoked during the build -- thus leading to a lot of "but it works on my computer?!" type issues..

Standing back a bit, I wonder if it would help to have some centralised platform notes that explain what the status of each platform is, that people could update as they make progress or find problems. A wiki page, or maybe even in the repo; maybe just some 'official' comments in the top of each plaform script would do it.

Do you mean from the perspective of the build system? or Buster?

xipmix commented 3 years ago

Do you mean from the perspective of the build system? or Buster?

From the perspective of the build system, so people who come along and want to start building can find their way better. I was just thinking in the context of getting Buster going, but it may be useful longer term.

The thing I had in the back of my mind was the debian installation reports system - with a new candidate installer people can report in on whether their weirdo hardware combination worked or not. In the volumio/Build context, it might be enough to collect up the successful build.sh invocations that the official team makes. Maybe with community contributions too, I dunno. Something like below - but I can see this getting unwieldly. It's probably not worth pursuing.

| date | commithash  | buildline | build env (optional) |
| 2021-01-11 | d5ecdc3 | ./build.sh -b arm -d raspberry USE_NODE_ARMV6=no | Ubuntu 20.04 amd64 |
ashthespy commented 3 years ago

From the perspective of the build system, so people who come along and want to start building can find their way better. I was just thinking in the context of getting Buster going, but it may be useful longer term.

I will try and write some docs on the build system - there are some quirks that should be pointed out. To be quite honest, I didn't think it was going to grow into what it is now, it was just meant to get my two boards building :-D

The thing I had in the back of my mind was the debian installation reports system - with a new candidate installer people can report in on whether their weirdo hardware combination worked or not. In the volumio/Build context, it might be enough to collect up the successful build.sh invocations that the official team makes. Maybe with community contributions too, I dunno. Something like below - but I can see this getting unwieldly. It's probably not worth pursuing.

A wiki page might be a good start for this! but FWIW, I've been building on Docker to take the variation of the build env out..

ashthespy commented 3 years ago

With #441 this should now build, and with #449 the build should boot OTB, without having to set DEBUG mode..