# Upgrade to Rocky9.3 breaks freeipa running instalation, bind core dump

**URL:** <https://forums.rockylinux.org/t/upgrade-to-rocky9-3-breaks-freeipa-running-instalation-bind-core-dump/13709>\
**Category:** Rocky Linux Help & Support\
**Tags:** rocky-linux-9\
**Created:** [April 24, 2024, 12:50am UTC](https://forums.rockylinux.org/t/upgrade-to-rocky9-3-breaks-freeipa-running-instalation-bind-core-dump/13709 "2024-04-24T00:50:04Z")\
**Posts on this page:** 14\
**Page:** 1

<div class="post-metadata">

**Author:** ![apereira](https://avatars.discourse-cdn.com/v4/letter/a/c57346/32.png) [@apereira](https://forums.rockylinux.org/u/apereira)\
**Post date:** [April 24, 2024, 12:50am UTC](https://forums.rockylinux.org/t/upgrade-to-rocky9-3-breaks-freeipa-running-instalation-bind-core-dump/13709/1 "2024-04-24T00:50:06Z")

</div>

After upgrade to RL9.3 and **bind-9.16.23-14** , when loading configuration system fails badly dumping core.

This is the startup of bind …

Apr 23 21:03:27 ipa named[7564]: starting BIND 9.16.23-RH (Extended Support Version) id:fde3b1f  
Apr 23 21:03:27 ipa named[7564]: running on Linux x86\_64 5.14.0-362.24.1.el9\_3.0.1.x86\_64 #1 SMP PREEMPT\_DYNAMIC Thu Apr 4 22:31:43 UTC 2024

And this is the dump …

Apr 23 21:03:27 ipa named[7564]: configuring command channel from ‘/etc/rndc.key’  
Apr 23 21:03:27 ipa named[7564]: command channel listening on 127.0.0.1#953  
Apr 23 21:03:27 ipa named[7564]: configuring command channel from ‘/etc/rndc.key’  
Apr 23 21:03:27 ipa named[7564]: command channel listening on ::1#953  
Apr 23 21:03:27 ipa named[7564]: managed-keys-zone: loaded serial 3731  
Apr 23 21:03:27 ipa named[7564]: …/…/…/lib/isc/hp.c:156: INSIST(tid() \< isc\_\_hp\_max\_threads) failed, back trace  
Apr 23 21:03:27 ipa named[7564]: #0 0x560f2da54621 in ??  
Apr 23 21:03:27 ipa named[7564]: #1 0x7fb9bd78b4e0 in ??  
Apr 23 21:03:27 ipa named[7564]: #2 0x7fb9bd78fa4d in ??  
Apr 23 21:03:27 ipa named[7564]: #3 0x7fb9bd7bc99c in ??  
Apr 23 21:03:27 ipa named[7564]: #4 0x7fb9bd7a7d15 in ??  
Apr 23 21:03:27 ipa named[7564]: #5 0x7fb9bd7c50fc in ??  
Apr 23 21:03:27 ipa named[7564]: #6 0x7fb9b90eab93 in ??  
Apr 23 21:03:27 ipa named[7564]: #7 0x7fb9b90eb354 in ??  
Apr 23 21:03:27 ipa named[7564]: #8 0x7fb9b90a2bfa in ??  
Apr 23 21:03:27 ipa named[7564]: #9 0x7fb9b90a3943 in ??  
Apr 23 21:03:27 ipa named[7564]: #10 0x7fb9b90ec585 in ??  
Apr 23 21:03:27 ipa named[7564]: #11 0x7fb9b90eca43 in ??  
Apr 23 21:03:27 ipa named[7564]: #12 0x7fb9bd7c468a in ??  
Apr 23 21:03:27 ipa named[7564]: #13 0x7fb9bcc9f802 in ??  
Apr 23 21:03:27 ipa named[7564]: #14 0x7fb9bcc3f450 in ??  
Apr 23 21:03:27 ipa named[7564]: exiting (due to assertion failure)  
Apr 23 21:03:27 ipa systemd[1]: Started Process Core Dump (PID 7571/UID 0).  
Apr 23 21:03:27 ipa systemd-coredump[7572]: Process 7564 (named) of user 25 dumped core.#012#012Stack trace of thread 7569:#012#0 0x00007fb9bcca154c \_\_pthread\_kill\_implementation (libc.so.6 + 0xa154c)#012#1 0x00007fb9bcc54d06 raise (libc.so.6 + 0x54d06)#012#2 0x00007fb9bcc287f3 abort (libc.so.6 + 0x287f3)#012#3 0x0000560f2da515b5 assertion\_failed.cold (named + 0x1c5b5)#012#4 0x00007fb9bd78b4e0 isc\_assertion\_failed (libisc-9.16.23-RH.so + 0x1c4e0)#012#5 0x00007fb9bd78fa4d isc\_hp\_protect (libisc-9.16.23-RH.so + 0x20a4d)#012#6 0x00007fb9bd7bc99c isc\_queue\_enqueue (libisc-9.16.23-RH.so + 0x4d99c)#012#7 0x00007fb9bd7a7d15 isc\_\_nm\_enqueue\_ievent (libisc-9.16.23-RH.so + 0x38d15)#012#8 0x00007fb9bd7c50fc isc\_task\_sendto (libisc-9.16.23-RH.so + 0x560fc)#012#9 0x00007fb9b90eab93 syncrepl\_update (ldap.so + 0x1cb93)#012#10 0x00007fb9b90eb354 ldap\_sync\_search\_entry (ldap.so + 0x1d354)#012#11 0x00007fb9b90a2bfa ldap\_sync\_search\_entry (libldap.so.2 + 0x45bfa)#012#12 0x00007fb9b90a3943 ldap\_sync\_init (libldap.so.2 + 0x46943)#012#13 0x00007fb9b90ec585 ldap\_sync\_doit (ldap.so + 0x1e585)#012#14 0x00007fb9b90eca43 ldap\_syncrepl\_watcher.lto\_priv.0 (ldap.so + 0x1ea43)#012#15 0x00007fb9bd7c468a isc\_\_trampoline\_run (libisc-9.16.23-RH.so + 0x5568a)#012#16 0x00007fb9bcc9f802 start\_thread (libc.so.6 + 0x9f802)#012#17 0x00007fb9bcc3f450 \_\_clone3 (libc.so.6 + 0x3f450)#012#012Stack trace of thread 7564:#012#0 0x00007fb9bcc55aca \_\_sigtimedwait (libc.so.6 + 0x55aca)#012#1 0x00007fb9bcc5510c sigwait (libc.so.6 + 0x5510c)#012#2 0x00007fb9bd795003 isc\_app\_ctxrun (libisc-9.16.23-RH.so + 0x26003)#012#3 0x00007fb9bd7952cc isc\_app\_run (libisc-9.16.23-RH.so + 0x262cc)#012#4 0x0000560f2da5245a main (named + 0x1d45a)#012#5 0x00007fb9bcc3feb0 \_\_libc\_start\_call\_main (libc.so.6 + 0x3feb0)#012#6 0x00007fb9bcc3ff60 \_\_libc\_start\_main@@GLIBC\_2.34 (libc.so.6 + 0x3ff60)#012#7 0x0000560f2da52f85 \_start (named + 0x1df85)#012#012Stack trace of thread 7567:#012#0 0x00007fb9bcc9c39a \_\_futex\_abstimed\_wait\_common (libc.so.6 + 0x9c39a)#012#1 0x00007fb9bcc9eea4 pthread\_cond\_timedwait@@GLIBC\_2.3.2 (libc.so.6 + 0x9eea4)#012#2 0x00007fb9bd7d6180 isc\_condition\_waituntil (libisc-9.16.23-RH.so + 0x67180)#012#3 0x00007fb9bd7c83ef run (libisc-9.16.23-RH.so + 0x593ef)#012#4 0x00007fb9bd7c468a isc\_\_trampoline\_run (libisc-9.16.23-RH.so + 0x5568a)#012#5 0x00007fb9bcc9f802 start\_thread (libc.so.6 + 0x9f802)#012#6 0x00007fb9bcc3f450 \_\_clone3 (libc.so.6 + 0x3f450)#012#012Stack trace of thread 7568:#012#0 0x00007fb9bcd4ea6e epoll\_wait (libc.so.6 + 0x14ea6e)#012#1 0x00007fb9bd7cfb7c netthread (libisc-9.16.23-RH.so + 0x60b7c)#012#2 0x00007fb9bd7c468a isc\_\_trampoline\_run (libisc-9.16.23-RH.so + 0x5568a)#012#3 0x00007fb9bcc9f802 start\_thread (libc.so.6 + 0x9f802)#012#4 0x00007fb9bcc3f450 \_\_clone3 (libc.so.6 + 0x3f450)#012#012Stack trace of thread 7566:#012#0 0x00007fb9bcc3e6bb \_\_sched\_yield (libc.so.6 + 0x3e6bb)#012#1 0x00007fb9bd5bdb75 uv\_\_async\_io.part.0 (libuv.so.1 + 0xab75)#012#2 0x00007fb9bd5d985e uv\_\_io\_poll.part.0 (libuv.so.1 + 0x2685e)#012#3 0x00007fb9bd5c35a8 uv\_run (libuv.so.1 + 0x105a8)#012#4 0x00007fb9bd7b1b5b nm\_thread (libisc-9.16.23-RH.so + 0x42b5b)#012#5 0x00007fb9bd7c468a isc\_\_trampoline\_run (libisc-9.16.23-RH.so + 0x5568a)#012#6 0x00007fb9bcc9f802 start\_thread (libc.so.6 + 0x9f802)#012#7 0x00007fb9bcc3f450 \_\_clone3 (libc.so.6 + 0x3f450)#012#012Stack trace of thread 7565:#012#0 0x00007fb9bcd3eb7f \_\_write (libc.so.6 + 0x13eb7f)#012#1 0x00007fb9bd5c2db1 uv\_async\_send (libuv.so.1 + 0xfdb1)#012#2 0x00007fb9bd7c50fc isc\_task\_sendto (libisc-9.16.23-RH.so + 0x560fc)#012#3 0x00007fb9bd91c263 dns\_resolver\_createfetch (libdns-9.16.23-RH.so + 0x11c263)#012#4 0x00007fb9bd96ffbd zone\_refreshkeys.lto\_priv.0 (libdns-9.16.23-RH.so + 0x16ffbd)#012#5 0x00007fb9bd9789cf zone\_timer.lto\_priv.0 (libdns-9.16.23-RH.so + 0x1789cf)#012#6 0x00007fb9bd7c68ad isc\_task\_run (libisc-9.16.23-RH.so + 0x578ad)#012#7 0x00007fb9bd7b1929 process\_netievent (libisc-9.16.23-RH.so + 0x42929)#012#8 0x00007fb9bd7b1aa5 process\_queue (libisc-9.16.23-RH.so + 0x42aa5)#012#9 0x00007fb9bd7b2297 async\_cb (libisc-9.16.23-RH.so + 0x43297)#012#10 0x00007fb9bd5bdb3d uv\_\_async\_io.part.0 (libuv.so.1 + 0xab3d)#012#11 0x00007fb9bd5d985e uv\_\_io\_poll.part.0 (libuv.so.1 + 0x2685e)#012#12 0x00007fb9bd5c35a8 uv\_run (libuv.so.1 + 0x105a8)#012#13 0x00007fb9bd7b1b37 nm\_thread (libisc-9.16.23-RH.so + 0x42b37)#012#14 0x00007fb9bd7c468a isc\_\_trampoline\_run (libisc-9.16.23-RH.so + 0x5568a)#012#15 0x00007fb9bcc9f802 start\_thread (libc.so.6 + 0x9f802)#012#16 0x00007fb9bcc3f450 \_\_clone3 (libc.so.6 + 0x3f450)#012ELF object binary architecture: AMD x86-64  
Apr 23 21:03:27 ipa systemd[1]: named.service: Control process exited, code=exited, status=1/FAILURE  
Apr 23 21:03:27 ipa systemd[1]: named.service: Killing process 7569 (isc-net-0000) with signal SIGKILL.

The solution I found was to downgrade just the involved packages to 9.16.23-11 …

bind-9.16.23-11.el9\_2.2.x86\_64.rpm  
bind-dnssec-doc-9.16.23-11.el9\_2.2.noarch.rpm  
bind-dnssec-utils-9.16.23-11.el9\_2.2.x86\_64.rpm  
bind-dyndb-ldap-11.9-8.el9\_1.x86\_64.rpm  
bind-libs-9.16.23-11.el9\_2.2.x86\_64.rpm  
bind-license-9.16.23-11.el9\_2.2.noarch.rpm  
bind-utils-9.16.23-11.el9\_2.2.x86\_64.rpm  
python3-bind-9.16.23-11.el9\_2.2.noarch.rpm

---

<div class="post-metadata">

**Author:** ![label](https://avatars.discourse-cdn.com/v4/letter/l/c5a1d2/32.png) [@label](https://forums.rockylinux.org/u/label)\
**Post date:** [April 24, 2024, 1:41am UTC](https://forums.rockylinux.org/t/upgrade-to-rocky9-3-breaks-freeipa-running-instalation-bind-core-dump/13709/2 "2024-04-24T01:41:03Z")

</div>

Looking at my IPA systems, they are fully updated and they do not exhibit this behavior.

Did you do a full update or did you cherry pick updates? When you updated from 9.2 to 9.3, did you reboot the system?

---

<div class="post-metadata">

**Author:** ![apereira](https://avatars.discourse-cdn.com/v4/letter/a/c57346/32.png) [@apereira](https://forums.rockylinux.org/u/apereira)\
**Post date:** [April 24, 2024, 3:36am UTC](https://forums.rockylinux.org/t/upgrade-to-rocky9-3-breaks-freeipa-running-instalation-bind-core-dump/13709/3 "2024-04-24T03:36:51Z")

</div>

full update 9.2 to 9.3 and after restart the system behave this way

---

<div class="post-metadata">

**Author:** ![gerry666uk](https://avatars.discourse-cdn.com/v4/letter/g/dbc845/32.png) [@gerry666uk](https://forums.rockylinux.org/u/gerry666uk)\
**Post date:** [April 24, 2024, 9:15pm UTC](https://forums.rockylinux.org/t/upgrade-to-rocky9-3-breaks-freeipa-running-instalation-bind-core-dump/13709/4 "2024-04-24T21:15:12Z")

</div>

It seems to be complaining about “hp max threads”, check any config related to threading. Why does it say “extended support version”?

---

<div class="post-metadata">

**Author:** ![label](https://avatars.discourse-cdn.com/v4/letter/l/c5a1d2/32.png) [@label](https://forums.rockylinux.org/u/label)\
**Post date:** [April 24, 2024, 9:39pm UTC](https://forums.rockylinux.org/t/upgrade-to-rocky9-3-breaks-freeipa-running-instalation-bind-core-dump/13709/5 "2024-04-24T21:39:18Z")

</div>

```auto
Apr 23 18:39:26 ipa01 named[5121]: starting BIND 9.16.23-RH (Extended Support Version) <id:fde3b1f>

```

That’s just what it reports and is normal in our packages.

---

<div class="post-metadata">

**Author:** ![smeemcgee](https://avatars.discourse-cdn.com/v4/letter/s/b2d939/32.png) [@smeemcgee](https://forums.rockylinux.org/u/smeemcgee)\
**Post date:** [April 28, 2024, 4:34am UTC](https://forums.rockylinux.org/t/upgrade-to-rocky9-3-breaks-freeipa-running-instalation-bind-core-dump/13709/6 "2024-04-28T04:34:06Z")

</div>

Just to add to this, the upgrade broke bind for me aswell:

Apr 28 04:21:35 ipa named[2891]: …/…/…/lib/isc/hp.c:156: INSIST(tid() \< isc\_\_hp\_max\_threads) failed, back trace  
Apr 28 04:21:35 ipa named[2891]: #0 0x555c7ae04621 in ??  
Apr 28 04:21:35 ipa named[2891]: #1 0x7ffaea38b4e0 in ??  
Apr 28 04:21:35 ipa named[2891]: #2 0x7ffaea38fa4d in ??  
Apr 28 04:21:35 ipa named[2891]: #3 0x7ffaea3bc99c in ??  
Apr 28 04:21:35 ipa named[2891]: #4 0x7ffaea3a7d15 in ??  
Apr 28 04:21:35 ipa named[2891]: #5 0x7ffaea3c50fc in ??  
Apr 28 04:21:35 ipa named[2891]: #6 0x7ffae5c7eb93 in ??  
Apr 28 04:21:35 ipa named[2891]: #7 0x7ffae5c7f354 in ??  
Apr 28 04:21:35 ipa named[2891]: #8 0x7ffae5c40bfa in ??  
Apr 28 04:21:35 ipa named[2891]: #9 0x7ffae5c41943 in ??  
Apr 28 04:21:35 ipa named[2891]: #10 0x7ffae5c80585 in ??  
Apr 28 04:21:35 ipa named[2891]: #11 0x7ffae5c80998 in ??  
Apr 28 04:21:35 ipa named[2891]: #12 0x7ffaea3c468a in ??  
Apr 28 04:21:35 ipa named[2891]: #13 0x7ffae989f802 in ??  
Apr 28 04:21:35 ipa named[2891]: #14 0x7ffae983f450 in ??  
Apr 28 04:21:35 ipa named[2891]: exiting (due to assertion failure)

---

<div class="post-metadata">

**Author:** ![smeemcgee](https://avatars.discourse-cdn.com/v4/letter/s/b2d939/32.png) [@smeemcgee](https://forums.rockylinux.org/u/smeemcgee)\
**Post date:** [April 28, 2024, 4:52am UTC](https://forums.rockylinux.org/t/upgrade-to-rocky9-3-breaks-freeipa-running-instalation-bind-core-dump/13709/7 "2024-04-28T04:52:54Z")

</div>

> [@apereira](#):
>
> bind-9.16.23-11.el9\_2.2.x86\_64.rpm  
> bind-dnssec-doc-9.16.23-11.el9\_2.2.noarch.rpm  
> bind-dnssec-utils-9.16.23-11.el9\_2.2.x86\_64.rpm  
> bind-dyndb-ldap-11.9-8.el9\_1.x86\_64.rpm  
> bind-libs-9.16.23-11.el9\_2.2.x86\_64.rpm  
> bind-license-9.16.23-11.el9\_2.2.noarch.rpm  
> bind-utils-9.16.23-11.el9\_2.2.x86\_64.rpm  
> python3-bind-9.16.23-11.el9\_2.2.noarch.rpm

Can you provide any info on downgrading to these?  
`dnf downgrade bind`  
gives me:

```auto
Package bind of lowest version already installed, cannot downgrade it.

```

---

<div class="post-metadata">

**Author:** ![apereira](https://avatars.discourse-cdn.com/v4/letter/a/c57346/32.png) [@apereira](https://forums.rockylinux.org/u/apereira)\
**Post date:** [May 2, 2024, 6:57pm UTC](https://forums.rockylinux.org/t/upgrade-to-rocky9-3-breaks-freeipa-running-instalation-bind-core-dump/13709/8 "2024-05-02T18:57:59Z")

</div>

The system does not provide a direct path to downgrade.  
I’ve look in the repos the previous version and manually download it.  
Then aplly the downgrade.

---

<div class="post-metadata">

**Author:** ![label](https://avatars.discourse-cdn.com/v4/letter/l/c5a1d2/32.png) [@label](https://forums.rockylinux.org/u/label)\
**Post date:** [May 2, 2024, 7:55pm UTC](https://forums.rockylinux.org/t/upgrade-to-rocky9-3-breaks-freeipa-running-instalation-bind-core-dump/13709/9 "2024-05-02T19:55:33Z")

</div>

I’m still failing to reproduce this issue in at least three IPA domains. In the Rocky Linux infrastructure for example, our IPA and bind versions are at the latest as provided by 9.3. In 9.4, the versions will upgrade again.

It would be helpful to know the hardware specs of these systems, the configuration that has been done (such as hardening, e.g. CIS benchmarks), and other potential changes. I would ask to install `sos` and run `sos report`, but the forums do not allow uploading large archives like that.

---

<div class="post-metadata">

**Author:** ![ferr](https://avatars.discourse-cdn.com/v4/letter/f/a88e57/32.png) [@ferr](https://forums.rockylinux.org/u/ferr)\
**Post date:** [May 4, 2024, 6:43pm UTC](https://forums.rockylinux.org/t/upgrade-to-rocky9-3-breaks-freeipa-running-instalation-bind-core-dump/13709/10 "2024-05-04T18:43:08Z")

</div>

i got the same error message on my IPA cluster on rocky9 docker container with archlinux as docker host.  
im using freeipa/freeipa-server:rocky-9 which got updated few days ago

see [Docker](https://hub.docker.com/r/freeipa/freeipa-server/tags?page=&page_size=&ordering=&name=rocky)

After a bit of testing i found out bind does start after few tries, sometimes i need to try 1-2 times sometimes more like 8-10 times to get bind started, if it does not start i get the same error message.  
this was also the solution to get ipa updated, starting a paralel shell making sure bind is running while update.  
After the update i noticed that my IPA instance does not start in the container as it should. so after i started the container, i need to exec a bash and start bind manually, than start IPA again. after that my IPA is up and running fine, but its not reboot/restart proof.

affected bind packages:  
[root@ipa1 /]# rpm -qa | grep ^bind  
bind-license-9.16.23-14.el9\_3.4.noarch  
bind-libs-9.16.23-14.el9\_3.4.x86\_64  
bind-utils-9.16.23-14.el9\_3.4.x86\_64  
bind-dnssec-doc-9.16.23-14.el9\_3.4.noarch  
bind-dnssec-utils-9.16.23-14.el9\_3.4.x86\_64  
bind-9.16.23-14.el9\_3.4.x86\_64  
bind-dyndb-ldap-11.9-8.el9\_3.3.x86\_64  
[root@ipa1 /]#

---

<div class="post-metadata">

**Author:** ![tomkep](https://avatars.discourse-cdn.com/v4/letter/t/8e8cbc/32.png) [@tomkep](https://forums.rockylinux.org/u/tomkep)\
**Post date:** [May 7, 2024, 7:03pm UTC](https://forums.rockylinux.org/t/upgrade-to-rocky9-3-breaks-freeipa-running-instalation-bind-core-dump/13709/11 "2024-05-07T19:03:15Z")

</div>

I am on Almalinux and also see this problem.

It started with the upgrade to bind-9.16.23-14.el9\_3.4.x86\_64.rpm and bind-dyndb-ldap-11.9-8.el9\_3.3.alma.1.x86\_64.rpm, works with bind-9.16.23-14.el9\_3.x86\_64.rpm and bind-dyndb-ldap-11.9-8.el9\_1.x86\_64.rpm. The interesting part is that it only fails on one system (out of 5 VMs and 2 on real HW). And that VM where it fails has ONLY ONE CPU. All other systems have at least two cores.

So I tried to lower number of VCPUs on one of the other VMs and here it goes - it crashed after the reboot, when starting named. So I guess it is somehow related to the number of available cores.

---

<div class="post-metadata">

**Author:** ![label](https://avatars.discourse-cdn.com/v4/letter/l/c5a1d2/32.png) [@label](https://forums.rockylinux.org/u/label)\
**Post date:** [May 7, 2024, 10:46pm UTC](https://forums.rockylinux.org/t/upgrade-to-rocky9-3-breaks-freeipa-running-instalation-bind-core-dump/13709/12 "2024-05-07T22:46:08Z")

</div>

> [@tomkep](#):
>
> And that VM where it fails has ONLY ONE CPU

Thank you for noting how many CPU’s you attempted to use or systems that were crashing with just 1 CPU. I asked for system specs from the OP and others in this thread and haven’t received anything, so this nails down an important thing that anyone running IPA in general should know about hardware resources required.

> [@gerry666uk](#):
>
> It seems to be complaining about “hp max threads”

This should’ve been the part that rang a bell.

The official documentation for IPA does not talk about CPU cores, it talks about RAM (4GB of RAM, at a minimum) and storage (10GB of storage minimum). Given that there are several key components in an IPA installation (bind + bind’s dyndb ldap plugin, dogtag CA which uses java, krb5kdc, 389DS), it stands to reason that 1 CPU is simply not enough. I have always recommended at least 2 CPU’s for this very reason.

If you have at least 2 CPU cores and are still having this issue, please let us know and we can continue to troubleshoot. Please note that we are also planning to push 9.4 soon.

---

<div class="post-metadata">

**Author:** ![wilcoNL](https://avatars.discourse-cdn.com/v4/letter/w/b782af/32.png) [@wilcoNL](https://forums.rockylinux.org/u/wilcoNL)\
**Post date:** [May 16, 2024, 9:15am UTC](https://forums.rockylinux.org/t/upgrade-to-rocky9-3-breaks-freeipa-running-instalation-bind-core-dump/13709/13 "2024-05-16T09:15:08Z")

</div>

Had the same issue.  
Reinstalled a test environment with Hyper-V on windows 11, no problems there. So back to my ESXi 7.02 server. And reinstalled a fresh, 9.4 rocky server and installed a replica. Same issue as described in this topic.

So updated to 2 CPU’s, revert to a previos snapshot of my server and reinstalled the replica again. This time, no problems at all. I installed the replica server, CA and DNS seperate from each other, so it was easier to revert the snapshots to a specific part of the installation.

Hope this helps a little, looks like an issue between VMWare ESXi, the DNS install and the number of CPU’s.  
My server had 8 GB RAM so no complaints about the memory usage.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/flex020/uploads/rockylinux/original/1X/91b7219eec10e30013422e4df76c1d898711a5d5.svg) [@system](https://forums.rockylinux.org/u/system)\
**Post date:** [July 15, 2024, 9:17am UTC](https://forums.rockylinux.org/t/upgrade-to-rocky9-3-breaks-freeipa-running-instalation-bind-core-dump/13709/14 "2024-07-15T09:17:22Z")

</div>

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.