Error baking image with modified template

[raryanpur]

I've pulled the template from the rugpi-template repo and can bake it successfully using ./run-bakery bake image pi4 build/image-pi4.img.

I've tried adding a simple additional recipe that installs the jq package into the customized layer but get the below error when baking. Running on an M2 MacBook Air with Sonoma 14.2 and the latest version of Docker Desktop.

➜  rugpi-template git:(main) ✗ ./run-bakery bake image pi4 build/image-pi4.img
v0.6: Pulling from silitics/rugpi-bakery
Digest: sha256:026a07d0517564a027f1ac788fd17c9f61aaebac9b5dcdb254ec667c150f3d94
Status: Image is up to date for ghcr.io/silitics/rugpi-bakery:v0.6
 INFO baking image `pi4`
Error: loading library

Caused by:
    invalid architecture

I've added the recipe by appending its name to the recipes array in layers/customized.toml. The recipe has one step 00-packages that contains one line jq to install the package. Any ideas?

[koehlma]

This is strange. Are there any significant differences to this: https://github.com/silitics/rugpi-template/tree/test-custom-recipe

[raryanpur]

Used the recipe you linked in a new clone of the template repo and all worked fine first try.

I've tried replicating the original issue but haven't been able to do so consistently. Taking your example, I added a few additional recipes one by one (custom-packages-1, custom-packages-2, etc.) - each just installing one package via apt (e.g. tmux in one, vim in another, etc.) - and appended the recipe each time to the recipes array in layers/customized.toml. Repeating this process a few times I hit the invalid architecture error once, although it resolved itself after I re-ran the command a second time...

Also tried changing the order of the custom-packages-* recipes in customized.toml and hit the error 3 or 4 times through about 30 or so tests. This occurred in multiple clones of the template repo (which I think use different Docker container instances?).

Given the one time I saw the error resolve itself after I re-ran the command, perhaps it has something to do with Docker? Also, it only seems to happen when adding recipes and editing the layer's .toml file. I've never seen it happen on first build from a clean template.

I've preserved a few of the templates that cause the error - let me know if there's any info I can pull from them that would be helpful.

[koehlma]

Thanks for doing these tests and providing further details. The error messages suggests that there is something wrong with loading the recipes. More concretely, it indicates that there appears some architecture in some configuration file which is neither armhf nor arm64. I have to investigate this in more detail. Unfortunately, my schedule this week is very tight as I am currently on a business trip. I guess, I will have time for this next week.

[koehlma]

I am unable to reproduce this problem on my M1 Mac. I added multiple recipes and changed their order several times, but the error did not occur. I do, however, have an hypothesis: The only way I can see this error to occur is a temporary file which is placed in the layers directory, e.g., by an editor. Layers can have architecture specific configuration <layer-name>.<arch>.toml. When something creates a temporary file with two periods in the name, this error may occur. Can you confirm whether this may be the problem?

[raryanpur]

Confirmed - I am now able to reproduce consistently. Vim, for example, will create a swap file named <layer-name>.toml.swp in the layers directory if editing a layer config. If I suspend vim with ctrl + z (not closing the .toml) and invoke ./run-bakery, the error occurs. If I then bring vim to the foreground with fg, close the file, and do ./run-bakery again, the error goes away. The only difference between the two invocations being the presence of the swap file in the first and absence in the second.

[koehlma]

Thanks! Should be fixed with the next release. Is that critical for you? If so, I am happy to publish an early release.

[raryanpur]

Not critical, thank you for confirming!