But that begs the question of why my initrd is correct but my
/lib/modules/4.19.72-gentoo isn't ...
I'll look into it tomorrow...
On 12/11/19 22:56, n952162 wrote:
On 12/11/19 17:47, Neil Bothwick wrote:
On Wed, 11 Dec 2019 14:55:48 +0100, n952162 wrote:
I've made a new recognition about this issue. If I move
/lib/modules/4.19.72-gentoo to a saved/ subdirectory, and otherwise have
NO modules directory, I don't have this problem. When I move the modules
directory back into place, the problem returns.
I'm not understanding how the system can run without a modules
directory.
As long as everything your system *needs* to run is built into the
kernel, this will work, but things will fail when modules are needed.
As an example, I looked at a module that was easy to spell, fuse.ko, ;-)
and looked where else on the system it exists, and found a copy in
/usr/src. The files have the same file(1) response (both non-stripped,
with the same build id), but different lengths. I didn't see anything
in /var/log like, "falling back to /usr/src/..."
When you run make in /usr/src/linux, the modules are built there. When
you run "make modules_install", they are copied to /lib/modules/version/
The kernel only look in /lib/modules/version
When the modules directory is present (/lib/modules/4.19.72-gentoo/), I
have a lot more problems than just the power problem. For example, X
comes up but eventually locks up. With NO modules subdirectory, X works
okay.
So you have a misbehaving module, or faulty hardware that uses a module.
All you need to do now is work out which one it is ;-)
Okay, I guess I understand now ...
# mount | grep /dev/sda
...
/dev/sda3 on /tmp type *ext4* (rw,relatime)
# lsmod | grep ext4
*ext4* 720896 4
# gzip -cd < /proc/config.gz | grep -i ext4
CONFIG_EXT4_FS=*m*
...
# xz -dc < /boot/*initramfs*-genkernel-x86_64-4.19.72-gentoo | cpio
-ivt | grep -i ext4
...
-rw-r--r-- 1 root root 1392337 Dec 10 20:58
lib/modules/4.19.72-gentoo/kernel/fs/ext4/*ext4.ko*
...
