[Bug 259702] buildkernel -j[#] with PORTS_MODULES pauses indefinitely with SIGNAL 22 if port config not set yet
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.