After running the bootstrap script to register client system to Suse Manager 5.0.1
The bootstrap script runs fine, I can manage the system from SUMA but when trying to install a package with zypper from the client it gives me “no repositories defined”
zypper lr > no repo’s defined
how do you get the repo’s back on your client system ( suse linux enterprise ) after the system is registered in SUMA with bootstrap script
Did you assign a Base and Child Channels to an Activation Key that was then set in the bootstrap script? If so, the client should have repositories assigned and defined.
after bootstrapping the client and reboot I was able so see the repositories on the client . But after a zypper refresh they dissapeared
installing updates via SUMA is working … only missing thing are repo’s on the client system keeping me from installing packages using zypper
after following procedure in this kb : https://www.suse.com/support/kb/doc/?id=000019499 for all channels the repo’s available again on my system
after a reboot and running the bootstrap script again , they are gone again …
Hi,
for me SLES15-SP6 is working. Do you use an suma-proxy or you attach the system direct to the suma-server? I use a cloned chanel, note the origial, but I think thats not the problem.
Did you check the salt-keys ? May there is somethink denied.
removing the system from SUMA and registering it again with bootstrap , repo are back ok after accepting salt key.
Running bootstrap script again breaks it , all repo’s are gone …
Is it possible to check if system is already registered ? if “no” run bootstrap else continue …
Hi,
duble bootstrap is not working for me as well. So you can just check on client site with “zypper lr” if repos present or on the SUMA-web GUI or spacecmd command , or you may use some automation via API call.
VIa command you can check with
mgrctl exec “spacecmd system_list | grep client_hostname”
before you can use spacecmd without enter the container, you must configure the username and PW inside the container in /root/.spacecmd/config. To enter the container, use “mgrctl term”
If the file not exist, just start “spacecmd” and log in. The file will be created
add the lines
username=username
password=pw
then you can use the spacecmd without extra login
Kind regards
Tino
Worked a way around it in ansible by checking for minion_id and with api calls checking if system is registered , check on uuid on hostname etc …
also automated accepting the salt key
so we have a working solution now …
