VirtualBox

Custom Query (16363 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (2020 - 2022 of 16363)

Ticket Resolution Summary Owner Reporter
#19311 invalid Changes on Archlinux 1/27/20 to support Linux 5.5 cause 10 min. boot of guest after downgrade to Linux 5.4 drankinatty
Description

This issue was first discussed on the virtualbox-users list on 2/4/20 under the thread "[VBox-users] 5.5 kernel and 5.2.36 - Does this not work with the new 5.2.36?"

Following direction to https://www.virtualbox.org/ticket/19145 I was directed to file a separate bug and submit the strace and dmesg output for the guest here.

I build the 5.2.x branch for the AUR repository. https://aur.archlinux.org/packages/virtualbox-bin-5/

During update on 2/4/20, Archlinux moved to Linux 5.5 kernel. The virtualbox drivers built and on reboot starting my Archlinux guest headless, virtualbox reports that the guest started. 5 minutes later the boot had yet to complete and a poweroff was issued. So I built with 5.2.36 - same result, so I built with testcase 5.2.37 (135942), same result.

After posting to the vbox-users list and being informed of https://www.virtualbox.org/ticket/19145 and 5.2 not yet supporting Linux 5.5 kernel, I downgraded my host. The same problem remained, but this time I just left the boot of a simple Archlinux guest that boot to a text console running. After 10 minutes -- the boot succeeded, but the guest was unusably slow.

For example, users cannot login because the 90 second login timeout expires between the time the user enters their user name and presses [Enter] and the display of the 'password:' prompt. root can login as there is no 90 second timeout (takes about 120 seconds for 'password:' to display after entering user name.

All was fine on 1/27/20 when I last updated the guest to the Linux 5.4.14 kernel. I have downgraded both the host and guest multiple times to the package/kernel state they were in on 1/14/20, 1/21/20, 1/24/20, and 1/27/20. The guests are still unusable. It is like a config or something similar was modified to support the 5.5 kernel that isn't reverted on downgrade (or something similar) that is causing the problem. That's the only reason I can think that downgrading the entire system before the point the problem appeared does not resole the issue. I have a number of guests I use, and all was well before the 5.5 update.

I have attached a strace of the communication between the Archlinux host and Archlinux guest. I am no expert interpreting the strace communications, but when each bit of I/O is taking more than 10 seconds -- that looks like an issue to me. I have also attached the dmesg output from the Archlinux guest after waiting though the 10 minute boot (it normally boots fully in less than 20 seconds).

I'm happy to provide anything else you can think of that may identify the issue.

#20896 fixed Changes to vdi image using vboximg-mount are not persistent jpt
Description

Hi,

File /new_vdi.vdi created by the VBox Machines' Management Tool, attached to a machine running Linux Debian Bullseye 64bits and partitionned/formated with gparted. That partition is then mounted and copying data (file "from_vm.txt") to it works fine, so power off machine and detach file from machine.

Then, using a terminal from the host, where /x and /y are two mountpoints for test :

1st run, writing file "from_host.txt" to vdi image :

vboximg-mount --rw -i /new_vdi.vdi -o allow_root /x/
mount /x/vol0 /y/
touch /y/from_host.txt
echo "try from host" > /y/from_host.txt 
sync
ls /y/ # --> from_host.txt  from_vm.txt  lost+found
cat /y/from_host.txt # --> "try from host"
umount /y/
umount /x/

Everything is fine.

2nd run, reading from vdi image :

vboximg-mount --rw -i /new_vdi.vdi -o allow_root /x/
mount /x/vol0 /y/
ls /y/ # --> from_vm.txt  lost+found
umount /y/
umount /x/

Written file "from_host.txt" lost !

Same problem here https://www.reddit.com/r/virtualbox/comments/mogadt/vboximgmount_readwrite_persistence/ or there : https://forums.virtualbox.org/viewtopic.php?f=7&t=96967&p=515917, and no one provides a good working command line.

Thanks a lot in advance.

#11892 obsolete Changeset 45436 slows down program in guest considerably kristiankarl
Description

Changeset https://www.virtualbox.org/changeset/45436/vbox (Disable TSC offsetting for SMP VMs) slows down program in guest considerably. I found this using the Spotify Desktop client. My guess is that it may have to do with CEF (https://code.google.com/p/chromiumembedded/) which it uses. I have not verified it with other clients using CEF, so I'm not sure as to why this changeset affects the Spotify client so hard...

Repro of problem:

1) VirtualBox installed on a Linux amd64 host

2) Launch a Windows 7 guest

3) Download and run latest Spotify windows desktop client (https://www.spotify.com/en/download/windows/)

4) The Spotify program runs super slow.

Fix the problem:

1) Fetch the latest version of VirtualBox OSE [source code]

2) Revert https://www.virtualbox.org/changeset/45436/vbox, or comment out lines 354-355 in src/VBox/VMM/VMMR3/TM.cpp

3) Build it and run it according to https://www.virtualbox.org/wiki/Linux%20build%20instructions

4) Launch a Windows 7 guest

5) Download and run latest Spotify windows desktop client (https://www.spotify.com/en/download/windows/)

6) The Spotify program runs fast.

Batch Modify
Note: See TracBatchModify for help on using batch modify.
Note: See TracQuery for help on using queries.

© 2024 Oracle Support Privacy / Do Not Sell My Info Terms of Use Trademark Policy