Univention Bugzilla – Bug 47687
UCS-4.2 fails to upgrade to UCS-4.3 - slapd to retstarted due to systemd disabled in chroot
Last modified: 2018-08-28 14:04:53 CEST
I tried to setup a UCS-4.2-4 system and selected "update" on the last page of USS.
The system tried to update itself to UCS-4.3, which failed in setup.log:
> Starting univention-upgrade. Current UCS version is 4.3-0 errata0
> Starting univention-upgrade. Current UCS version is 4.3-0 errata157
> WARNING: A failed.ldif exists.
> Please check https://help.univention.com/t/what-to-do-if-a-failed-ldif-is-found/6432 for further information.
> The update can be started after the failed.ldif has been removed.
> Error: Please check "/var/log/univention/updater.log" for details.
> ERROR: update failed. Please check /var/log/univention/updater.log
1. See Bug #47686
2. In the case of the update happening directly after the initial installation the "updater.log" contains NO hint; everything is in "setup.log"; so the error message is misleading.
3. The final USS screen showed "success" even when there was an error! Afterwards the system was not fully joined:
Warning: 'python-univention-directory-manager' is not configured.
Warning: 'univention-virtual-machine-manager-daemon' is not configured.
The underlying problem for the "failed.ldif" is that one errata restart "slapd" through "systemctl", which does not yet work as the upgrade is still running in the chroot environment of the installer. A manual "/etc/init.d/slapd" started the LDAP server successfully.
4. Similar to Bug #47019 we should (re-)boot after a minor update and/or as soon as possible into the installed system to get rid of the restricted chroot environment, where things are different.
5. I still find is confusing that the installed system upgrades automatically to the UCS release using on the master (Bug #45931). I usually use an older UCS installation media for a reason and would expect it to stay at least at that major.minor-version.