Summary: | app-emulation/virtualbox-guest-additions-4.2.6 segfaults due to missing sys-apps/dbus dependency | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Alex Barker <alex> |
Component: | Current packages | Assignee: | Lars Wendler (Polynomial-C) (RETIRED) <polynomial-c> |
Status: | RESOLVED TEST-REQUEST | ||
Severity: | normal | CC: | gabemarcano, patrick, rossi.f, swapon |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | .config |
Description
Alex Barker
2013-01-03 16:42:20 UTC
I am guessing sys-apps/dbus should be required by the guest additions. After installing manually, it appears to be working correctly. I recently experienced this issue and came to the same resolution. Gentoo guest on an OSX host. localhost ~ # vboxguest-service --foreground --verbose VBoxService 4.2.6_OSE r82870 (verbosity: 1) linux.amd64 (Jan 2 2013 19:29:45) release log 00:00:00.000128 main Log opened 2013-01-21T22:16:34.265029000Z 00:00:00.000326 main OS Product: Linux 00:00:00.000359 main OS Release: 3.5.0-gentoo 00:00:00.000377 main OS Version: #8 SMP Wed Aug 29 23:06:39 EDT 2012 00:00:00.000394 main OS Service Pack: #8 SMP Wed Aug 29 23:06:39 EDT 2012 00:00:00.000413 main Executable: /usr/sbin/vboxguest-service 00:00:00.000422 main Process ID: 14085 00:00:00.000427 main Package type: LINUX_64BITS_GENERIC (OSE) 00:00:00.003083 main 4.2.6_OSE r82870 started. Verbose level = 1 00:00:00.007246 main All services started. 00:00:00.010002 vminfo rtldrNativeLoad: dlopen('libdbus-1.so.3', RTLD_NOW | RTLD_LOCAL) failed: libdbus-1.so.3: cannot open shared object file: No such file or directory Segmentation fault localhost ~ # emerge -av dbus localhost ~ # vboxguest-service --foreground --verbose VBoxService 4.2.6_OSE r82870 (verbosity: 1) linux.amd64 (Jan 2 2013 19:29:45) release log 00:00:00.000193 main Log opened 2013-01-21T22:24:12.330475000Z 00:00:00.000291 main OS Product: Linux 00:00:00.000317 main OS Release: 3.5.0-gentoo 00:00:00.000339 main OS Version: #8 SMP Wed Aug 29 23:06:39 EDT 2012 00:00:00.000396 main OS Service Pack: #8 SMP Wed Aug 29 23:06:39 EDT 2012 00:00:00.000420 main Executable: /usr/sbin/vboxguest-service 00:00:00.000434 main Process ID: 27027 00:00:00.000443 main Package type: LINUX_64BITS_GENERIC (OSE) 00:00:00.004360 main 4.2.6_OSE r82870 started. Verbose level = 1 00:00:00.008717 main All services started. 00:00:00.011885 vminfo Error: Unable to connect to system D-Bus (1/3): Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory 00:00:05.023714 vminfo Error: Unable to connect to system D-Bus (2/3): Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory 00:00:10.027228 vminfo Error: Unable to connect to system D-Bus (3/3): Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory ^C 00:00:33.062191 main Ended. localhost ~ # /etc/init.d/dbus start * Caching service dependencies ... [ ok ] * Starting D-BUS system messagebus ... [ ok ] localhost ~ # vboxguest-service --foreground --verbose VBoxService 4.2.6_OSE r82870 (verbosity: 1) linux.amd64 (Jan 2 2013 19:29:45) release log 00:00:00.000177 main Log opened 2013-01-21T22:24:53.864620000Z 00:00:00.000287 main OS Product: Linux 00:00:00.000316 main OS Release: 3.5.0-gentoo 00:00:00.000426 main OS Version: #8 SMP Wed Aug 29 23:06:39 EDT 2012 00:00:00.000469 main OS Service Pack: #8 SMP Wed Aug 29 23:06:39 EDT 2012 00:00:00.000495 main Executable: /usr/sbin/vboxguest-service 00:00:00.000508 main Process ID: 27197 00:00:00.000515 main Package type: LINUX_64BITS_GENERIC (OSE) 00:00:00.003899 main 4.2.6_OSE r82870 started. Verbose level = 1 00:00:00.008074 main All services started. ^C 00:00:31.056456 main Ended. Confirmed also here +*virtualbox-guest-additions-4.2.6-r1 (10 Feb 2013) + + 10 Feb 2013; Lars Wendler <polynomial-c@gentoo.org> + +virtualbox-guest-additions-4.2.6-r1.ebuild, + +files/virtualbox-guest-additions-8.initd: + Depend on sys-apps/dbus (bug #450020). Rewritten init script. + Can you please give virtualbox-guest-additions-4.2.6-r1.ebuild a try. I'm especially interested in the new init script functioning correctly. (In reply to comment #4) > Can you please give virtualbox-guest-additions-4.2.6-r1.ebuild a try. I'm > especially interested in the new init script functioning correctly. I removed dbus and then updated the guest additions and it looks like dbus was pulled in correctly. I have tested the init script and that appears to be causing some issues on amd64. Initially it appears to start correctly with the rest of the system, however, after attempting a restart I am presented with the following sequence of errors: * Stopping virtualbox-guest-additions ... * start-stop-daemon: fopen `/var/run/vboxguest-service.pid': No such file or directory [ ok ] * Removing kernel modules * ERROR: virtualbox-guest-additions failed to stop Running `start-stop-daemon --make-pidfile --pidfile /var/run/vboxguest-service.pid --background /usr/sbin/vboxguest-service -- --foreground` manually produces a PID file that appears to be correct. When attempting to stop the service manually, it does produce an error "virtualbox-guest-additions failed to stop" but not complaining about a PID file. My best guess is something is messed up with the auto-magic that is responsible for calling start-stop-daemon in /sbin/runscript. If there is something I can do to debug that please let me know. Thanks! (In reply to comment #5) Sorry one more thing. Although it fails to stop cleanly, it appears to stop the process. Starting the process after issuing a ZAP seems to bring it back online just fine leading me to believe the stop processes is what is messed up. Let me know if you would like me to test any other ideas. Dear Alex, thanks for testing :) Unfortunately I cannot reproduce the error you're describing. The init script works flawlessly on my Gentoo test VMs. Out of curiosity: to what shell does your /bin/sh symlink point to? How fast is your host system and thus your VM you see this error? Maybe it's some kind of race condition I cannot reproduce on my VMs because they are too fast/slow. Tested, it works on my system Created attachment 338672 [details]
.config
(In reply to comment #7) > Dear Alex, > > thanks for testing :) > Unfortunately I cannot reproduce the error you're describing. The init > script works flawlessly on my Gentoo test VMs. > Out of curiosity: to what shell does your /bin/sh symlink point to? > How fast is your host system and thus your VM you see this error? Maybe it's > some kind of race condition I cannot reproduce on my VMs because they are > too fast/slow. This seems to be happening consistently for me. I have 8 cores allocated to the vm. 2048 MB RAM Acceleration is enabled. Intel(R) Core(TM) i7 CPU 950 @ 3.07GHz I did a little digging and found out its throwing that error due to exit 1 after the modprobe -r so ran the commands and go the following. crosscompiler ~ # /sbin/modprobe -r vboxsf ; echo $? modprobe: FATAL: Module vboxsf is in use. 1 crosscompiler ~ # /sbin/modprobe -r vboxguest ; echo $? modprobe: FATAL: Module vboxguest is in use. 1 So, lsmod: vboxsf 26834 1 ohci_hcd 15355 0 ehci_hcd 31764 0 usbcore 124260 2 ohci_hcd,ehci_hcd vboxguest 135660 1 vboxsf usb_common 1011 1 usbcore e1000 88241 0 Killing the running process first does not release the module. I was able to unload all of the modules in this way exact for those two. Nothing in the logs... this is really strange. After rmmod -f vboxsf it came out and left a dmesg entry. Feb 12 00:22:06 crosscompiler kernel: Disabling lock debugging due to kernel taint I had to do the same for vboxguest which caused a crash. I have attached my guest kernel config. Following is the dump: BUG: unable to handle kernel paging request at ffffffffa0037590 IP: [<ffffffff810caed8>] do_vfs_ioctl+0x3e8/0x43a PGD 160d067 PUD 1611063 PMD 7d23c067 PTE 0 Oops: 0000 [#1] SMP Modules linked in: ohci_hcd ehci_hcd usbcore usb_common e1000 [last unloaded: vboxguest] CPU 2 Pid: 2578, comm: vmstats Tainted: G R O 3.6.11-gentoo #4 innotek GmbH VirtualBox/VirtualBox RIP: 0010:[<ffffffff810caed8>] [<ffffffff810caed8>] do_vfs_ioctl+0x3e8/0x43a RSP: 0018:ffff88007a9e7ec8 EFLAGS: 00010286 RAX: ffffffffa0037550 RBX: ffff88007bfed800 RCX: 00007f34f3f7dcf0 RDX: 00000000c0105602 RSI: 00000000c0105602 RDI: 0000000000000003 RBP: 00000000ffffffe7 R08: ffff88007d059ed8 R09: 0000000000000a12 R10: 00007f34f3f7dcd0 R11: 0000000000000246 R12: 00007f34f3f7dcf0 R13: ffff88007a847100 R14: 00007f34f9082000 R15: 0000000000000003 FS: 00007f34f3f7e700(0000) GS:ffff88007fc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: ffffffffa0037590 CR3: 000000007ca53000 CR4: 00000000000006a0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process vmstats (pid: 2578, threadinfo ffff88007a9e6000, task ffff88007c3cef00) Stack: 00007f34f3f7dcd0 0000000000000000 0000000000000001 0000000000000000 0000000000000a12 ffffffff8105c6d4 00000000ffffffff ffff88007a9e7f10 ffff88007bfed800 0000000000000003 00000000c0105602 00007f34f3f7dcf0 Call Trace: [<ffffffff8105c6d4>] ? sys_futex+0x11b/0x14f [<ffffffff810caf75>] ? sys_ioctl+0x4b/0x72 [<ffffffff8134d022>] ? system_call_fastpath+0x16/0x1b Code: 85 c9 74 15 4c 89 e2 48 89 df ff d1 ba e7 ff ff ff 3d fd fd ff ff 0f 44 c2 89 c5 eb 2e 48 8b 43 20 bd e7 ff ff ff 48 85 c0 74 20 <48> 8b 40 40 48 85 c0 74 17 4c 89 e2 48 89 df ff d0 89 c5 3d fd RIP [<ffffffff810caed8>] do_vfs_ioctl+0x3e8/0x43a RSP <ffff88007a9e7ec8> CR2: ffffffffa0037590 ---[ end trace 6df7a521addb5e78 ]--- Looks like I should make the module unloading stuff optional. What do you guys think? (In reply to comment #11) > Looks like I should make the module unloading stuff optional. > > What do you guys think? I was thinking a simple warning and terminating properly would be enough. Even just using the return value form start-stop-daemon and ignoring the modprobe return values would be enough. if [ $? -nq 0 ] ; then ewarn "Could not remove module vboxsf." fi (In reply to comment #11) > Looks like I should make the module unloading stuff optional. > > What do you guys think? Quick update, Looks like the modules cannot be removed because there is a vboxfs share mounted. |