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

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 users@lists.uyuni-project.org:

...

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

Hi List, hi Victor,

mbussolotto found the solution in https://github.com/uyuni-project/uyuni/issues/5669 : After increasing java.salt_presence_ping_timeout from default (4) to 10 and spacewalk-service reload, uyuni was able to register that client. It would really make sense if notification in uyuni or error in log would say something about that parameter, because the documentation https://www.uyuni-project.org/uyuni-docs/en/uyuni/specialized-guides/large-deployments/tuning.htmlhe linked clearly says: "Tuning is not required on installations of fewer than 1000 clients. Do not perform these instructions on small or medium scale installations." and we only have 62 clients right now.

Thanks, BR, Heiner

Am Do., 14. Juli 2022 um 16:09 Uhr schrieb Heiner Wulfhorst <email@heiwu.de

:

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 users@lists.uyuni-project.org:

...

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