[Bug 259702] buildkernel -j[#] with PORTS_MODULES pauses indefinitely with SIGNAL 22 if port config not set yet

From: <bugzilla-noreply_at_freebsd.org>
Date: Wed, 07 Dec 2022 16:51:31 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259702

Jonathan Vasquez <jon@xyinn.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jon@xyinn.org

--- Comment #1 from Jonathan Vasquez <jon@xyinn.org> ---
Thanks Edward for that description. This actually helped me figure out why my
builds were getting stuck with the Signal 22 issue. Yea it seems you are right
that if you haven't set your port options in the ports directory for
`virtualbox-ose-kmod`, you'll get this issue. I tried the following below:

You can consider this happening after a fresh install and a fresh build
stable/13 has already occurred (buildworld buildkernel).

After this, I'll add the following to /etc/make.conf:

PORTS_MODULES+=net/realtek-re-kmod graphics/drm-510-kmod
emulators/virtualbox-ose-kmod

/usr/ports has the latest changes using git pull.


// Step 1: Try and rebuild the kernel and allow the build system to hook into
PORTS_MODULES
// in order to rebuild all of those modules.

# cd /usr/src
# make -j32 buildkernel


===> Ports module emulators/virtualbox-ose-kmod (all)
cd ${PORTSDIR:-/usr/ports}/emulators/virtualbox-ose-kmod; env  -u CC  -u CXX 
-u CPP  -u MAKESYSPATH  -u MK_AUTO_OBJ  -u MAKEOBJDIR  MAKEFLAGS="-j 32 -J
15,16 -j 32 -J 15,16 -D NO_MODULES_OBJ KERNEL=kernel TARGET=amd64
TARGET_ARCH=amd64"  SYSDIR=/usr/src/sys 
PATH=/usr/obj/usr/src/amd64.amd64/tmp/bin:/usr/obj/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
 SRC_BASE=/usr/src  OSVERSION=1301509 
WRKDIRPREFIX=/usr/obj/usr/src/amd64.amd64/sys/GENERIC make -B clean build
===>  Cleaning for virtualbox-ose-kmod-6.1.36
*** [all] Stopped -- signal 22

// The above causes our Signal 22 issue. Let's go ahead and set the ports
options for the virtualbox-ose-kmod port:

# cd /usr/ports/emulators/virtualbox-ose-kmod
# make config-recursive

// Set all of the options and then switch back to the /usr/src dir and try and
rebuild.

cd /usr/src
make -j32 buildkernel

// This allows the Signal 22 issue to no longer occur, but fails with a
different issue:

make[3]: stopped in /usr/ports/emulators/virtualbox-ose-kmod
*** [all] Error code 1

make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/GENERIC
1 error

make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/GENERIC

make[1]: stopped in /usr/src

make: stopped in /usr/src

// Let's try and set any other remaining port options on the `virtualbox-ose`
main port package
// directly. Maybe it's similar to Signal 22 but starting from the main
virtualbox package:

# cd /usr/ports/emulators/virtualbox-ose
# make config-recursive

// Try and rebuild
# cd /usr/src
# make -j32 buildkernel

// Still fails with the same issue. Let's try and actually just build our
`virtualbox-ose`
// in its entirety and not just try to build the kernel module:

# cd /usr/ports/emulators/virtualbox-ose
# make install clean

// The build now succeeded! Let's try and rebuild the kernel module again to
see if going
// forward it should (usually) build fine:

# cd /usr/src
# make -j32 buildkernel

--------------------------------------------------------------
>>> Kernel build for GENERIC completed on Wed Dec  7 11:46:49 EST 2022
--------------------------------------------------------------
>>> Kernel(s)  GENERIC built in 194 seconds, ncpu: 32, make -j32
--------------------------------------------------------------

// and now it works.

So now we know the issue, but is there a better user experience for this? Am I
just doing it wrong or is this as good as it gets?

-- 
You are receiving this mail because:
You are the assignee for the bug.