Just as it says in the summary. This can lead to a system that won't boot because the vbox modules try to load and then oops the kernel. Reproducible: Always Steps to Reproduce: 1. Install virtualbox-modules 2. Upgrade kernel 3. Run emerge @module-rebuild Actual Results: virtualbox-modules doesn't get rebuilt Expected Results: virtualbox-modules should get rebuilt
Works for me .. when you "upgrade"d the kernel in step 2 , was that an actual upgrade or was that a rebuild of the same kernel with different .config settings? The reason I ask is because you won't get a kernel oops if it was a whole new kernel due to the version mismatch of the modules (they just wouldn't load at all). However, it's possible you will if you rebuilt the same kernel with settings that conflict compared to the one in place when you built vbox-modules.
Let me describe in more detail what I saw in my two gentoo systems. System 1: - Upgrade from 4.1.5 to 4.1.12 (by which I mean build new kernel, install it into /boot, install modules, change /usr/src/linux symlink) - emerge @module-rebuild, which did not include virtualbox-modules - Reboot into 4.1.12, and watch kernel oops from vbox module loading and dereferencing a null ptr - Reboot into 4.1.5 again, rebuild virtualbox-modules, reboot into 4.1.12 and all is well System 2: - Upgrade from 4.0.5 to 4.1.12 (same process) - emerge @module-rebuild, observe no virtualbox-modules - file bug on gentoo :) So, while I agree that it SEEMS like the module shouldn't have tried to load, it *did* and failed. And either way, virtualbox-modules seems like it should be rebuilt with @module-rebuild.
One explanation for this would be if virtualbox-modules actually was not installed on the system when you ran emerge @module-rebuild (the modules could still exist in /lib/modules even if it was unmerged). So when you thought you were REinstalling it, you were really just installing it. The @module-rebuild set is defined in /usr/share/portage/config/sets/portage.conf: [module-rebuild] class = portage.sets.dbapi.OwnerSet files = /lib/modules So the set includes any package which installs files to /lib/modules, and virtualbox-modules does.
I already had virtualbox-modules installed, so that's not it, and the files exist in my old kernel's /lib/modules: ls -l `find /lib/modules/4.0.5-gentoo -type f | grep vb` -rw-r--r-- 1 root root 393160 Nov 1 01:24 /lib/modules/4.0.5-gentoo/misc/vboxdrv.ko -rw-r--r-- 1 root root 10752 Nov 1 01:24 /lib/modules/4.0.5-gentoo/misc/vboxnetadp.ko -rw-r--r-- 1 root root 28232 Nov 1 01:24 /lib/modules/4.0.5-gentoo/misc/vboxnetflt.ko -rw-r--r-- 1 root root 26640 Nov 1 01:24 /lib/modules/4.0.5-gentoo/misc/vboxpci.ko I updated to 4.1.12 this morning. % ls -l `find /lib/modules/4.1.12-gentoo -type f | grep vb` -rw-r--r-- 1 root root 471096 Nov 11 10:25 /lib/modules/4.1.12-gentoo/misc/vboxdrv.ko -rw-r--r-- 1 root root 12192 Nov 11 10:25 /lib/modules/4.1.12-gentoo/misc/vboxnetadp.ko -rw-r--r-- 1 root root 30456 Nov 11 10:25 /lib/modules/4.1.12-gentoo/misc/vboxnetflt.ko -rw-r--r-- 1 root root 29880 Nov 11 10:25 /lib/modules/4.1.12-gentoo/misc/vboxpci.ko
Does "emerge -pv @module-rebuild" right now show any packages to build?
On both of my boxes (now on 4.1.12 kernel), emerge -pv @module-rebuild *does* include virtualbox-modules. So, whatever transient issue affected (both) boxes is not present now. However, here for instance is part of the emerge log from me doing @module-rebuild this morning: 1447266094: Started emerge on: Nov 11, 2015 10:21:34 1447266094: *** emerge --with-bdeps=y --autounmask --autounmask-write =app-emulation/virtualbox-additions-5.0.8 1447266095: >>> unmerge success: sys-fs/zfs-kmod-0.6.4.2 1447266097: === (2 of 3) Post-Build Cleaning (sys-fs/zfs-kmod-0.6.4.2::/usr/portage/sys-fs/zfs-kmod/zfs-kmod-0.6.4.2.ebuild) 1447266097: ::: completed emerge (2 of 3) sys-fs/zfs-kmod-0.6.4.2 to / 1447266097: >>> emerge (3 of 3) x11-drivers/nvidia-drivers-355.11-r2 to / 1447266097: === (3 of 3) Cleaning (x11-drivers/nvidia-drivers-355.11-r2::/usr/portage/x11-drivers/nvidia-drivers/nvidia-drivers-355.11-r2.ebuild) 1447266098: === (3 of 3) Compiling/Merging (x11-drivers/nvidia-drivers-355.11-r2::/usr/portage/x11-drivers/nvidia-drivers/nvidia-drivers-355.11-r2.ebuild) 1447266120: *** exiting unsuccessfully with status '1'. 1447266120: *** terminating. 1447266128: === (3 of 3) Merging (x11-drivers/nvidia-drivers-355.11-r2::/usr/portage/x11-drivers/nvidia-drivers/nvidia-drivers-355.11-r2.ebuild) 1447266131: >>> AUTOCLEAN: x11-drivers/nvidia-drivers:0 1447266131: === Unmerging... (x11-drivers/nvidia-drivers-355.11-r2) 1447266134: >>> unmerge success: x11-drivers/nvidia-drivers-355.11-r2 1447266137: === (3 of 3) Post-Build Cleaning (x11-drivers/nvidia-drivers-355.11-r2::/usr/portage/x11-drivers/nvidia-drivers/nvidia-drivers-355.11-r2.ebuild) 1447266137: ::: completed emerge (3 of 3) x11-drivers/nvidia-drivers-355.11-r2 to / 1447266137: *** Finished. Cleaning up... 1447266139: *** exiting successfully. 1447266139: *** terminating. You can see there's no virtualbox... Could it perhaps be something related to changing the /usr/src/linux symlink confusing the detection of modules? Though I don't know why that would cause only some packages to get rebuilt rather than 0...
I'm fairly certain that you did not have virtualbox-modules installed when you first ran emerge @module-rebuild. The /usr/src/linux symlink is not involved, emerge just checks the installed package DB for any installed packages with files in /lib/modules and rebuilds those. Basically it looks at /var/db/pkg/*/*/CONTENTS for any occurrence of /lib/modules. Either virtualbox-modules wasn't installed, or it was installed in some broken way such that no files were installed to /lib/modules/.
Oops, sorry, wrong log snippet. Let me try again, with better detail... Here is what emerge -pv @module-rebuild shows now: [ebuild R ~] sys-kernel/spl-0.6.4.2::gentoo USE="-custom-cflags -debug -debug-log" 0 KiB [ebuild R ~] app-emulation/virtualbox-modules-5.0.8::gentoo USE="-pax_kernel" 0 KiB [ebuild R ] x11-drivers/nvidia-drivers-355.11-r2:0/355::gentoo USE="X acpi gtk2 multilib tools -gtk3 -pax_kernel -uvm" 0 KiB [ebuild R ~] sys-fs/zfs-kmod-0.6.4.2::gentoo USE="-custom-cflags -debug -rootfs" 0 KiB 4 ebuilds, which is correct as far as I know. Here's what I was seeing this morning: 1447265816: Started emerge on: Nov 11, 2015 10:16:56 1447265816: *** emerge --autounmask --with-bdeps=y @module-rebuild 1447265853: >>> emerge (1 of 3) sys-kernel/spl-0.6.4.2 to / 1447265853: === (1 of 3) Cleaning (sys-kernel/spl-0.6.4.2::/usr/portage/sys-kernel/spl/spl-0.6.4.2.ebuild) 1447265853: === (1 of 3) Compiling/Merging (sys-kernel/spl-0.6.4.2::/usr/portage/sys-kernel/spl/spl-0.6.4.2.ebuild) 1447265855: *** Finished. Cleaning up... 1447265855: *** exiting unsuccessfully with status '1'. 1447265855: *** terminating. Unfortunately I don't have a complete log because I ^C'd it after seeing that it had only 3 ebuilds instead of including virtualbox, but you get the idea: definitely 1 of 3!
(In reply to Ben Kohler from comment #7) > I'm fairly certain that you did not have virtualbox-modules installed when > you first ran emerge @module-rebuild. The /usr/src/linux symlink is not > involved, emerge just checks the installed package DB for any installed > packages with files in /lib/modules and rebuilds those. Basically it looks > at /var/db/pkg/*/*/CONTENTS for any occurrence of /lib/modules. > > Either virtualbox-modules wasn't installed, or it was installed in some > broken way such that no files were installed to /lib/modules/. Ah, interesting... this could explain it for ONE of my two systems. I had previously ^C'd an unrelated 'emerge -avuDN world' during a downgrade build of virtualbox (which I did not desire; I wanted to upgrade to the next minor version, which meant I needed to keyword it). So perhaps I ^C'd it in just the right time to make @module-rebuild not detect it. That doesn't explain why my other system (where there was no such ^C during a build) didn't work. Is there anything I can investigate there?
You should be able to tell from emerge.log whether your "emerge virtualbox-modules" that was run after @module-rebuild was a reinstall or new install. You can tell based on whether there is an "Unmerging..." step listed right after the "Merging.." step. I'm guessing there will be no Unmerging.. step listed, which means the package was not already installed at the time.
In the next build involving virtualbox after the ^C: 1447266317: >>> AUTOCLEAN: app-emulation/virtualbox-modules:0 1447266317: === Unmerging... (app-emulation/virtualbox-modules-4.3.28) 1447266318: >>> unmerge success: app-emulation/virtualbox-modules-4.3.28
At this point we don't really have anything concrete to debug, so I'll close this.
