[BUG] bootstrap-salt.sh installs ancient version of salt from vendor repository on Debian 10 "buster" arm64

[defanator]

Description

The bootstrap-salt.sh (2023.04.26), being run with onedir 3006, configures saltstack package repository with amd64 arch instead of arm64 on Debian 10 "buster" arm64 instance, thus resulting in installing pretty old version of salt-minion and salt-common packages from Debian's own repos instead of latest 3006 from saltstack repo.

In our case this ended up with an issue similar to this one - saltstack/salt#52289. See saltstack/salt#52289 (comment) for more details.

Setup

• VM running on a cloud service, please be explicit and add details
• used bootstrap to install

Steps to Reproduce the behavior
Launch new Debian 10 arm64 instance e.g. in AWS (we are seeing this with ami-0d224ff05feac2300 in us-west-2) and run salt bootstrap with onedir 3006 options.

Expected behavior

# cat /etc/apt/sources.list.d/salt.list 
deb [signed-by=/usr/share/keyrings/salt-archive-keyring.gpg arch=arm64] https://repo.saltproject.io/salt/py3/debian/10/arm64/3006/ buster main

# dpkg -l | fgrep salt
ii  salt-common                   3006.5                       arm64        shared libraries that salt requires for all packages
ii  salt-minion                   3006.5                       arm64        client package for salt, the distributed remote execution system

Minion starts with latest 3006.x, able to connect to master.

Actual behavior

# cat /etc/apt/sources.list.d/salt.list 
deb [signed-by=/usr/share/keyrings/salt-archive-keyring.gpg arch=amd64] https://repo.saltproject.io/salt/py3/debian/10/amd64/3006/ buster main

# dpkg -l | grep salt
ii  salt-common                   2018.3.4+dfsg1-6+deb10u3     all          shared libraries that salt requires for all packages
ii  salt-minion                   2018.3.4+dfsg1-6+deb10u3     all          client package for salt, the distributed remote execution system

Minion starts with 2018.3.4 (original one available from Debian repos), and fails to connect to master:

2023-12-15 09:14:31,274 [salt.channel.server:375 ][ERROR   ][1631458] Authentication attempt from XXX failed, the public keys did not match. This may be an attempt to compromise the Salt cluster.
2023-12-15 09:14:55,218 [salt.channel.server:375 ][ERROR   ][1631466] Authentication attempt from XXX failed, the public keys did not match. This may be an attempt to compromise the Salt cluster.

Versions Report
N/A

Additional context
saltstack/salt#52289 (comment)

JFTR, this patch fixes the issue for us:

root@ip-10-212-32-87:/tmp/.saltcloud-a444a9ed-3a2a-4e48-870e-c7d3af35c112# diff -u deploy.sh.orig deploy.sh
--- deploy.sh.orig	2023-12-15 08:48:41.712883695 +0000
+++ deploy.sh	2023-12-15 08:59:51.120719109 +0000
@@ -1521,9 +1521,9 @@
             if [ "$_CUSTOM_REPO_URL" != "null" ]; then
                 warn_msg="Support for arm64 is experimental, make sure the custom repository used has the expected structure and contents."
             else
-                # Saltstack official repository has arm64 metadata beginning with Debian 11,
+                # Saltstack official repository has arm64 metadata beginning with Debian 10,
                 # use amd64 repositories on arm64 for anything older, since all pkgs are arch-independent
-                if [ "$DISTRO_NAME_L" = "debian" ] && [ "$DISTRO_MAJOR_VERSION" -lt 11 ]; then
+                if [ "$DISTRO_NAME_L" = "debian" ] && [ "$DISTRO_MAJOR_VERSION" -lt 10 ]; then
                   __REPO_ARCH="amd64"
                 else
                   __REPO_ARCH="arm64"
@@ -9759,4 +9759,4 @@
 
 exit 0
 
-# vim: set sts=4 ts=4 et
\ No newline at end of file
+# vim: set sts=4 ts=4 et

[twangboy]

Would you mind submitting a PR here?

[szmolnar]

Experiencing the same issue: