Since fdf32154fc, we no longer allow
missing modules in the initrd. Unfortunately since before this commit,
the modules-closure script would also fail on missing firmware, which
is a very common case (e.g. xhci-pci.ko.xz lists renesas_usb_fw.mem as
dependent firmware). Fix this by only issuing a warning instead.
Before this commit, the firmware information would be loaded from the
currently running kernel, not from the kernel to be loaded.
This commit ensures the correct kernel version and modules are read.
After a recent upgrade of modinfo, its output is now incorrect for
builtin modules. This commit filters out the output until a fix is made
available upstream
The previous code discarded entire dependency trees if the first entry in the dependency list compiled by `modprobe --show-depends` is a builtin and otherwise handled its output in a rather hackish way.
depmod looks for files modules.order and modules.builtin which are
generated at kernel build time but were previously not passed to
the modules-shrunk derivation
Pull request #38470 added support for running/building kernels without
modules. This got merged in 38e04bbf29 but
unfortunately while this works perfectly on kernels without modules it
also makes sure that *every* kernel gets no modules.
So all of our VM tests fail since that merge with something like this:
machine# loading module loop...
machine# modprobe: FATAL: Module loop not found in directory /lib/modules/4.14.33
machine# loading module vfat...
machine# modprobe: FATAL: Module vfat not found in directory /lib/modules/4.14.33
machine# loading module nls_cp437...
machine# modprobe: FATAL: Module nls_cp437 not found in directory /lib/modules/4.14.33
machine# loading module nls_iso8859-1...
machine# modprobe: FATAL: Module nls_iso8859-1 not found in directory /lib/modules/4.14.33
machine# loading module fuse...
machine# modprobe: FATAL: Module fuse not found in directory /lib/modules/4.14.33
machine# loading module dm_mod...
machine# modprobe: FATAL: Module dm_mod not found in directory /lib/modules/4.14.33
I shortly tested this against the "misc" VM test and the test is working
again.
In the long term (and I currently don't have time for this) it would be
better to also have a VM test which tests a kernel without modules.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @roberth, @7c6f434c
There were conflicting patches of pkgs/os-specific/linux/module-init-tools.
Apparently, the expression was updated independently in both branches. I've
resolved the conflict by preferring the patches from stdenv-updates, because
those patches appeared to be more sophisticated, i.e. they build the manual,
etc.
svn path=/nixpkgs/branches/stdenv-updates/; revision=29680
This comes from:
svn diff ^/nixpkgs/trunk/@18255 ^/nixpkgs/branches/stdenv-updates/ > diff
patch -p0 < diff
and then adding into svn all files new from the patch.
trunk@18255 comes from the last time I updated stdenv-updates from trunk.
svn path=/nixpkgs/stdenv-updates2/; revision=18272
tree under $out into a separate stdenv adapter named keepBuildTree.
* makeModulesClosure: support building an initrd for a kernel that has
been compiled with coverage instrumentation.
svn path=/nixpkgs/trunk/; revision=16916
modules for the initial ramdisk if there were no additional kernel
module packages (such as the NVIDIA driver or AUFS), leading to a
kernel panic in the initrd. This was because in that case modprobe
would print paths referring to the kernel path rather than the
module aggregation path, and then `sed "s^$kernel^$out^"' would
silently fail. Fixed.
* Also, use depmod here rather than doing sed hackery on modules.dep.
* Also, `allowMissing' was broken (missing "$" before the variable
name).
svn path=/nixpkgs/trunk/; revision=15394
