Hi Heiner. 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. Victor 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 dehwllhdb21: Thu Jul 14 09:37:22 CEST 2022 # salt dehwllhdb21 grains.items|wc -l 10118 # salt dehwllhdb21 grains.items|grep -A1 'id:' gid: 0 id: dehwllhdb21 lsb_distrib_id: SLES machine_id: a0a85c7a8e4c611fa66868da62cfc837 pid: 5881 server_id: 444072978 uid: 0 uuid: 0a024321-7508-5d5c-8f34-dc250ec0c11e
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 packages.
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?
Thanks, Heiner