[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: Sun, 07 Nov 2021 21:38:37 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259702

            Bug ID: 259702
           Summary: buildkernel -j[#] with PORTS_MODULES pauses
                    indefinitely with SIGNAL 22 if port config not set yet
           Product: Base System
           Version: Unspecified
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: misc
          Assignee: bugs@FreeBSD.org
          Reporter: mirror176@hotmail.com

stable/13-n247959-f8b998c7305 here built November 2nd (ports tree near same
time) but suspect the issue is more widespread as this appears to be bug 198545
(Closed Overcome By Events) but reproduced with more ports. The issue is signal
22 results from trying to provide a ports configuration screen if -j flag is
used including -j1.

Reproduced in /usr/src with `make -j1 buildkernel
PORTS_MODULES=x11/nvidia-driver-390` or `make -j2 buildkernel
PORTS_MODULES=sysutils/openzfs-kmod` though I initially ran into it with the
variable defined in /etc/src.conf.

Possible things to fix:
Is there a way to provide a configuration screen to terminal with -j>1 defined?
Run port build with BATCH defined if -j[>1] defined.
-j1 should fallback to running the same as without the flag.
Error out successfully instead of locking up and needing to abort the build
manually (used ctrl+c at terminal I executed it from).

workarounds:
Manually proceed to find/answer config dialogs before executing buildkernel;
needs to always be done if ports tree is updated or freebsd source is updated
as ports revise their options and freebsd version changing can change path
through ports tree (graphics/drm-kmod leading to a different variant based on
version of OS it is built for).
`make -j# buildkernel&&make buildkernel PORTS_MODULES=` as a type of 2 step
run; permits still building kernel parallel but would not be compatible with
defining it in /etc/src.conf.

Wondering if i am doing it wrong or in some unexpected way:
  I switched to building my own packages through poudriere and with defaults
instead of my preferences (usually) years ago which resulted on me not having
ports config screens set regularly. I remember trying PORTS_MODULES
unsuccessfully more than once but never really looked into it. Started to now
as it seems much more appropriate thank building kernel modules 'after' an OS
install+reboot which needs the old module set to not load during launch.
  Poudriere doesn't recommend it be used to build ports for a newer OS than it
is running on and at a few hours usually for
x11/nvidia-driver-390+emulators/virtualbox-ose-kmod that seemed like a lot of
down time with complicated steps to remove module from boot, update OS, rebuild
ports providing modules and the chain they depend on (poudriere makes that task
easy), reinstall newly built copies (not sure when pkg considers the install
necessary vs skippable), best to manually load the modules once at this point,
then we can finally add modules to boot sequence again.
  That has been my reliable path which is much slower than my old portupgrade
way in place of poudriere; too many times ports fail to build due to depending
on local files over build directory files unexpectedly. Never learned how to
'properly' fix those issues but fear the original issue needs to be addressable
to use PORTS_MODULES reliably too.

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