[x86-64-v2] ntp not starting

plexman commented

2022-01-14 00:42:58 +01:00

So I have a mini server based on Gigabyte BRIX with CPU Celeron N3000 which supports x86-64-v2 according to /lib/ld-linux-x86-64.so.2's output:

Subdirectories of glibc-hwcaps directories, in priority order:
  x86-64-v4
  x86-64-v3
  x86-64-v2 (supported, searched)

I'm using the v2 repository as my system wide packages, so everything was x86-64-v2 and noticed that ntpd (NTP daemon) didn't start. Reverted back to normal x86-64 and it worked, daemon starts. Updated only ntp package to x86-64-v2 (to discard system wide packages) and it doesn't start neither. This is the output from journalctl when trying to start the daemon:

Starting Network Time Service...
ene 14 00:29:55 ntpd[2790]: ntpd 4.2.8p15@1.3728-o Wed Dec  8 09:39:35 UTC 2021 (1): Starting
ene 14 00:29:55 ntpd[2790]: Command line: /usr/bin/ntpd -g -u ntp:ntp
ene 14 00:29:55 ntpd[2790]: ----------------------------------------------------
ene 14 00:29:55 ntpd[2790]: ntp-4 is maintained by Network Time Foundation,
ene 14 00:29:55 ntpd[2790]: Inc. (NTF), a non-profit 501(c)(3) public-benefit
ene 14 00:29:55 ntpd[2790]: corporation.  Support and training for ntp-4 are
ene 14 00:29:55 ntpd[2790]: available at https://www.nwtime.org/support
ene 14 00:29:55 ntpd[2790]: ----------------------------------------------------
ene 14 00:29:55 ntpd[2792]: proto: precision = 0.188 usec (-22)
ene 14 00:29:55 ntpd[2792]: recvbuff.c:372: REQUIRE((((void *)0) == pf->phead && ((void *)0) == pf->pptail) || (((void *)0) != pf->phead && ((void *)0) != pf->pptail)) failed
ene 14 00:29:55 ntpd[2792]: exiting (due to assertion failure)
ene 14 00:29:55 ntpd[2790]: daemon child died with signal 6
ene 14 00:29:55 systemd[1]: ntpd.service: Control process exited, code=exited, status=70/SOFTWARE
ene 14 00:29:55 systemd[1]: ntpd.service: Failed with result 'exit-code'.
ene 14 00:29:55 systemd[1]: Failed to start Network Time Service.

To complement the bug, I'm using two other servers with system-wide x86-64-v3 without any errors on ntp daemon, so apparently only affects v2.

Let me know if more debugging is needed.

So I have a mini server based on Gigabyte BRIX with CPU Celeron N3000 which supports x86-64-v2 according to /lib/ld-linux-x86-64.so.2's output: ``` Subdirectories of glibc-hwcaps directories, in priority order: x86-64-v4 x86-64-v3 x86-64-v2 (supported, searched) ``` I'm using the v2 repository as my system wide packages, so everything was x86-64-v2 and noticed that ntpd (NTP daemon) didn't start. Reverted back to normal x86-64 and it worked, daemon starts. Updated only ntp package to x86-64-v2 (to discard system wide packages) and it doesn't start neither. This is the output from journalctl when trying to start the daemon: ``` Starting Network Time Service... ene 14 00:29:55 ntpd[2790]: ntpd 4.2.8p15@1.3728-o Wed Dec 8 09:39:35 UTC 2021 (1): Starting ene 14 00:29:55 ntpd[2790]: Command line: /usr/bin/ntpd -g -u ntp:ntp ene 14 00:29:55 ntpd[2790]: ---------------------------------------------------- ene 14 00:29:55 ntpd[2790]: ntp-4 is maintained by Network Time Foundation, ene 14 00:29:55 ntpd[2790]: Inc. (NTF), a non-profit 501(c)(3) public-benefit ene 14 00:29:55 ntpd[2790]: corporation. Support and training for ntp-4 are ene 14 00:29:55 ntpd[2790]: available at https://www.nwtime.org/support ene 14 00:29:55 ntpd[2790]: ---------------------------------------------------- ene 14 00:29:55 ntpd[2792]: proto: precision = 0.188 usec (-22) ene 14 00:29:55 ntpd[2792]: recvbuff.c:372: REQUIRE((((void *)0) == pf->phead && ((void *)0) == pf->pptail) || (((void *)0) != pf->phead && ((void *)0) != pf->pptail)) failed ene 14 00:29:55 ntpd[2792]: exiting (due to assertion failure) ene 14 00:29:55 ntpd[2790]: daemon child died with signal 6 ene 14 00:29:55 systemd[1]: ntpd.service: Control process exited, code=exited, status=70/SOFTWARE ene 14 00:29:55 systemd[1]: ntpd.service: Failed with result 'exit-code'. ene 14 00:29:55 systemd[1]: Failed to start Network Time Service. ``` To complement the bug, I'm using two other servers with system-wide x86-64-v3 without any errors on ntp daemon, so apparently only affects v2. Let me know if more debugging is needed.