#3849 Upgrade in fedup environment fails
Closed: Fixed None Opened 8 years ago by mkosek.

Ticket was cloned from Red Hat Bugzilla (product Fedora): Bug 989094

Description of problem:

Upgrading from Fedora18 and FreeIPA server 3.1.5-1 to Fedora 19 and FreeIPA
server 3.2.2-1 fails while upgrading directory server.  The work around of
running ipa-ldap-updater and ipa-upgradeconfig following the failure is

Steps proposed on a meeting:

  1. When RPM upgrade succeeds, it writes the upstream version ID to system (/var/lib/ipa/sysupgrade/sysupgrade.state). When it fails, version is not written

  2. Next time, when ipa service starts and detects that upgrade was not performed (comparing it's version with stored one), it would execute the upgrade before IPA starts

3.4 development was shifted for one month, moving tickets to reflect reality better.

Adjusting time plan - 3.4 development was postponed as we focused on 3.3.x testing and stabilization.

Adjusting time plan - 3.4 development was postponed as we focused on 3.3.x testing and stabilization.

Moving stabilization tickets that do not affect FreeIPA 4.0 release usability in any significant way to 4.0.1 stabilization milestone.

FreeIPA 4.0.1 was released, moving to next bugfixing release milestone.

Alternatively, instead of running the upgrade automatically (may be quite intrusive change), we could at least:

  • Check the version when IPA is started via ipactl
  • Do not start IPA when the versions do not match and report error, pointing to correct upgrade process
  • Add/reuse ipactl force flag to allow IPA to be started when content is not upgraded. IMO, it may be useful in some scenarios as a fall back plan

Given that we plan to potentially convert to systemd native services (#4552), ipactl would be removed and the upgrade check mechanism would need to be completely different than what was proposed.

We should thus only stay with documentation approach present in our release notes and defer the real solution.

See #4800 for a scenario that needs to be covered.

Fixed in 9f049ca .

IPA will not start if upgrade is required.

Manual steps on upgrade is prone to mistakes. I'd like to reopen this ticket and propose an alternative solution:

  1. Add the following to the freeipa.service systemd unit:


  2. Modify {{{ipa-server-upgrade}}} to check the current and target versions of FreeIPA on the system and short-circuit to quick success to avoid slowing down the start-up of a fully-upgraded system.

This should still work with the upgrade environments because the freeipa.service unit should not be started at all, unless something in the system-upgrade.target {{{Requires=}}} or {{{Wants=}}} freeipa.service, which it never should. So what will happen is that the packages would be updated in the system-upgrade environment and then on the first "real" boot of the upgraded system, freeipa.service would be started and then run {{{ipa-server-upgrade}}} first.

freeipa server upgrade may take several minutes,

I'm afraid that user may not expect this delay and try to restart services manually, which may break upgrade.

Opened a new ticket, this milestone has been closed.


Metadata Update from @mkosek:
- Issue assigned to mbasti
- Issue set to the milestone: FreeIPA 4.2

4 years ago

Login to comment on this ticket.