Re: [uyuni-users] Bootstrapped salt minions never appear as systems
I'm quite new to the list, but the only thing that helps recover the SUMA 3.2 (that's what I have as experience) is to do a full reboot. If possible - try a reboot and check. If somebody more experienced can help you - it will be nice to learn how they do it. best Regards, Strahil Nikolov Hi, I also realised there have been no tasks scheduled or run in Schedule > Pending Actions or Schedule > Completed Actions since yesterday 10:25. I have restarted taskomatic since then. Is there something wrong with my database? Cheers -----Original Message----- Date: Fri, 12 Apr 2019 11:30:55 +0000 (UTC) Subject: Re: [uyuni-users] Bootstrapped salt minions never appear as systems To: uyuni-users@opensuse.org, David Mace <david@macemail.co.uk> From: Strahil Nikolov <hunter86_bg@yahoo.com> Hi David, I also have an openSuSE 15 minion and it joined properly. Here is what I did . 1. Checked what is the expected channel name so the bootstrap repo will be successfully created. -> /usr/share/susemgr/mgr_bootstrap_data.py 2. Created the channel with the same name and added several repos Mines are: oss/nonoss base oss/nonoss updates SLE15-uyuni-client-tools 3. Created the bootstrap repo mgr-create-bootstrap-repo 4. Created bootstrap script via web and edited it manually via cli to add the sle15 key 5. Bootstraped via web filling everything necessary. For bootstraping I have used the ip of the machine , but most probably it will work via hostname. Best Regards, Strahil Nikolov В петък, 12 април 2019 г., 6:37:09 ч. Гринуич-4, David Mace <david@macemail.co.uk> написа: Hi, so this was working initially, but something has broke. I am running Uyuni 4.0.1 stable on openSUSE 42.3 host. A new openSUSE Leap 15.0 minion is bootstrapped using bootstrap.sh which was generated using mgr-bootstrap. It joins Salt master and the key shows using command: salt-key -L But the minion never appears in Systems > Systems List Viewing the Salt message bus using salt-run state.event pretty=True I see this: salt/job/20190411153502494691/new { "_stamp": "2019-04-11T14:35:02.495370", "arg": [], "fun": "mgractionchains.resume", "jid": "20190411153502494691", "minions": [ "minion.domain.co.uk" ], "missing": [], "tgt": "minion.domain.co.uk", "tgt_type": "glob", "user": "salt" } salt/job/20190411153502494691/ret/minion.domain.co.uk { "_stamp": "2019-04-11T14:35:06.850239", "cmd": "_return", "fun": "mgractionchains.resume", "fun_args": [], "id": "minion.domain.co.uk", "jid": "20190411153502494691", "metadata": { "suma-action-chain": true }, "out": "nested", "retcode": 254, "return": "'mgractionchains.resume' is not available.", "success": false }
From the minion if I do a salt-call state.apply I get this error:
minion.domain.co.uk:~ # salt-call state.apply [WARNING ] /var/cache/salt/minion/extmods/grains/__pycache__/cpuinfo.cpython- 36.py:20: DeprecationWarning: Use of 'salt.utils.which_bin' detected. This function has been moved to 'salt.utils.path.which_bin' as of Salt 2018.3.0. This warning will be removed in Salt Neon. [ERROR ] Error encountered during module reload. Modules were not reloaded. [WARNING ] /var/cache/salt/minion/extmods/modules/udevdb.py:24: DeprecationWarning: Use of 'salt.utils.which_bin' detected. This function has been moved to 'salt.utils.path.which_bin' as of Salt 2018.3.0. This warning will be removed in Salt Neon. [ERROR ] Template was specified incorrectly: False [ERROR ] Template was specified incorrectly: False local: Data failed to compile: ---------- Specified SLS packages.packages_7a5b9695fb48e3a146f6b8d35caf5e2a in saltenv base is not available on the salt master or through a configured fileserver ---------- Specified SLS custom.custom_7a5b9695fb48e3a146f6b8d35caf5e2a in saltenv base is not available on the salt master or through a configured fileserver Not sure where else to look for errors? -- To unsubscribe, e-mail: uyuni-users+unsubscribe@opensuse.org To contact the owner, e-mail: uyuni-users+owner@opensuse.org
participants (1)
-
Strahil Nikolov