Heya, running Uyuni 2020.04 we encounter the following issue: If a user 'recycles' a system (through reprovisioning) the following happens: 1) We do not explicitly remove the current system profile in Uyuni nor remove the minion from salt 2) The system will be reprovisioned through our internal deployment system 3) After successful provisioning, we bootstrap the host with the same minion-id The result: The already existing system profile is not updated. Crucial information (like the dbus/systemd machine-id) is not refreshed in the profile leading to 'interesting' errors like these: ``` local: Data failed to compile: ---------- Specified SLS packages.packages_b60982e0e0334b5baffb24ca15e2b98a in saltenv base is not available on the salt master or through a configured fileserver ---------- Specified SLS custom.custom_b60982e0e0334b5baffb24ca15e2b98a in saltenv base is not available on the salt master or through a configured fileserver ``` This is happening because Uyuni is still using the machine-id of the previously deployed system for the generation of salt states. I raised the Taskomatic log level to debug in the hopes of seeing 'something' [TM], but grepping these logs using the machine-ids/hostnames didn't help me either. It seems as if Uyuni is simply skipping the bootstrap/registration procedure if the minion-id is already existing. There does not seem to be the possibility to 'force' a re-registration. So, my question to the Uyuni devs would be: Is the only way to work around this the complete deletion of the system profile or is there a magic flag/configuration setting hidden somewhere that i could specify? Regards, Mattias