Re: [gentoo-user] Module and kernel woes after two "emerge -DuNe @world"s

[Mick]

On Sunday, 9 June 2019 18:55:34 BST Grant Taylor wrote:
> On 6/9/19 2:56 AM, Mick wrote:
> > This sounds as if it may be related to a move from an older gcc to
> > a newer version.
>
> I'm not sure it's related to a gcc version:
>
> # gcc-config -l
>   [1] x86_64-pc-linux-gnu-6.4.0 *
>   [2] x86_64-pc-linux-gnu-8.3.0
>
> I think that gcc 8.3 might have been selected and I reverted to 6.4
> thinking that it might have been part of the problem.  I have since done
> an emerge -DuNeq @world with gcc 6.4 and the problem persists.
>
> > Checking my understanding:
> >
> > 1. The old modules, compiled with the old gcc and toolchain worked
> > fine.
>
> Correct.
>
> > 2. The new modules, compiled with the new gcc but old libtool,
> > binutils and glibc worked (usually you update these or @system,
> > before you update the whole world).
>
> Correct.
>
> > 3. The new modules, compiled with the new gcc and toolchain rebuilt
> > the second time do not work (this would use libtools, binutils, glibc,
> > now compiled with the new gcc).
>
> Correct.
>
> > 4. All of the above happens with the old kernel, which was not rebuilt
> > with the new toolchain.
>
> Correct.
>
> > 5. New kernel(s) compiled thereafter will not boot.
>
> Correct.
>
> > You have not mentioned if you upgraded gcc.
>
> I think that the first emerge -DuNeq @world did pull in a new gcc.  But
> I have since selected gcc 6.4 as part of diagnostics.  (See above.)
>
> > The error you get about modules failing to load sounds like a
> > path/symlink error, or a linux headers error, or a change of arch.
>
> I don't think it's a symlink error.  (I've configured things to not
> automatically update the sym-link.)
>
> # ls -la /usr/src/linux
> lrwxrwxrwx 1 root root 22 Sep  8  2018 /usr/src/linux ->
> linux-4.9.76-gentoo-r1/
> # uname -a
> Linux REDACTED 4.9.76-gentoo-r1 #1 SMP Thu Nov 15 22:23:44 MST 2018
> x86_64 Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz GenuineIntel GNU/Linux
>
> As you can see, the machine has enough CPU that I can let it do the
> following to make sure that things are consistent.  (At least I think
> that's what's happening.)
>
> emerge -DuNeq @world && emerge --depclean && revdep-rebuild
>
> That's my SOP.  If that fails I usually try a --resume to see if the
> problem repeats, and if it's at the same place.  If that fails for some
> reason, I'll fall back to a @system.  Usually the failure is caused by
> something that I've done, disk space, ZFS version issues, etc.
>
> > Since both vbox and zfs modules fail to boot I would not think this
> > is a zfs isolated problem.
>
> Agreed.
>
> > Have you tried forcing the loading of these modules?
> >
> > modprobe --force --verbose <module_name>
>
> No, not yet.  I've never had any success forcing the kernel to load modules.
> > What errors do you get with the new non-booting kernels?
>
> # modprobe --force --verbose vboxdrv
> insmod /lib/modules/4.9.76-gentoo-r1/misc/vboxdrv.ko
> modprobe: ERROR: could not insert 'vboxdrv': Exec format error
>
> dmesg reports the following for each attempt to (force) load the module.
>
> module: vboxdrv: Unknown rela relocation: 4
>
> Mick I get the impression that you've got the correct understanding of
> my current situation.  I'm interested learn what you think should be done.


If you haven't done it already, perhaps have a look in the path /lib/modules/
4.9.76-gentoo-r1/misc/ to check the VBox modules are present and owned by 
root:root with 0644 access rights.

Since you have not cross compiled any of these modules, altered your make.conf 
CFLAGS, or messed with the linux-headers, I can't see what else might have 
gone sideways.  :-/

I'm not saying this is what you should do, but unless someone more learned 
than myself chimes in with better advice, this is how I would go about it:

1. Make a back up of your system in case you can't get back into it and need 
to restore from a back up.
2. Sync portage and upgrade gcc to the latest stable version.  Switch to it.
3. Rebuild libtools, binutils, glibc.
4. Rebuild @system.
5. Copy your present kernel config to the latest stable kernel which also 
deals with the MDS Intel vulnerability; change symlink; 'make oldconfig' on 
the latest kernel; build it and install it.  Don't forget to emerge @module-
rebuild.

If the newly built kernel won't boot, troubleshoot the error messages at boot 
and perhaps keyword and try a later kernel.

The reason I would go about it this way is because ultimately you will need to 
both upgrade gcc and move on to a later version kernel.  I appreciate right 
now may not be the right time for you, but at some point, when convenient, 
you'll have to make time to deal with these errors and work through them to a 
solution.

PS. May also be worth posting in the forums and asking in IRC as there will be 
more users who may have come across you problem.

-- 
Regards,
Mick