make image-metal fails under WSL2.

[Flightkick]

Bug Report

Description

Trying to build an ISO with system extensions enabled using: sudo make image-metal IMAGER_SYSTEM_EXTENSIONS="docker.io/me/custom-image:latest"

Results in:

v1.2.0-alpha.1-21-ge97b9f6d3: Pulling from siderolabs/imager
Digest: sha256:557974f4456e7cb0d306fadde257479d353b303f4aab7d90009e7bedae48bc18
Status: Image is up to date for ghcr.io/siderolabs/imager:v1.2.0-alpha.1-21-ge97b9f6d3
ghcr.io/siderolabs/imager:v1.2.0-alpha.1-21-ge97b9f6d3
: not found ./hack/imager.sh:
/bin/sh: 7: local: not in a function
make: *** [Makefile:236: image-metal] Error 2

https://github.com/siderolabs/talos/blob/e97b9f6d3e14757288d7b2f415b69aef222e8e99/hack/imager.sh#L1-L19

This issue happened while trying to build in a WSL2 environment.

• SO03112 reported the same behavior on StackOverflow local:not in a function for variable and reported that switching to Ubuntu resolved the issue. Switching to an Ubuntu VM resolved the issue for me as well.
• In another unrelated project I found a comment reporting difference in behavior depending on the function syntax used: https://github.com/att/ast/issues/220#issuecomment-350996434 I have not tested this, but it may be helpful for future reference.

PS: The : not found ./hack/imager.sh error seems to print on any error and may be misleading.

---

I encountered this issue while trying to automate Talos Linux builds, discussion here: https://github.com/siderolabs/talos/discussions/6018

[frezbo]

local is a shell built-in, if the currently used shell doesn't support it, it would throw errors.

[Flightkick]

FYI: I'm running Ubuntu 20.04 under WSL2 and it does have local support built in using bash.

[smira]

Talos Makefile depends on bash to be available.

[justingarfield]

FWIW to anyone else landing at this issue while working through the MakeFile and a WSL environment...I was able to successfully build images using Ubuntu-22.04 on WSL w/o any modifications (that is, a fresh Windows 11 Professional / WSL / Ubuntu 22.04 install).

That said, if you're still hitting build errors, and you're sure you installed the pre-reqs, you may be hitting the same problem I was...The build targets will most likely still fail OOTB, especially if you're on the main branch, because the Makefile is attempting to derive which TAG to pull for containers involved in the image creation process (mainly siderolabs/imager:<TAG>). In my case, the default value was appending -dirty to the TAG since I was on a fresh clone of the main branch.

If you're hitting this subsequent issue, please see posts below this one ~~it's as simple as either:~~

~~* Making sure you checkout a tag that has a corresponding release associated with it: e.g. git checkout v1.4.0-alpha.1-42-g426fe9687~~ ~~* Making sure you pass the TAG variable to use when pulling images:~~

• ~~make image-metal -> TAG=latest make image-metal~~
• ~~make sbc-rpi_generic -> TAG=latest make sbc-rpi_generic~~

Note: If you receive an error at the end of the build process re: an _out folder, you may still have to mkdir _out manually, so that the imager can dump-out the image locally after building it (remember that we're building INSIDE a container, not locally).

Hope that helps anyone else that might be here reading this while working through their own custom-built images :)

[frezbo]

note: make image-<target> requires make imager PUSH=true to first build and push the imager image first

[justingarfield]

@frezbo Just so I understand (still learning a lot about Talos at this point)...Does that mean that we should be making our own imager builds before using make image-<target>?

E.g. If I build my own imager on main for instance, then both my imager image and local tag will both resolve with -dirty appended (from the default value in the Makefile) and therefore it would work regardless of doing a checkout <tag / branch> or passing TAG?

Thanks in advance (got all the way here from following guides for Sidero on Raspberry Pi 4 and trying to get a build with a custom driver baked-in)

[frezbo]

E.g. If I build my own imager on main for instance, then both my imager image and local tag will both resolve with -dirty appended (from the default value in the Makefile) and therefore it would work regardless of doing a checkout <tag / branch> or passing TAG?

Yes, always do a make imager, no need to mess with tags and all. Also this make sure that any make image-<target> uses any code changes locally