| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We have no mechanism to ensure that we build the kernel modules for
the same kernel version as the version we will record in the virtual/dist-kernel
subslot dependency. This does not fix this problem, but it does add a warning
to ensure users are aware that, for example, built binpkgs are going to have
wrong dependency metadata.
Bug: https://bugs.gentoo.org/923025
Signed-off-by: Andrew Ammerlaan <andrewammerlaan@gentoo.org>
Closes: https://github.com/gentoo/gentoo/pull/35066
Signed-off-by: Andrew Ammerlaan <andrewammerlaan@gentoo.org>
|
| |
|
|
|
| |
Closes: https://github.com/gentoo/gentoo/pull/34513
Signed-off-by: Michał Górny <mgorny@gentoo.org>
|
| |
|
|
|
|
|
|
|
|
|
| |
Add a `modules-compress` USE flag to explicitly control kernel module
compression. When the flag is disabled, modules are installed
uncompressed even if the kernel supports compression (which is going
to be the case for new sys-kernel/gentoo-kernel* builds). When it is
enabled, the eclass compresses modules using the compressor configured,
or fails if no compression is supported.
Signed-off-by: Michał Górny <mgorny@gentoo.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the non-default CONFIG_KERNEL_DECOMPRESS option is set in
kernel >6.4, >=kmod-31 will let the kernel handle decompression
rather than use xz-utils.
...but kernel XZ decompressor is more limited, so need to use the
same options the kernel does. -T/--threads fortunately is harmless
to keep on top.
Note crc32 is already the default and main problem was dict size, but
still specify in case someone has e.g. XZ_DEFAULTS="--check=sha256".
Closes: https://bugs.gentoo.org/920837
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
| |
|
|
|
|
|
| |
Not necessary, but also change STRIP while at it for parity.
Closes: https://bugs.gentoo.org/916587
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These cause no issues with depmod itself, but dracut has the
funny idea to parse /lib/depmod.d files manually in its
90kernel-modules-extra/module-setup.sh and decides to include
modules that are overriden even though they are not needed in
early boot (increasing size, perhaps by as much as 90MB if
nvidia got included).
By disabling we're back to potentially loading stale
UNINSTALL_IGNORE'ed modules, but would rather keep the status
quo than introduce different issues (or at least for now),
especially considering dracut has become widely used on Gentoo.
Note there's no real need to revbump all modules to omit
these files given:
1) has not existed for that long, and is mostly in ~arch
2) will be cleaned on kernel upgrade + modules rebuild
3) initramfs will not include extra modules unless it
is ran *after* the modules were rebuilt which is
atypical except for zfs-kmod (in case of zfs-kmod
we want to include modules either way)
4) users that rebuild their initramfs after out-of-tree modules
likely rebuild everytime as-is (avoids stale modules)
5) "most" modules are harmless to include unless large or being
API sensitive and the user does not upgrade their kernel
Primary issue can be with nvidia-drivers in a scenario such as:
1. build kernel
2. build nvidia
3. build initramfs *after* nvidia (gets included, while
wouldn't without the depmod.d)
4. build new nvidia-drivers version
5. don't rebuild initramfs
6. get API mismatch if nvidia.ko got loaded during initramfs
(typically happens even if not using the display yet)
Non-issue if the initramfs was built in step 1, unless nvidia
modules were already installed for that kernel version like
a gentoo-kernel revbump that did not trigger dist-kernel rebuilds.
As a precaution, will still revbump nvidia-drivers given these
are already using this in stable.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
| |
|
|
|
|
|
|
|
| |
<name> without .ko can easily trigger implicit build rules,
as far as I can tell no ebuild has needed ever needed
TARGETS="name" including those already migrated (some *do*
need "name.ko"), so should be safe to just drop it.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
| |
|
|
|
|
|
|
|
|
| |
Previous commit raised concerns about this, turns out passing
`-b ${EROOT}` is not sufficient.
Not really harmful, but also avoid passing -b / given results
in double //lib/modules in depmod -v.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sneaking in another quick improvement while the eclass still has
low tree usage, file is not *essential* so it can wait till next
merge of the package to be active.
e.g. if have (filesystem order):
/lib/modules/6.3.4/not-right/ryzen_smu.ko
/lib/modules/6.3.4/extra/ryzen_smu.ko
It will load not-right/ryzen_smu.ko by default.
But with /lib/depmod.d/ryzen_smu.conf having:
override ryzen_smu 6.3.4 extra
We more deterministically get extra's. Lacking this can be a problem
when either want to override the kernel's own modules, or if portage
left over behind modules in an outdated directory due to the default
UNINSTALL_IGNORE for modules.
Can be worse with e.g. nvidia given loading the wrong version of
the module means everything will fail. And not everyone upgrade
their kernel regularly to cleanup, some also install modules that
aren't tracked by portage in different subdirs (including nvidia's...)
which is not entirely surprising considering many build their kernel
without portage/dist-kernel.
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Not an issue when people upgrade their kernel regularly but,
if keeping same kernel forever, may end up with stale modules
if change the location.
The eclass' default change has little impact given very few
ebuilds actually did not specify the directory, but suggesting
s/misc/extra/ may not be wise.
This is also an issue when different-named modules are added
or removed (e.g. xtables-addons has optional modules).
Worse if user changes or enables compression given all old
modules will stay with their old extension.
With some modules this may have a bigger impact if api changes
or the userland does version checks, and it ends up loading
the wrong module. For most others, will likely go unnoticed
and fix itself with a kernel upgrade.
Changes may require having a pkg_postinst cleanup at times.
...ideal would be if package manager could clean modules if
they are being installed for the same kernel, but keep the
ones for a different (old) kernel, but well.
For eclass solutions there could(?) be:
1. sanity check that warn if duplicates are found in postinst
(informational only, being destructive there sounds bad)
2. install depmod.d files that gives priority to the modules
we just installed (untested, but sounds possible)
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The virtual allows pulling older slots without being downgraded,
which may make things confusing for USE=dist-kernel automatic
rebuilds.
If try to downgrade the virtual, it will suggest downgrading
the kernel too and likely won't need to explain further.
Beside that, rather stay somewhat vague there. This is not
downgrade instructions.
(note will take the liberty to do quick edits without ML
review for the time being, very few consumers at the moment)
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
|
|
Here's a rough overview of -r0 -> -r1 differences with occasional
rationale behind them if felt relevant (for migrating, refer to
the eclassdocs instead as this does not really document usage
changes):
Features that did not exist in previous eclass (not exhaustive):
* automatic modules signing support, been often requested and
users would instead use messy bashrc hacks to accomplish this
(enabled with USE=modules-sign)
* modules (manual) stripping support to allow stripping *before*
signing and compression
(can be disabled with USE=-strip)
* can auto-select toolchain to match kernel, e.g. if built with
clang-15 then it won't use gcc nor clang-16 if possible
(will warn if the matching compiler went missing)
* helper functions to profit from the above 3 even if not using
linux-mod-r1_src_compile+install (e.g. for zfs-kmod)
* generic supported kernel version checks (min/max) which comes with
an encouragement to use LTS kernels for out-of-tree modules
(but max is not enforced, just makes a strong suggestion)
* linux-mod-r1_src_install now does einstalldocs
* can guess some common build targets rather than just 'module',
largely removing the need for BUILD_TARGETS
* user-oriented MODULES_EXTRA_EMAKE among other few variables
* various additional sanity checks hopefully making issues
clearer for users and ebuilds a bit harder to write wrong
"Features" that existed but were not kept (not exhaustive):
* support for <kernel-2.6(!) modules, eclass only tested with >=4.14.x
* allowing doing all in global scope using variables ran through `eval`
(this often led to all sort of variable misuse in global scope)
* MODULESD_* support, originally meant to keep but it is used by only
5 packages and holds very little meaning that I can see even in these
(when needed, packages should write their own .conf)
* moduledb, was being updated for nothing in postinst/postrm
despite the tool that can use this (sys-kernel/module-rebuild)
being gone from the tree since Feb 2014
* convert_to_m(), only 1 in-tree ebuild uses this right now (svgalib)
* various other functions with no consumers were dropped, some
were likely meant to be @INTERNAL, get-KERNEL_CC was never used
either and now there's ${KERNEL_CC}
* running 'clean' by default, this sometime led to race conditions by
attempting to clean and build at same time in e.g. nvidia-drivers
(if an ebuild truly need this, it can be specified manually)
* INSTALL_MOD_PATH support, this integrates badly with ebuilds that
use it as DESTDIR with e.g. `make INSTALL_MOD_PATH="${ED}" install`
or find "${ED}"/lib/modules, etc... requiring extra consideration
(also feels inconsistent with how ebuilds normally work, the few
concerned users may be interested by setting ROOT or manually moving
files instead -- but support was missing until 2021 so it should
have little impact)
* BUILD_FIXES support, this is set by linux-info.eclass but has no
real relevance that I can see (ebuilds have sometime wrongly used it)
* undocumented feature CONFIG_CHECK="@CONFIG:modname" (or so?) meant
for automagic based on kernel config is no longer supported, this
also removes the also undocumented MODULE_IGNORE used by it (found
0 ebuilds using these in the tree, can be done manually if needed)
* converting CONFIG_CHECK to non-fatal for running again on binary
merge when (while *possible*) it's rather unlikely would build
modules for a different kernel than the one that will be used
* having preinst and postrm exports, removed
-> originally wanted to remove pkg_setup too but it complicated
things with linux-info's own pkg_setup and made the eclass
feel less convenient and error-prone with environment handling
Dependency changes:
* virtual/libelf DEPEND removed, building objtool (which uses this) is
not handled by the eclass and does not seem auto-built by make if
missing, as such the dependency is not used *here* but rather by
dist-kernels and source packages which both already request it.
* sys-apps/kmod[tools] BDEPEND+IDEPEND added, and removed from DEPEND
(linux-mod-r0 uses it similarly but lacks the eapi7+8 adjustment)
* modules-sign? ( dev-libs/openssl virtual/pkgconfig ) BDEPEND for
building sign-file, unlike objtool it may need rebuilds for openssl
and is handled here
* dependencies are no longer guarded by "kernel_linux? ( )", it only
served to silence pkgcheck and then give build failures (linux-only
ebuilds should be masked on non-Linux profiles or, if mixed, use a
masked MODULES_OPTIONAL_IUSE which *can* be kernel_linux).
Tentative changes:
* drop KERNEL_ABI support, (nowadays) kernel seems to append its own
-m32/-m64 and should be no need for multilib.eclass complications
(tested to work *at least* with x32[userland]+64bit[kernel])
* ^ but add hppa2.0->64 kgcc64 switching like kernel-build.eclass
* drop addpredict wrt bug #653286, assuming no longer relevant given
unable to reproduce even with kernel-4.14.315+split-debug+some misc
modules, perhaps would with spl but that (removed) ebuild is too
broken to try
Misc changes:
* misc -> extra default install dir, to match the kernel's defaults
(this is also where zfs-kmod already installs due to that default)
Three bugs were addressed, but not closing given -r0 remains affected:
* bug #447352: modules signing is supported
* bug #759238: arguably not an issue anymore in -r0 either due to
CHECKCONFIG_DONOTHING=1 (bug #862315) now existing, but -r1
additionally makes it non-fatal if a whitelist exists in the kernel
* bug #816024: trying to select toolchain better is a -r1 highlight
Additionally, becomes WONTFIX in this version:
* bug #642240: INSTALL_MOD_PATH support is reverted
Bug: https://bugs.gentoo.org/447352
Bug: https://bugs.gentoo.org/642240
Bug: https://bugs.gentoo.org/759238
Bug: https://bugs.gentoo.org/816024
Closes: https://github.com/gentoo/gentoo/pull/31154
Signed-off-by: Ionen Wolkens <ionen@gentoo.org>
|
Andrew Ammerlaan
Michał Górny
Ionen Wolkens
GitWeb