The installer needs to be a lot more verbose about what can go wrong, because currently it comes across as being completely broken, which I suspect is unlikely in a stable release..
End of install is always: Parent DN of cn=custodia,cn=ipa,cn=etc,dc=hoyle,dc=me,dc=uk may not exist, cannot create the entry Parent DN of cn=dogtag,cn=custodia,cn=ipa,cn=etc,dc=hoyle,dc=me,dc=uk may not exist, cannot create the entry Parent DN of cn=tim.hoyle.me.uk,cn=masters,cn=ipa,cn=etc,dc=hoyle,dc=me,dc=uk may not exist, cannot create the entry Parent DN of cn=ca,cn=topology,cn=ipa,cn=etc,dc=hoyle,dc=me,dc=uk may not exist, cannot create the entry default_range: No local ID range and no admins group found. Cannot create default ID range Error retrieving: cn=ipaConfig,cn=etc,dc=hoyle,dc=me,dc=uk Upgrade failed with no such entry [error] RuntimeError: no such entry [cleanup]: stopping directory server [cleanup]: restoring configuration Update failed: no such entry The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information
Tried this two ways: 1. Install fedora workstation, check 'freeipa server' 2. Run ipa-server-install 3. Install crashes.
1 Install fedora server 2. Do a yum update 3. Do yum install freeipa-server 4. Run ipa-server install 5. Install crashes
What should happen: installer stops with an error that indicates what is wrong. Ideally it should complete in a default install ie defaults should be correct.
freeipa-server-4.7.0-1.fc28.x86_64 freeipa-client-4.7.0-1.fc28.x86_64 package ipa-server is not installed package ipa-client is not installed 389-ds-base-1.4.0.16-1.fc28.x86_64 pki-ca-10.6.6-1.fc28.noarch krb5-server-1.16.1-13.fc28.x86_64
<img alt="ipaserver-install.log" src="/freeipa/issue/raw/55d2b9d59f9b763ce855c986b577e9de23622f075c92bb5acd48306684857d7d-ipaserver-install.log" />
I don't know if it is an issue with pagure or not but the installation log is not accessible.
It is not accessible to me either. @tonyhoyle, how can we get access to your log?
I'm seeing the same issue with 4.7, while pre2 still worked fine (both on Ubuntu). I should be able to bisect this..
for me it broke with bumping the WSGI process count from 2, bisect proved this
and that's because the VM had only 1GB of RAM.. giving it 2GB made it survive the install/upgrade
We haven't seen any other reports like this and haven't reproduce it locally, closing as worksforme.
Metadata Update from @rcritten: - Issue close_status updated to: worksforme - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.