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.
