Check target architecture before deploying about morph

[piegamesde]

So I found the root cause for the issue: morph does not check for whether the architecture for which the configuration was built is correct. The configuration will then contain a shebang to a wrong binary, which will lead to failure. A preliminary check would catch this gracefully.

---

To the error message, this is a bug in Bash (actually, they say it's not because it's specified in POSIX, so one could call it a bug in POSIX): If the execution of a shebang fails, Bash will try to interpret the file directly. Of course this makes no sense, and since our file is a perl script we thus get the use: command not found error message.

[piegamesde]

So the root cause remains: the perl from the activation script's shebang is compiled for x86_64 Linux, although the hardware is aarch64. Executing the activation script manually gives me zsh: exec format error instead, which makes a lot more sense. However, when executing from a bash I get the stupid error message again. WTF?

[pinkisemils]

Do you have any good tips for recovering a host that has been morphed with the wrong architecture?
switch-to-configuration is now borked on an x86 host after I mistakenly pushed an aarch64 config, so the zstd on it is not executable.

[piegamesde]

No, I was fortunate enough that the activation script was in Perl and thus failed before it could do any harm. You may try executing the activation script in emulation mode (with binfmt), but I can't guarantee this will work or even is a good idea. Personally, I'd try to manually force it some new configuration and then morph deploy it over.

[pinkisemils]

I copied over the activation script from a previous generation and that made it happy to deploy again.