The original message from you contains the note that it was not able to
detect the architecture of this server. It's better to check full
grains.items output and check for the arch there (most probably
`osarch`). I don't think the issue is related to the machine ID.
On Thu, 2022-07-14 at 08:22 +0000, Heiner W. wrote:
> Hi List,
> here's some additional Information regarding my problem ("Error
> registering minion id: dehwllhdb21")
> What confuses me the most: Uyuni integrated salt master is able to
> work with said client/minion:
> # salt dehwllhdb21 cmd.run date
> Thu Jul 14 09:37:22 CEST 2022
> # salt dehwllhdb21 grains.items|wc -l
> # salt dehwllhdb21 grains.items|grep -A1 'id:'
> What i already tried:
> I removed any salt rpm and config from client several times before
> each bootstrap retry:
> # zypper remove -y venv-salt-minion salt*
> # rm -rf /etc/venv-salt-minion* /etc/salt*
> Also regenerated system uid:
> # rm /etc/machine-id /var/lib/dbus/machine-id
> # dbus-uuidgen --ensure
> # systemd-machine-id-setup
> ... and rebooted the client os.
> I tried bootstrapping with new venv salt and also the old salt-minion
> I even tried using another network interface on my client, with
> another ip, net, route to uyuni.
> Why can't uyuni register the client (get its data/grains) but
> directly using salt as root in bash from uyuni seems to work great?
> What else could i try?