Hi Victor, thanks again, great hint with state.event! I'm new to salt, seems like a tool that will generally be handy in future! In this case unfortunately it didn't show anything interesting, besides the fact that uyuni is using user "admin" and if using salt on bash it shows my personal uyuni os system account. So i created this bug report, hope it helps :-/ https://github.com/uyuni-project/uyuni/issues/5669 BR Heiner Am Do., 14. Juli 2022 um 13:40 Uhr schrieb Victor Zhestkov < vzhestkov@suse.com>:
In this case I would suggest cleanup the minion and trying to bootstrap again, but before the bootstrapping run the following command: salt-run state.event pretty=true | tee /var/salt-events.txt
to capture the salt responses. Check rhn_web_ui.log for the errors and the events from the minion in the captured file maybe you will find the reason, or create an issue in https://github.com/uyuni-project/uyuni/issues with capture and logs attached.
Victor
On Thu, 2022-07-14 at 12:13 +0200, Heiner Wulfhorst wrote:
Hi Victor,
thanks for your feedback. I also checked for arch. Only "osarch" seems to be relevant. It can also be queried from console as root without any problem and also doesn't look suspicious to me: # salt dehwllhdb21 grains.items|grep -A1 osarch osarch: x86_64
In the meantime i also rebooted my uyuni server, but still no progress - errors keep the same:
Any more ideas, hints, suggestions?
Thanks, Heiner
Am Do., 14. Juli 2022 um 11:32 Uhr schrieb Victor Zhestkov via Uyuni Users
: 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