make dvd hanging

[chaichairiko]

Hi,
I have tried to compile an image twice using make dvd.
In both cases make gets stuck here:
libtool: compile: cc -DHAVE_CONFIG_H -I. -I.. -I.. -I.. -I/usr/local/include/dbus-1.0 -I/usr/local/lib/dbus-1.0/include -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include -pthread -DDBUS_COMPILATION=1 -DDBUS_LOCALEDIR=\"/usr/local/@DATADIRNAME@/locale\" -isystem /usr/local/include -O2 -pipe -DHARDENEDBSD -fPIC -fstack-protector-all -isystem /usr/local/include -fno-strict-aliasing -Wall -Wchar-subscripts -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wcast-align -Wfloat-equal -Wsign-compare -MT dbus-gvalue-parse-variant.lo -MD -MP -MF .deps/dbus-gvalue-parse-variant.Tpo -c dbus-gvalue-parse-variant.c -fPIE -o dbus-gvalue-parse-variant.o >/dev/null 2>&1 libtool: compile: cc -DHAVE_CONFIG_H -I. -I.. -I.. -I.. -I/usr/local/include/dbus-1.0 -I/usr/local/lib/dbus-1.0/include -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include -pthread -DDBUS_COMPILATION=1 -DDBUS_LOCALEDIR=\"/usr/local/@DATADIRNAME@/locale\" -isystem /usr/local/include -O2 -pipe -DHARDENEDBSD -fPIC -fstack-protector-all -isystem /usr/local/include -fno-strict-aliasing -Wall -Wchar-subscripts -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wcast-align -Wfloat-equal -Wsign-compare -MT dbus-gparser.lo -MD -MP -MF .deps/dbus-gparser.Tpo -c dbus-gparser.c -fPIE -o dbus-gparser.o >/dev/null 2>&1

Is there some way to debug this? I will keep the make running on idle for the time being as it takes around 6 hours to get here

[fichtner]

It's hard to say without build system info (most relevantly RAM, CPU). The full packages batch usually takes 6-8 hours every day and it runs fine. The logs are here... https://nightly.opnsense.org/20.7/amd64/logs/

[chaichairiko]

Can I take a look on the process in which the nightly is run so that I can recreate it locally?

[chaichairiko]

@fichtner
RAM:
root@freebsd:/home/ec2-user # grep memory /var/run/dmesg.boot
real memory = 35058089984 (33434 MB)
avail memory = 33004916736 (31475 MB)

CPUS:
root@freebsd:/home/ec2-user # dmesg | grep SMP
FreeBSD/SMP: Multiprocessor System Detected: 16 CPUs
FreeBSD/SMP: 1 package(s) x 2 cache groups x 4 core(s) x 2 hardware threads

[chaichairiko]

I just found this issue: #157

I think I am looking at the same issue. If I have to have suricata, what can I do?

[fichtner]

Huh, are you cross-compiling? Your log said dbus, not rust.

I’m not sure about EC2 issues here. Normally hypervisor doesn’t matter, but it is also clear that the build itself is ok so it’s something specific to the instance. RAM and CPU look fine.

[chaichairiko]

No.
I am trying to zero-in in the issues, so I ran each stage independently as well.
When running make ports, I get stuck here:

94838  0- I    0:00.01 - sh ./ports.sh
96100  0- I    0:00.00 `-- /bin/sh -s
96104  0- I    0:00.00   `-- /bin/sh -s
  928  0- I    0:00.03     `-- make -s -C /usr/ports/lang/rust install USE_PACKAGE_DEPENDS=yes PACKAGES=/.pkg-cache PRODUCT_ARCH=amd64 PRODUCT_FLAVOUR=OpenSSL PRODUCT_PERL=5.32 PRODUCT_PHP=73 PRODUCT_PYTHON=37 PRODUCT_RUBY=26 UNAME_r=12.1-RELEASE-p12-HBSD
 6244  0- I    0:00.06       `-- /usr/local/bin/python3.7 x.py build --jobs=16
 6394  0- I    0:00.17         `-- /usr/obj/usr/ports/lang/rust/work/rustc-1.48.0-src/build/bootstrap/debug/bootstrap build --jobs=16
13091  0- I    0:00.01           |-- /usr/obj/usr/ports/lang/rust/work/bootstrap/bin/cargo build --target x86_64-unknown-freebsd -Zbinary-dep-depinfo -j 16 -v --release --frozen --features  llvm max_level_info --manifest-path /usr/obj/usr/ports/lang/rust/work/rustc-1.
13091  0- S    0:16.79           `-- /usr/obj/usr/ports/lang/rust/work/bootstrap/bin/cargo build --target x86_64-unknown-freebsd -Zbinary-dep-depinfo -j 16 -v --release --frozen --features  llvm max_level_info --manifest-path /usr/obj/usr/ports/lang/rust/work/rustc-1.

[fichtner]

And I'm just trying to see and match what your initial post said: dbus-gparser.c is a file in D-Bus implementation which means rust was built successfully in that particular run. It makes me wonder why now rust is the alleged culprit.

[fichtner]

Is this an instance using ZFS? And how is the storage connected? It's probably not having the usual issues it seems.

[chaichairiko]

It does not:
root@freebsd:/usr/tools # mount -p /dev/gpt/rootfs / ufs rw 1 1 devfs /dev devfs rw 0 0 /usr/ports /usr/obj/usr/tools/config/20.7/OpenSSL:amd64/usr/ports unionfs rw 0 0 /usr/src /usr/obj/usr/tools/config/20.7/OpenSSL:amd64/usr/src unionfs rw 0 0 devfs /usr/obj/usr/tools/config/20.7/OpenSSL:amd64/dev devfs rw 0 0
Should it run ZFS? What do you mean by how the storage is connected? Is there anything else that you think AWS could cause issues in the build?

[chaichairiko]

It seems this issue is probably connected to working with AWS. Closing this issue as it is not reproducible outside AWS