- GUI: Improvements in Native Language Support area
- Main: OVF Export: Added support for exporting VMs containing Virtio-SCSI controllers
- Recording settings: Fixed a regression which could cause not starting the COM server (VBoxSVC) under certain circumstances (bug #21034)
- Recording: More deterministic naming for recorded files (will now overwrite old .webm files if present)
- Linux Host and Guest Additions installer: Improved check for systemd presence in the system (bug #19033)
- Linux Guest Additions: Introduced initial support for kernel 6.0
- Linux Guest Additions: Additional fixes for kernel RHEL 9.1 (bug #21065)
- Windows Guest Additions: Improvements in Drag and Drop area
Discuss the VirtualBox 6.1.38 release
Discuss the VirtualBox 6.1.38 release
This is a maintenance release. The following items were fixed and/or added:
-
- Posts: 5
- Joined: 20. Jul 2022, 15:45
Re: VirtualBox 6.1.38 released
6.1.38 solves the "failed to acquire com object" problem (viewtopic.php?f=7&t=106572) and allows me to start VirtualBox again, but now I have the problem that all VMs with a saved state fail to start...
This is on Ubuntu 22.04.
This is on Ubuntu 22.04.
Re: VirtualBox 6.1.38 released
Hi ermshiperete,ermshiperete wrote:6.1.38 solves the "failed to acquire com object" problem (viewtopic.php?f=7&t=106572) and allows me to start VirtualBox again, but now I have the problem that all VMs with a saved state fail to start...
This is on Ubuntu 22.04.
Could you please provide VBox.log for a VM which is unable to start from saved state?
-
- Site Moderator
- Posts: 20945
- Joined: 30. Dec 2009, 20:14
- Primary OS: MS Windows 10
- VBox Version: PUEL
- Guest OSses: Windows, Linux
Re: VirtualBox 6.1.38 released
@galitsyn, I responded to ermshiperete's post on the topic they were discussing this on, with suggestions on workarounds. I suspect that the Virtualbox version was changed while the VM was save-stated.
This is a duplicate post, @ermshiperete, which is a no-no.
This is a duplicate post, @ermshiperete, which is a no-no.
-
- Site Moderator
- Posts: 39134
- Joined: 4. Sep 2008, 17:09
- Primary OS: MS Windows 10
- VBox Version: PUEL
- Guest OSses: Mostly XP
Re: Discuss the VirtualBox 6.1.38 release
I have split this topic into the more typical announcement (locked), with a separate duscussion topic. This is the discussion topic.
-
- Site Moderator
- Posts: 39134
- Joined: 4. Sep 2008, 17:09
- Primary OS: MS Windows 10
- VBox Version: PUEL
- Guest OSses: Mostly XP
Re: Discuss the VirtualBox 6.1.38 release
Something pretty nasty seems to be going on with 6.1.38.
I have a Debian 11.4 (Bullseye) VM (LXDE) which I created in 6.1.36. After I upgraded to 6.1.38 this VM hung on boot. On a retry it booted, but only to the command line. I'm not enough of a Linux expert to know how to repair this, so I reverted to 6.1.36. This still did not allow me to boot past the command line, meaning the VM was damaged somehow. I had to restore the VM from a recent backup, but inevitably there are small differences which I'm still discovering and fixing.
I didn't want to find out if other VMs (e.g. Windows 10) can be are permanently corrupted too, so I've left it there for now. Hopefully some additional comments will soon allow us to pinpoint the exact failure.
I have a Debian 11.4 (Bullseye) VM (LXDE) which I created in 6.1.36. After I upgraded to 6.1.38 this VM hung on boot. On a retry it booted, but only to the command line. I'm not enough of a Linux expert to know how to repair this, so I reverted to 6.1.36. This still did not allow me to boot past the command line, meaning the VM was damaged somehow. I had to restore the VM from a recent backup, but inevitably there are small differences which I'm still discovering and fixing.
I didn't want to find out if other VMs (e.g. Windows 10) can be are permanently corrupted too, so I've left it there for now. Hopefully some additional comments will soon allow us to pinpoint the exact failure.
-
- Volunteer
- Posts: 5677
- Joined: 14. Feb 2019, 03:06
- Primary OS: Mac OS X other
- VBox Version: PUEL
- Guest OSses: Linux, Windows 10, ...
- Location: Germany
Re: Discuss the VirtualBox 6.1.38 release
If you've kept some VBox.log and VBoxSVC.log files and like to have a second opinion, ...mpack wrote:After I upgraded to 6.1.38 this VM hung on boot.
-
- Site Moderator
- Posts: 39134
- Joined: 4. Sep 2008, 17:09
- Primary OS: MS Windows 10
- VBox Version: PUEL
- Guest OSses: Mostly XP
Re: Discuss the VirtualBox 6.1.38 release
Sure, see attached.
- Attachments
-
- VBox.log.zip
- (37.24 KiB) Downloaded 16 times
-
- Volunteer
- Posts: 5677
- Joined: 14. Feb 2019, 03:06
- Primary OS: Mac OS X other
- VBox Version: PUEL
- Guest OSses: Linux, Windows 10, ...
- Location: Germany
Re: Discuss the VirtualBox 6.1.38 release
The attached log files seem not to match your story exactly (different VM, different time ranges):
The VBoxSVC.log file shows the time range from 15:50 to 16:00 UTC, VBoxSVC 6.1.38, the Extension Pack installation, three runs of the "Debian 11 Yocto Hardknott" VM and a VBoxSVC shutdown.
The VBox.log file shows the time range from 16:36 to 16:39 UTC, VirtualBoxVM 6.1.36 and a run of the "Debian 11 Yocto Hardknott" VM. I don't see anything wrong, except for the missing indication of enabling the graphical output, which matches your description.
A VBox.log file from the first VM run with VirtualBoxVM 6.1.38 could perhaps have been more interesting, but I suppose you already provided the oldest log file you still had available.
Another thing to look at would be the log files of the guest OS (e.g. /var/log/syslog, journalctl) after reproducing the problem.
A general idea: Since your host CPU has the VMCS Shadowing capability, you could use nested virtualization and try to reproduce the problem with a VirtualBox installation inside one of your VMs, while staying with VirtualBox 6.1.36 on your host.
The VBoxSVC.log file shows the time range from 15:50 to 16:00 UTC, VBoxSVC 6.1.38, the Extension Pack installation, three runs of the "Debian 11 Yocto Hardknott" VM and a VBoxSVC shutdown.
The VBox.log file shows the time range from 16:36 to 16:39 UTC, VirtualBoxVM 6.1.36 and a run of the "Debian 11 Yocto Hardknott" VM. I don't see anything wrong, except for the missing indication of enabling the graphical output, which matches your description.
A VBox.log file from the first VM run with VirtualBoxVM 6.1.38 could perhaps have been more interesting, but I suppose you already provided the oldest log file you still had available.
Another thing to look at would be the log files of the guest OS (e.g. /var/log/syslog, journalctl) after reproducing the problem.
A general idea: Since your host CPU has the VMCS Shadowing capability, you could use nested virtualization and try to reproduce the problem with a VirtualBox installation inside one of your VMs, while staying with VirtualBox 6.1.36 on your host.
-
- Site Moderator
- Posts: 39134
- Joined: 4. Sep 2008, 17:09
- Primary OS: MS Windows 10
- VBox Version: PUEL
- Guest OSses: Mostly XP
Re: Discuss the VirtualBox 6.1.38 release
As I mentioned earlier, I had since reverted to 6.1.36. While I preserved the damaged VM folder before restoring my backed up copy I did not preserve the .VirtualBox folder containing the VBoxSVC.log. However the provided VBoxSVC.log is from 6.1.38 and I attempted no other VMs, so it should have been just as good.
To be clear: I didn't expect the logs to show anything useful, I provided them because you asked. For now I don't intend to pursue the matter any further: I will simply skip 6.1.38 while keeping an eye on other user reports.
To be clear: I didn't expect the logs to show anything useful, I provided them because you asked. For now I don't intend to pursue the matter any further: I will simply skip 6.1.38 while keeping an eye on other user reports.
Edit: The previous VBox log is not the oldest I have. Attached is the oldest I have. However it is only from a minute or so earlier, so I have no idea what stage in my struggles that it represents. Of the four logs kept by VirtualBox, the two oldest were from 6.1.38 (and you now have them both), the more recent two were from 6.1.36 - i.e. during which I restored the older software but then established that this did not in fact recover the VM. It was after this that I renamed the VM folder and restored another from a two day old backup. [Edit2] I should have mentioned earlier that I think I saw brief glimpses in the Debian terminal of certification error messages which were not there before the 6.1.38 upgrade. However it flashed past before I had time to read or screenshot it. If VirtualBox 6.1.38 includes work on TPM or secure boot then perhaps it's associated with that. Perhaps those error messages are in a log somewhere, but as mentioned I'm not experienced in Linux. |
- Attachments
-
- VBox.log.3.zip
- (33.8 KiB) Downloaded 6 times
-
- Volunteer
- Posts: 5677
- Joined: 14. Feb 2019, 03:06
- Primary OS: Mac OS X other
- VBox Version: PUEL
- Guest OSses: Linux, Windows 10, ...
- Location: Germany
Re: Discuss the VirtualBox 6.1.38 release
mpack wrote:Attached is the oldest I have. However it is only from a minute or so earlier, so I have no idea what stage in my struggles that it represents.
The provided VBoxSVC.log probably was the perfect one, showing your first 6.1.38 run. The provided VBox.log.3 file corresponds to your second attempt (of three) to run the VM. Just like the VBox.log file provided earlier, it doesn't show anything unusual to me, except for the missing indication of enabling the graphical output. Both log files show more or less the same behavior. According to your detailed description, we don't have the VBox.log file from the initial VM run under VirtualBox 6.1.38, so that's a dead end for now.VBox-6.1.38-mpack overview wrote:2022-09-03T15:50:20Z VBoxSVC.log + 00:00:05.899715 ExtPackInst + 00:00:38.959471 Launched VM name: Debian 11 Yocto Hardknott + 00:04:40.809069 Launched VM name: Debian 11 Yocto Hardknott + 00:07:01.528430 Launched VM name: Debian 11 Yocto Hardknott + 00:08:37.643803 VirtualBox: object deletion starts 2022-09-03T15:55:05Z VBox.log.3 2022-09-03T16:36:24Z VBox.log
Perhaps this was a misunderstanding. From the VBoxSVC.log file provided, I looked at the VM names of all your VMs at the time 6.1.38 was installed, and saw "Debian 11 Yocto Hardknott" and "Debian 11.4 (Bullseye) 64bit Raw". Your log files showed that you've been running the former, but your initial description mentioned "Debian 11.4 (Bullseye) VM (LXDE)", which looks like the latter. That's why I thought that the provided log files might have been wrong.mpack wrote:It was after this that I renamed the VM folder and restored another from a two day old backup.
Did they occur right after the usual resolution switch from 720x400 to 800x600? Perhaps you've seen the two vmwgfx related warning/error messages, which are always displayed and cleared (on Linux guests when using VMSVGA), but not always seen: "[drm:vmw_host_log [vmwgfx]] *ERROR* Failed to send log"?mpack wrote:I should have mentioned earlier that I think I saw brief glimpses in the Debian terminal of certification error messages which were not there before the 6.1.38 upgrade. However it flashed past before I had time to read or screenshot it.
FWIW, I've skimmed through the VirtualBox source code diff between 6.1.36 and 6.1.38 a few days ago, but I didn't notice any backports regarding TPM and/or Secure Boot.mpack wrote:If VirtualBox 6.1.38 includes work on TPM or secure boot then perhaps it's associated with that.
Just keep the VDI file, and we can pursue this further at any time, if no-one else experiences your problem and we're inclined to do so. One possible next step then would be to add this VDI file as a second hard disk to another VM, mount it, and have a look at /var/log/syslog*.mpack wrote:Perhaps those error messages are in a log somewhere, but as mentioned I'm not experienced in Linux.
-
- Site Moderator
- Posts: 39134
- Joined: 4. Sep 2008, 17:09
- Primary OS: MS Windows 10
- VBox Version: PUEL
- Guest OSses: Mostly XP
Re: Discuss the VirtualBox 6.1.38 release
Ah, that rings a bell. The raw VM is my template Debian BullsEye VM. I created this first, in 6.1.36. My Yocto project VM was a clone of that raw VM, also created in 6.1.36 - this is the VM inside which I did most work thereafter.fth0 wrote: Perhaps this was a misunderstanding. From the VBoxSVC.log file provided, I looked at the VM names of all your VMs at the time 6.1.38 was installed, and saw "Debian 11 Yocto Hardknott" and "Debian 11.4 (Bullseye) 64bit Raw".
When the Yocto clone failed in 6.1.38 I reverted to 6.1.36, confirmed that the Yocto clone was still broken, and then briefly tested if the original raw VM was broken as well: it was not. Had it been broken too I might have been looking at some sort of coincidental corruption event and not the 6.1.38 update. However the original raw VM was still working in 6.1.36, as was the restored Yocto backup.
Essentially it was virtually the same VM both ways, run back to back, if it isn't the correct log then the contents should still be very close.
No, I'm familiar with those spurious warnings, it wasn't that. These were additional messages and the wording mentioned certification errors as I said.fth0 wrote:Did they occur right after the usual resolution switch from 720x400 to 800x600? Perhaps you've seen the two vmwgfx related warning/error messages, which are always displayed and cleared (on Linux guests when using VMSVGA), but not always seen: "[drm:vmw_host_log [vmwgfx]] *ERROR* Failed to send log"?mpack wrote:I should have mentioned earlier that I think I saw brief glimpses in the Debian terminal of certification error messages which were not there before the 6.1.38 upgrade. However it flashed past before I had time to read or screenshot it.
version 6.1.38 bug
After update to 6.1.38 version, my Linux guest Vm crashes on boot when i have a linux enternal usb connected to pc.
I have to boot the Vm first and then attach the usb. (maybe its guest addition version bug)
I have to boot the Vm first and then attach the usb. (maybe its guest addition version bug)
Last edited by mpack on 10. Sep 2022, 15:09, edited 1 time in total.
Reason: Moved topic to appropriate discussion.
Reason: Moved topic to appropriate discussion.
Re: Discuss the VirtualBox 6.1.38 release
Something strange with the lastest 6.1.38 release. Windows version running Linux x64.
Its about setup, everytime i reboot, the hard-drive got missing first letter after the path. Made a few test. Better explanation with the below.
D:\VM\disk.vdi -> after reboot D:\M\disk.vdi
D:\disk.vdi > after reboot D:\isk.vdi
Then i need to free and remove the unlocated disk. Attach it again and setup the vm with the disk again..
Its about setup, everytime i reboot, the hard-drive got missing first letter after the path. Made a few test. Better explanation with the below.
D:\VM\disk.vdi -> after reboot D:\M\disk.vdi
D:\disk.vdi > after reboot D:\isk.vdi
Then i need to free and remove the unlocated disk. Attach it again and setup the vm with the disk again..
-
- Site Moderator
- Posts: 20945
- Joined: 30. Dec 2009, 20:14
- Primary OS: MS Windows 10
- VBox Version: PUEL
- Guest OSses: Windows, Linux
Re: Discuss the VirtualBox 6.1.38 release
KshMlg, that's a really unusual problem! Please provide zips of the config files or screenshots of this happening, before and after please, uploaded with the forum's Upload Attachment tab.