VirtualBox

Ticket #2395 (closed defect: fixed)

Opened 6 years ago

Last modified 6 years ago

VirtualBox failing when a virtual machine is started at boot -> fixed in 2.0.4

Reported by: ZioNemo Owned by:
Priority: major Component: other
Version: VirtualBox 2.0.2 Keywords:
Cc: Guest type: Linux
Host type: Linux

Description

Hi, I have a strange problem:

I have a recent (2.0.2 PUEL) version of VirtualBox installed on a very up-to-date ubuntu 8.4 Hardy host.

I have a specialized Linux version (IPCop 1.4.21) as guest; this is based on a 2.4.36 kernel.

This virtual machine acts as firewall for the host and for the rest of my home network.

It works (I'm using it to write this!).

The strangeness begins if and when I start this virtual machine with

 USER=$VBOXUSER LOGNAME=$VBOXUSER start-stop-daemon --start --quiet --background --make-pidfile --pidfile $PIDFILE --name VBoxHeadless --chuid $VBOXUSER --startas /usr/bin/VBoxHeadless -- -s IPCop -a $VRDPADDR -p $VRDPPORT

from within one of the startup scripts (I do attach the complete script along with the /etc/network/interfaces file I use to setup the bridges).

If I do this the firewall machine starts ok and works (I can ssh into the machine and the whole firewall does work), but VirtualBox does not work ok anymore.

Symptoms are:

  • I cannot display the console with rdesktop -k en-us -a 16 192.168.0.5:4000 & because I get just a blank window and a (correct) message stating "WARNING: Remote desktop changed from 800x600 to 720x400.".
  • If I open VirtualBox GUI I see that the virtual machine is reported as "Running" (correctly).
  • If I try to start any other machine I get just a black window; not even the Sun splash screen.
  • if I manually stop and restart the firewall virtual machine (using the same scripts used at boot!) everything gets back to normal (I can use rdesktop, I can start other virtual machines, etc.).

I saw another, apparently similar bug that concerned the SDL libraries, but I do not think it is relevant here.

I also tried to move the start of the Virtual Machine to the very end of the boot sequence (S95vbox-ipcop in /etc/rc2.d), but nothing changed.

The behavior is very repetitive.

What did I do wrong?
Regards
ZioNemo

Attachments

vbox-ipcop Download (1.5 KB) - added by ZioNemo 6 years ago.
Script used to start/stop the Virtual Machine
interfaces Download (2.3 KB) - added by ZioNemo 6 years ago.
/etc/network/interfaces used to setup the bridges.
VBox.log Download (33.7 KB) - added by ZioNemo 6 years ago.
Log of the latest startup.

Change History

Changed 6 years ago by ZioNemo

Script used to start/stop the Virtual Machine

Changed 6 years ago by ZioNemo

/etc/network/interfaces used to setup the bridges.

Changed 6 years ago by ZioNemo

Log of the latest startup.

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

Oops!

I really made a mess.

How do I delete the duplicate attachment?

I assume I cannot remove the duplicate entry #2396, or can I?

Regards

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

Replying to ZioNemo:

How do I delete the duplicate attachment?

I assume I cannot remove the duplicate entry #2396, or can I?

Done.

comment:3 Changed 6 years ago by ZioNemo

Another data point:

In the "bad condition" (see above) I cannot cleanly stop the VM.

I tried in several ways:

su -c '/usr/bin/VBoxManage controlvm IPCop keyboardputscancode 1d 38 53' $VBOXUSER
su -c 'ssh -p 222 root@fw halt' $VBOXUSER
ssh -p 222 root@fw
  root@fw:~ # shutdown -h now

all I get on the logs is:

Oct 12 09:14:44 fw sshd[474]: Accepted publickey for root from 192.168.0.5 port 53585 ssh2
Oct 12 09:14:44 fw shutdown[476]: shutting down for system halt
Oct 12 09:14:44 fw init: Switching to runlevel: 0

... but the system continues to work almost normally (some daemons are actually killed, but sshd, for one, is alive and kicking)

I can kill the VM by:

start-stop-daemon --stop --quiet --pidfile $PIDFILE --name VBoxHeadless

but that is a bit drastic.

After that, if I restart the same VM, everything is back to normal and I can use any method I want to bring it down cleanly.

Pretty please help me!

I'm obviously ready to give any required support to the good soul who will try to debug this.

Regards ZioNemo

comment:4 Changed 6 years ago by ZioNemo

I just discovered something very wrong is happening in my client (when I'm in the "bad mode"): The clock seems stopped:

mauro@heimdall:/var/log$ ssh -p 222 root@fw
Last login: Sun Oct 12 11:51:39 2008 from heimdall.condarelli.it
root@fw:~ # date
Mon Oct 13 08:24:06 CEST 2008
root@fw:~ # hwclock
...looong wait, then <CTRL_C!>
root@fw:~ # hwclock -r
...looong wait, then <CTRL_C!>
root@fw:~ # date
Mon Oct 13 08:24:06 CEST 2008
root@fw:~ # date
Mon Oct 13 08:24:06 CEST 2008
root@fw:~ # date
Mon Oct 13 08:24:06 CEST 2008
root@fw:~ # date
Mon Oct 13 08:24:06 CEST 2008
root@fw:~ # sleep 3
...looong wait, then <CTRL_C!>
root@fw:~ #

This explains a lot of strange things happening, but I have no idea where to start to debug this.

comment:5 Changed 6 years ago by ZioNemo

It seems that: if the first Virtual Machine is started using VBoxHeadless [too] soon after installing vboxdrv module then the Real Time Clock in the client will not advance; it will remain set at the time of the start. This situation is stable until the client is killed. By "soon" I mean: one minute is "too soon". five minutes is "late enough".

I will make a few more tests.

comment:6 Changed 6 years ago by frank

Please could you have a look at #2247? Looking at your log file it seems that this bug report is a duplicate of #2247. Please fix the module source as described there and try again.

comment:7 Changed 6 years ago by ZioNemo

It is decidedly not the same, but could very well be a different symptom of the same bug!

The effect, in my case is I have a non-working timer in the VM if I start it before some time (I did not make precise calculations, but 300s "sounds good").

I will apply the patch and see what happens.

comment:8 Changed 6 years ago by ZioNemo

I did not make exhaustive testing, but a few reboots with the patched kernel driver seem to work well!

Many thanks.

I will leave as-is for a while.

If no further misbehavior surfaces I will let You know and You can close this bug.

Regards ZioNemo

comment:9 Changed 6 years ago by sandervl73

  • Status changed from new to closed
  • Resolution set to fixed
  • Summary changed from VirtualBox failing when a virtual machine is started at boot to VirtualBox failing when a virtual machine is started at boot -> fixed in 2.0.4
Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use