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

[Grant Taylor]

On 6/9/19 12:49 PM, Mick wrote:
> 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.

They are there.  I would have expected the error message to be different 
if the modules couldn't be found (or read).

But it doesn't hurt to check.

ls -l /lib/modules/4.9.76-gentoo-r1/misc
total 621
-rw-r--r-- 1 root root 539592 Jun  8 09:39 vboxdrv.ko
-rw-r--r-- 1 root root  15000 Jun  8 09:39 vboxnetadp.ko
-rw-r--r-- 1 root root  39384 Jun  8 09:39 vboxnetflt.ko
-rw-r--r-- 1 root root  36248 Jun  8 09:39 vboxpci.ko


> 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.  :-/

Agreed.

> 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.

BackupPC does that nightly for me.

Aside:  I'm quite happy with BackupPC.  It has worked extremely well for 
me for about 10 years.  If you're looking for a backup solution, I 
highly recommend you check it out.  I think you should check it out even 
if you aren't looking.

> 2. Sync portage and upgrade gcc to the latest stable version.
> Switch to it.

Portage is within a few days of current.

I do an emerge --sync -q before doing the emerge -DuNeq @world.  I've 
not done a --sync since then while working on things.  The idea is to 
not introduce any more changes while dealing with this.

> 3. Rebuild libtools, binutils, glibc.

Okay.

Do you (or anyone) know of any problems with downgrading binutils?  If I 
wanted to try to regress to the last working version for testing?

I don't know much about libtools.

I do know that glibc shouldn't be changed willy nilly without a good reason.

> 4. Rebuild @system.

Is there any problem with rebuilding @world in lieu of @system?  I think 
it just means more packages.  I guess there could be an issue with the 
overall emerge if there is a problem with a package that's in @world but 
not in @system.  At least emerge would not finish gracefully in that case.

> 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.

I'm reluctant to move to a new kernel version at this time.  I'm using 
Open vSwitch (for reasons) and last I looked (admittely it's been a 
while) I had an issue with newer than 4.9.<something>.  I don't recall 
the specifics.

Seeing as how I'm not concerned with the Intel MDS issues on this 
machine at this time, I don't view that as a compelling reason to change 
the kernel /now/.  Especially when dealing with other issues.

After all, the kernel has shown that it can be compiled and successfully 
run on the system.  So I really don't think the kernel version that I'm 
running is the problem.  ;-)

> Don't forget to emerge @module- rebuild.

I use genkernel, which handles the config file for me.  (I've confirmed 
the one it's using matches the one from /proc/config.gz of the good 
kernel.)  I also have genkernel configured to rebuild modules for me.

CMD_CALLBACK="emerge --quiet @module-rebuild"

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

I know that I can't successfully boot the new kernel.  I don't know if 
there are any error messages generated or not.  My monitor goes dark for 
a moment after picking the kernel in GRUB (2), and then I see my 
system's firmware initializing again.  The good kernel (that I'm 
replying from) does similar, but I see the penguins as part of the frame 
buffer initializing and other kernel messages.  I can't tell if there 
are messages from the bad kernel, or if the system is simply rebooting 
before any output.  Either way, I can't see any that quickly if they are 
there.  (I suppose I could record it with my phone and look at the video.)

> 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 agree that I /should/ do that.  (RFC sense of "should".)  But I don't 
think it's required for what I use this machine for.  Admittedly, I 
won't get any of the myriad of benefits available without doing so.  But 
that's a /choice/, not a /compulsion/.  ;-)

> 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.

Maybe.  Maybe not.  (See above.)

> 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.

ACK

Thank you for your input Mick.  I appreciate it.