#22059 closed defect (fixed)
Save State stuck at 0% since recent update (Arch Linux, Vbox 7.0.16r162802) => fixed in svn/7.0.x x>18
Reported by: | hans.werner | Owned by: | |
---|---|---|---|
Component: | other | Version: | VirtualBox-7.0.16 |
Keywords: | stuck saving state | Cc: | hans.werner |
Guest type: | Windows | Host type: | Linux |
Description (last modified by )
Problem Description
Since last update a week ago (or so) I can not save the win11 state (running -> save). However, I can save the state of all other machines (Linux, Win Server 2003, 2008, 12 etc). When I am saving it does not matter, e.g. during guest reboot or after running the guest a few min or anything else. It is just stuck at 0%. Logs and Debug are NOT showing any information (except SUSPENDING -> SUSPENDED -> SAVING) Cloning the machine, reverting to previous snapshots, making more disk space on host or things like that, and then trying to save the current state does not work either. Exporting and Reimporting does not work either.
uname -a
-> Linux 6.8.7-zen1-1-zen #1 ZEN SMP PREEMPT_DYNAMIC Wed, 17 Apr 2024 x86_64 GNU/Linux
cat /etc/os*
-> arch/rolling
vbox --version
-> 7.0.16r162802
Tried solutions:
- Reset to old save state and restore (doesn't fix anything)
- Deleting old save state (doesn't fix anything)
- cleaned up disk space (122 GB available, 40 GB vdi sizes) && Resizing HDD/Medium (vboxmanage modifyhd/medium win11.vdi --resize <size in mb> -> does not help)
- Full Machine Export/Reimport (Appliance)
- Deleting all snapshots and nvram file (or moving them out of the folder and resetting the state -> no success)
- full device reboot
- full device update
Once the saving process is started, it is unstoppable, except by forcefully terminating it e.g. by running sudo kill -9 $(pgrep -i vbox && pgrep -i virtualbox)
BTW: Log file does not indicate anything special but it is attached.
Possible related Reddit:
/Edit:
Problem seems prevalent in version 7.0.18-1 (host-dkms, vbox and guest-utils)
/Edit2:
Affected Version(s): All versions above 7.0.14 (so .16 and .18)
Temp fix:
- downgrade
Workaround by Oracle:
a workaround is to configure the VM to use a USB 3.0 (xHCI) controller
UPDATE 08.07.2024 18:00BT: Temporary solution:
- https://www.virtualbox.org/download/testcase/VirtualBox-7.0.19-163782-Linux_amd64.run (Linux amd64 testbuild v. 7.0.19)
Attachments (6)
Change History (36)
by , 6 months ago
Attachment: | win11-2024-04-29-14-14-44.log added |
---|
by , 6 months ago
Attachment: | win11_exported_1-2024-04-29-15-09-04.log added |
---|
by , 6 months ago
Attachment: | 29_Apr_2024_BugReportOracle.png added |
---|
by , 6 months ago
Attachment: | 29_Apr_2024_BugReportOracle_1.png added |
---|
comment:2 by , 6 months ago
Interestingly, it works after killing it (see above) as long Win 11 is not loaded, see ss below. Maybe a bug in Guest Additions? Too much memory to save? IDK - Logs are telling NOTHING.
comment:4 by , 6 months ago
I tried https://superuser.com/questions/623989/virtual-box-stuck-at-starting-virtual-machine-0 - no success. Also, I've played around with the settings (disable Network, other Media, CPU setttings, Mem settings, enabled/disabled AMD-V/intel-x etc
comment:5 by , 6 months ago
Tried full reinstall (paket purge, files purge etc) using pacman -R $(pacman -Q | grep -i virtualbox) and pacman -S virtualbox -> does NOT work.
comment:6 by , 6 months ago
I tried it with a fully fresh Tiny11 and it worked out of the box. I tried to figure out whether the shrinking and growing of disk sizes is a problem. Turns out: It's not a or the problem! There is no possibility to debug this, as there is no increase log level option (tried the wiki instructions for it) and there are no error messages in the log. So it seems without further instructions by Oracle we can not find out more about that.
Not sure if EFI plays a significant role in this.
comment:7 by , 6 months ago
I am seeing this problem also for a Windows XP guest on Windows 11 host. It started for me with 7.0.18 (updated from 7.0.14) and it persists in the test version 7.0.19.
comment:8 by , 6 months ago
With Tiny11 it worked until now, after I've installed everything (in the guest) and ran Windows Update (shortly before the whole machine got stuck when it was running!)
Now it's again stuck in the save state at 0%
- Might it be the missing KB5036980???
- OR is it the mapped network drive?
No clues in the logs
00:01:53.321212 GUI: UISession::sltAdditionsChange: GA state really changed, notifying listeners 00:01:53.321446 GUI: UIMachineViewNormal::adjustGuestScreenSize: Adjust guest-screen size if necessary 00:01:53.321528 GUI: UISession::sltAdditionsChange: GA state change event came, notifying listeners 00:01:53.321534 GUI: UIMachineLogicNormal::sltCheckForRequestedVisualStateType: Requested-state=1, Machine-state=6 00:01:53.321554 GUI: UISession::sltAdditionsChange: GA state change event came, notifying listeners 00:01:53.321559 GUI: UIMachineLogicNormal::sltCheckForRequestedVisualStateType: Requested-state=1, Machine-state=6 00:02:12.170204 VMMDev: Guest Log: Shared Clipboard: WM_CLIPBOARDUPDATE failed with VERR_ACCESS_DENIED 00:02:39.408595 Console: Machine state changed to 'OnlineSnapshotting' 00:02:39.429124 Saving state of VM, reason 'Snapshot' 00:02:39.429176 Changing the VM state from 'RUNNING' to 'SUSPENDING' 00:02:39.433766 GUI: UIMediumEnumerator: Medium-enumeration finished! 00:02:40.400456 PDMR3Suspend: 971 230 656 ns run time 00:02:40.400471 Changing the VM state from 'SUSPENDING' to 'SUSPENDED' 00:02:40.400781 Changing the VM state from 'SUSPENDED' to 'SAVING' 00:04:13.173796 SSM: Cancelled pending operation 00:06:25.454237 GUI: UIMachineView::sltPerformGuestResize: Omitting to send size-hint 1279x959 to guest-screen 0 because frame-buffer is already of the same size. 00:06:25.482005 GUI: UIMediumEnumerator: Medium-enumeration finished! 00:06:26.916666 GUI: UIMediumEnumerator: Medium-enumeration finished! 00:06:50.302280 GUI: UIMediumEnumerator: Medium-enumeration finished! 00:06:51.257090 VMMDevNotifyGuest: fAddEvents=0x80 ignored because enmVMState=18
Seemingly something changed in vbox making it overall really unstable! :O How did that even pass Software testing?
comment:9 by , 6 months ago
RonSMeyer1 gave me an important hint, thus saved my ass! Leading to a temp fix via downgrade!
Temp Fix (run as root):
/usr/bin/rcvboxdrv stop kill -9 $(pgrep -i vbox && pgrep -i virtualbox); wget "https://download.virtualbox.org/virtualbox/7.0.10/VirtualBox-7.0.10-158379-Linux_amd64.run" chmod u+x VirtualBox-7.0.10-158379-Linux_amd64.run ./VirtualBox-7.0.10-158379-Linux_amd64.run usermod -a -G vboxusers hostuser
The old version can be found by using the https://www.virtualbox.org/wiki/Download_Old_Builds_7_0 page (just type "Vbox 7.0 old version" in ur fav search eninge). Then "all distributions" on your selected version in this case 7.0.10.
His post: https://forums.virtualbox.org/viewtopic.php?t=111508#p548057
I [b][u]recommend to use 7.0.14ub, I tested it and it works. [b]7.0.16 bhas the "stuck in 0% saving state" bug!
comment:10 by , 6 months ago
Description: | modified (diff) |
---|
comment:11 by , 6 months ago
Description: | modified (diff) |
---|
comment:12 by , 6 months ago
Description: | modified (diff) |
---|
comment:13 by , 6 months ago
Description: | modified (diff) |
---|
by , 6 months ago
Attachment: | TempDowngradeDoc_1.png added |
---|
by , 6 months ago
Attachment: | TempDowngradeDoc_2.png added |
---|
comment:15 by , 6 months ago
Repost in 7.0.18 related bugs, as it's applying to all above 7.0.14! https://www.virtualbox.org/ticket/22071
comment:16 by , 6 months ago
This issue also occurs on OpenSUSE Leap 15.5, with both 7.0.16 and 7.0.18. Using the distro kernel 5.14.21-150500.55.59-default.
follow-up: 19 comment:17 by , 5 months ago
Thanks for the report. There is no need for separate tickets for different VirtualBox versions so I've closed #22071 as a duplicate of this ticket. It looks like a regression in the USB OHCI support was introduced in VirtualBox 7.0.16 which thus affects VMs configured to use either a USB 1.1 or USB 2.0 controller. Rather than downgrading a workaround is to configure the VM to use a USB 3.0 (xHCI) controller.
comment:19 by , 5 months ago
Replying to paulson:
Thanks for the report. There is no need for separate tickets
Thank you very much. I mean if nobody sees it and nobody replies to it after multiple days, except users panicking why their VMs are suddenly have stopped working and Oracle and the VBox Team is silent...
Also the SEO of the bug tracker is so crappy that I decided to post it separately, to link the affected versions and to make google index it properly, as well as giving users' the opportunity to see and read it, nobody looks into the old versions in a bug tracker under normal circumstances.
It looks like a regression in the USB OHCI support was introduced in VirtualBox 7.0.16 which thus affects VMs configured to use either a USB 1.1 or USB 2.0 controller.
What I do not get: why playing around with a feature that works fine in the first place ? Did anyone test this before rolling it out? I am sorry if I sound frustrated or angered but this is just the reality for me as an user.
Rather than downgrading a workaround is to configure the VM to use a USB 3.0 (xHCI) controller.
Does not that only work with your vbox extension pack ?
As far as I know, there is no option for USB 3.0 by default. I even tried playing around with the USB Controller (enabling, disabling, switching between the availabe options) in my first runs, which did not work. But maybe it works now idk.
Lessons learned: I will not trust new versions of vbox for now. They just break things and suck performance for such "features", causing unnecessary efforts.
A nice warning popup for the users' would be nice, when their machine can be possibly affected by this issue. Or a auto-fix deployed by VBox.
comment:20 by , 5 months ago
Replying to sideral:
I can confirm that this workaround appears to work.
The downgrade or the USB 3.0 switch?
comment:21 by , 5 months ago
Description: | modified (diff) |
---|
comment:22 by , 5 months ago
I had the same problem in my environment (Win11 host, Win10 guest). I can confirm, that setting USB Controller to USB 3.0 solved this for me
follow-up: 26 comment:23 by , 5 months ago
We've pushed a fix for this issue to the Testbuilds and would appreciate feedback on its efficacy from users who have run into this. You can download a 7.0.x build or development snapshot corresponding to your host OS to try it out. There is no need to update the Guest Additions or the Extension Pack (the latter should be the 7.0.18 one if you're on Windows host, older ones wouldn't work). If users could let us know here if the Testbuilds addresses the issue described here for VMs configured with an OHCI USB controller that would be much appreciated.
Also to answer the question above: xHCI/USB 3.0 support is included by default in VirtualBox 7.0 and thus the Extension Pack is no longer required for xHCI support.
comment:24 by , 5 months ago
Having the same issue here running 7.0.18-162988. Can confirm that switching to USB 3.0 controller seems to fix it. I also tried the latest test build (7.0.x revision 163377) with USB 2.0 controller, and it does seem to be fixed there as well.
comment:25 by , 5 months ago
Another +1 for the workaround mentioned here - VirtualBox 7.0.18 r162988, Windows 10 guest and host, with the guest originally using the USB 1.1 controller. Switching to USB 3.0 resolved the issue.
comment:26 by , 5 months ago
Replying to paulson:
We've pushed a fix for this issue to the Testbuilds and would appreciate feedback on its efficacy from users who have run into this. You can download a 7.0.x build or development snapshot corresponding to your host OS to try it out. There is no need to update the Guest Additions or the Extension Pack (the latter should be the 7.0.18 one if you're on Windows host, older ones wouldn't work). If users could let us know here if the Testbuilds addresses the issue described here for VMs configured with an OHCI USB controller that would be much appreciated.
Also to answer the question above: xHCI/USB 3.0 support is included by default in VirtualBox 7.0 and thus the Extension Pack is no longer required for xHCI support.
I ran into this on 7.0.18-162988, and I can confirm that upgrading to the 7.0.19-163426 testbuild fixed it for me, without having to change any settings.
comment:28 by , 4 months ago
Description: | modified (diff) |
---|
comment:29 by , 4 months ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Summary: | Save State stuck at 0% since recent update (Arch Linux, Vbox 7.0.16r162802) → Save State stuck at 0% since recent update (Arch Linux, Vbox 7.0.16r162802) => fixed in svn/7.0.x x>18 |
VirtualBox 7.0.20 was released today which resolves this issue. It can be downloaded from the usual location: https://www.virtualbox.org/wiki/Downloads
comment:30 by , 7 weeks ago
Is this really fixed? I can still reproduce the bug in 7.0.20 and 7.1.0...
I did a pacman -Syuuu and general update and saw this:
I'll test it now, looks promising.
/EDIT: Never mind, it's still broken.
pacman -Q | grep virtualbox
and
00:01:35.613975 PDMR3Suspend: 2 714 444 ns run time
00:01:35.613986 Changing the VM state from 'SUSPENDING' to 'SUSPENDED'
00:01:35.613998 Console: Machine state changed to 'Paused'
00:01:36.538584 GUI: Request for close-action to save VM state.
00:01:36.538600 GUI: Saving VM state..
00:01:36.544810 Console: Machine state changed to 'Saving'
00:01:36.545387 Changing the VM state from 'SUSPENDED' to 'SAVING'
-- after that no log --