VirtualBox

Ticket #14341 (closed defect: fixed)

Opened 2 years ago

Last modified 3 months ago

4.3.28 & 4.3.30 guest additions prevent logout -> fixed in 4.3 and later as of August 5 2015

Reported by: Mike255 Owned by:
Priority: major Component: guest additions
Version: VirtualBox 4.3.30 Keywords:
Cc: Guest type: Linux
Host type: Windows

Description

I just installed 4.3.30 of VB on my Windows 7 machine.

I run a Linux Mint KDE 17.1 64bit VM in that VirtualBox.

After I installed 4.3.30, I installed the 4.3.30 guest additions. Then I shutdown the VM. I then restarted the VM, logged in, and after it had completed logging in, I attempted to logout. I got a black screen, where I could not type, it would attempt to capture the mouse when I clicked on it, but nothing else worked and I had to power the VM off to shut it down.

So I reinstalled 4.3.28, reinstalled the 4.3.28 guest additions and tried the same exact scenario w/ exactly the same results (obviously I hadn't tried logging off of this VM since I had installed 4.3.28).

However I also have an older VM which I started up and logged in on, and it was running 4.3.26 guest additions. That VM had no problems returning to the display manager login screen on logout. And that worked both in VB 4.3.28 and in 4.3.30 (after I had installed it again). So I think it's safe to say the issue is in a change in the Guest Additions from version 4.3.26 to 4.3.28, that was not changed in 4.3.30.

I think this may be related to the KDM display manager, as I think I recently created another VM that was otherwise similar (Linux Mint 17.2 64bit KDE) that was using MDM and it returned to the DM login screen when I logged out.

Attachments

VBoxStartup.log Download (455.4 KB) - added by Mike255 2 years ago.
VBox.log Download (104.9 KB) - added by Mike255 2 years ago.
Xorg.0.log.old Download (27.9 KB) - added by Mike255 2 years ago.
The /var/log/Xorg log from when the VM hung on logout (retrieved after a powerdown and restart)
syslog-logout-hang Download (81.7 KB) - added by Mike255 2 years ago.
relevant section of the syslog

Change History

Changed 2 years ago by Mike255

Changed 2 years ago by Mike255

comment:1 follow-up: ↓ 2 Changed 2 years ago by michael

Could you try installing 4.3.26 Additions in the machine which failed to log out to see if that makes a difference? You could also do the reverse, installing 4.3.30 Additions in the working machine (take a snapshot first if you are worried about not being able to revert).

Other things which would be of interest: /var/log/Xorg.*.log at the time of the hang (one of those files if there are several will be the current one) and indeed checking whether the Xorg process is still running. Checking the system log for anything of interest would be good too. Finally precise steps to reproduce this with a fresh machine would be good.

comment:2 in reply to: ↑ 1 Changed 2 years ago by Mike255

I'm happy to try these things and provide more information but I will need some help

  1. How do I get ahold of guest additions 4.3.26 to install w/o reinstalling VirrtualBox 4.3.26 on Windows first? I have always installed by using the "Insert Guest Additions CD Image"
  1. I don't know of any way to check if the Xorg process is running when the VM hangs, I can't interact w/ the VM in any way which is why I have to power it off to shut it down.

The current Xorg*.log didn't seem interesting (from what I can tell it is created when the VM starts? But the previous one (from what I assume is the previous start of the VM which hung on logout) does look like it might have relevant info, so I've attached it here.

Also the syslog looked like it might have some interesting info (I've cut it down to just the relevant time period and have attached it) such as:

Jul 29 08:24:45 LM17-VM2 kernel: [   11.131155] vboxguest: module verification failed: signature and/or  required key missing - tainting kernel
...
Jul 29 08:27:43 LM17-VM2 kdm[1547]: X server for display :0 terminated unexpectedly
Jul 29 08:27:43 LM17-VM2 kdm[1547]: Unable to fire up local display :0; disabling.

Lastly I'll see about trying to figure out steps to reproduce this starting by installing a fresh iso, but that will probably have to wait until the weekend.

Changed 2 years ago by Mike255

The /var/log/Xorg log from when the VM hung on logout (retrieved after a powerdown and restart)

Changed 2 years ago by Mike255

relevant section of the syslog

comment:3 Changed 2 years ago by michael

Right, that X.Org log file does contain interesting information. You can get old Additions versions from our download page<1>, but I don't think that part is necessary any more. Instructions to reproduce with a fresh machine would be very welcome though.

<1>  http://download.virtualbox.org/virtualbox/

comment:4 Changed 2 years ago by Mike255

Steps to set up a reproducible system

From VirtualBox 4.3.30 on Windows

  1. Create New Linux Ubuntu 64 VM
  2. Give it 2GB RAM
  3. Create a 12GB VDI Dynamically allocated Drive
  4. Start it w/ the latest linuxmint-17.2-kde-64bit-rc.iso (see  http://www.linuxmint.com/edition.php?id=196)
  5. Install Linux Mint (double click icon on desktop)
    • I did a guided use entire disk install
  6. reboot and login
  7. start konsole
  8. sudo apt-get update
  9. sudo apt-get purge virtualbox-guest-dkms virtualbox-guest-utils virtualbox-guest-x11
    • that removes the pre-installed 4.3.10 guest additions
  10. insert the guest additions CD (open w/ dolphin which will mount it at /media/{user}/VBOXADDITIONS_4.3.30_101610)
  11. cd to that directory
  12. sudo ./VBoxLinuxAdditions.run
  • (I shutdown and restarted so I could see if the issue also exists w/ mdm) (logout works w/ mdm)
  1. sudo apt-get kdm
  2. select kdm as the default display manager
  3. shutdown
  4. restart
  5. see the kdm display manager and login
  6. logout (VM is hung at black screen)

comment:5 Changed 2 years ago by michael

I was able to reproduce this and to fix it locally. Could you please try the 5.0 Additions build (note: not the 4.3 one) on our test build page<1>? Thanks.

<1> Testbuilds

comment:6 Changed 2 years ago by Mike255

The problem is fixed w/ that test build of guest additions. Here's what I did:

I doublechecked the issue was still present, then I installed the guest additions from VBoxGuestAdditions_5.0.1-101929.iso

The install output:

Verifying archive integrity... All good.
Uncompressing VirtualBox 5.0.1 Guest Additions for Linux............
VirtualBox Guest Additions installer
Removing installed version 4.3.30 of VirtualBox Guest Additions...
Copying additional installer modules ...
Installing additional modules ...
Removing existing VirtualBox DKMS kernel modules ...done.
Removing existing VirtualBox non-DKMS kernel modules ...done.
Building the VirtualBox Guest Additions kernel modules ...done.
Doing non-kernel setup of the Guest Additions ...done.
You should restart your guest to make sure the new modules are actually used

Installing the Window System drivers
Installing X.Org Server 1.15 modules ...done.
Setting up the Window System to use the Guest Additions ...done.
You may need to restart the the Window System (or just restart the guest system)
to enable the Guest Additions.

Installing graphics libraries and desktop services components ...done.

Then I shutdown the VM and restarted. And the issue was no longer present, logging out displayed the KDM display manager as I would expect, and I was able to log in and out again.

Thank you. Can I ask if you have a one sentence description of what the problem was? Why KDM had the problem but other display managers were working OK?

comment:7 Changed 2 years ago by michael

KDM (at least this particular version) uses a feature of the X server which most other display managers do not: restarting the X server without stopping and restarting the X server process, which it does at the end of a log-in session. A recent change to the driver did not work well with this.

comment:8 Changed 2 years ago by michael

  • Summary changed from 4.3.28 & 4.3.30 guest additions prevent logout to 4.3.28 & 4.3.30 guest additions prevent logout -> fixed in 4.3 and later as of August 5 2015

Ahem, not quite awake yet - thank you for testing and confirming the fix.

comment:9 Changed 2 years ago by Ender

Hello, Michael. Could it be possible to get the commit(s) that you added to the 4.3 branch, maybe?

I'd like to backport that into Debian unstable at least. The 5.0 packages from experimental are also affected (I guess because you fixed this at some point after 5.0 as Mike reported success with the 5.0.1 additions).

The assertion that I'm getting in the server when logging from KDM to my KDE session is:

[...]
[   412.144] (II) VBoxVideo(0): Using default gamma of (1.0, 1.0, 1.0) unless otherwise stated.
[   412.144] (II) VBoxVideo(0): RandR 1.2 enabled, ignore the following RandR disabled message.
[   412.144] 
Assertion failed!

[   412.144] originalX == VBOX_VIDEO_MAX_VIRTUAL && originalY == VBOX_VIDEO_MAX_VIRTUAL
[   412.144] at setModeRandR12 (/build/virtualbox-4XFIa4/virtualbox-5.0.0-dfsg/src/VBox/Additions/x11/vboxvideo/vboxvideo.c:348)
[   412.144] OriginalSize=800x600(EE) 
Fatal server error:
[   412.145] (EE) Assertion(EE) 
[   412.145] (EE) 
[...]

Just to make sure we are talking about the same thing. :-)

comment:11 Changed 2 years ago by michael

This fix is already scheduled to be in any future 4.3 releases. And yes, that is the commit which fixes it. Since you are asking I can also give a little bit more background, so you know what you are back-porting.

Due to a bug in X.Org Server 1.3, it was not possible to set a virtual resolution during a server generation greater than the initial one. We worked around this by temporarily setting a massive initial resolution, then correcting it as soon as the server had picked it up. At some point we broke this and did not notice at once, as we don't test much with that old server version. So I added a check which caused the server to crash if we broke it again accidentally, and this check runs on newer server versions too (it has to in order to be useful).

However, the X server has a feature called generations which let you restart it without ending the Xorg process. Most systems do not use this, but kdm does seem to, and our fix never worked with later generations. So, my check kicked in and crashed the server when kdm started a second generation after the first generation server was logged out. The fix makes sure that the resolution is set up correctly in later generations too. (The check is still in place of course.)

comment:12 Changed 2 years ago by Ender

Many thanks for the detailed explanation. I'll try to slip that in 4.3.30 and/or 5.0 as soon as possible.

You should close this ticket as well. :-)

comment:13 Changed 2 years ago by Ender

I just rebuilt virtualbox with your patch and I cannot go through the login process. I'm running VBox 5.0.0 in an OS X host with Yosemite (but I can downgrade to 4.3.30 if that helps) and I switched back from kdm to xdm to decouple my problems from kdm. So far I don't see the assertion but my sessions get this error:

[...]
[   607.870] (II) VBoxVideo(0): Output VGA-0 has no monitor section
[   607.870] (II) VBoxVideo(0): Not using built-in mode "953x446" (height too large for virtual size)
[   607.870] (II) VBoxVideo(0): Not using built-in mode "2560x1600" (height too large for virtual size)
[   607.870] (II) VBoxVideo(0): Not using built-in mode "2560x1440" (height too large for virtual size)
[   607.870] (II) VBoxVideo(0): Not using built-in mode "2048x1536" (height too large for virtual size)
[   607.870] (II) VBoxVideo(0): Not using built-in mode "1920x1600" (height too large for virtual size)
[   607.870] (II) VBoxVideo(0): Not using built-in mode "1920x1080" (height too large for virtual size)
[   607.870] (II) VBoxVideo(0): Not using built-in mode "1680x1050" (height too large for virtual size)
[   607.870] (II) VBoxVideo(0): Not using built-in mode "1600x1200" (height too large for virtual size)
[   607.870] (II) VBoxVideo(0): Not using built-in mode "1400x1050" (height too large for virtual size)
[   607.870] (II) VBoxVideo(0): Not using built-in mode "1280x1024" (height too large for virtual size)
[   607.870] (II) VBoxVideo(0): Not using built-in mode "1024x768" (height too large for virtual size)
[   607.870] (II) VBoxVideo(0): Not using built-in mode "800x600" (height too large for virtual size)
[   607.870] (II) VBoxVideo(0): Not using built-in mode "640x480" (height too large for virtual size)
[   607.870] (II) VBoxVideo(0): No remaining probed modes for output VGA-0
[   607.870] (II) VBoxVideo(0): Output VGA-0 connected
[   607.870] (WW) VBoxVideo(0): Unable to find initial modes
[   607.870] (EE) VBoxVideo(0): Output VGA-0 enabled but has no modes
[   607.870] (EE) VBoxVideo(0): Initial CRTC configuration failed!
[   607.870] (EE) 
Fatal server error:
[   607.870] (EE) AddScreen/ScreenInit failed for driver 0
[   607.870] (EE) 
[   607.870] (EE) 
Please consult the The X.Org Foundation support 
	 at http://wiki.x.org
 for help. 
[   607.871] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
[   607.871] (EE) 

but previously (without your patch) it was able to get a valid modeline always:

[   341.088] (II) VBoxVideo(0): Printing probed modes for output VGA-0
[   341.088] (II) VBoxVideo(0): Modeline "953x446"x60.0   26.01  953 955 957 959  446 448 450 452 (27.1 kHz Pb)
[   341.088] (II) VBoxVideo(0): Output VGA-0 connected
[   341.088] (II) VBoxVideo(0): Using exact sizes for initial modes
[   341.088] (II) VBoxVideo(0): Output VGA-0 using initial mode 953x446
[   341.089] (II) VBoxVideo(0): Using default gamma of (1.0, 1.0, 1.0) unless otherwise stated.
[   341.089] (II) VBoxVideo(0): RandR 1.2 enabled, ignore the following RandR disabled message.

I'm thinking of downgrading everything, and also another possibility is using the Guest additions snapshot from 5.0.1 that you recommended before.

Anything that I'm ignoring?

comment:14 Changed 2 years ago by Ender

This is getting worse. I removed every Debian package from my system (including kernel modules) and I installed 5.0.x revision 102020. Now when I start my session, no matter if it's through KDM or startx, I get a black screen that doesn't go away. No console switching either.

The Xorg.0.log file shows the same Not valid modes error from above:

[    30.564] (II) VBoxVideo(0): Not using built-in mode "640x480" (height too large for virtual size)
[    30.564] (II) VBoxVideo(0): No remaining probed modes for output VGA-0
[    30.564] (II) VBoxVideo(0): Output VGA-0 connected
[    30.564] (WW) VBoxVideo(0): Unable to find initial modes
[    30.564] (EE) VBoxVideo(0): Output VGA-0 enabled but has no modes
[    30.564] (EE) VBoxVideo(0): Initial CRTC configuration failed!
[    30.564] (EE) 
Fatal server error:
[    30.564] (EE) AddScreen/ScreenInit failed for driver 0
[    30.564] (EE) 
[    30.564] (EE) 
Please consult the The X.Org Foundation support 
         at http://wiki.x.org
 for help. 
[    30.564] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
[    30.564] (EE) 

I'm going to revert my entire VBox installation to something before 4.3.30 to see if I see something different.

comment:15 Changed 2 years ago by michael

Could you please provide a full Xorg.0.log file?

comment:16 Changed 2 years ago by michael

You could also provide a copy of the Additions that you built. Testing them on a different virtual machine (and finding out what the difference is if they work there) would be interesting.

comment:17 Changed 2 years ago by Ender

I have no idea of what could happened. I had some of the logs and even had a video with the dark screen, but to be honest, I did a final try last Sunday with 5.0.2 and reinstalling KDE and it seems that it worked. Sorry to be mysterious but I'm as perplexed as you probably are.

So...Debian has upgraded to 5.0.2 and this doesn't show up anymore. On my part, I consider this closed. :-)

comment:18 Changed 2 years ago by michael

I know exactly how that is. Chances are that you accidentally hit some other issue which is entirely valid but not clear how to reproduce. But if you or anyone else does hit it again a new ticket is probably more appropriate. Thanks again.

comment:19 Changed 3 months ago by michael

  • Status changed from new to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use