May be the case that Windows does not 'like' user Files being written directly to the Root of a drive as the Root 'Folder' is normally reserved for System Files and Folders.
I would suggest testing by creating a 'VirtualBox VMs' folder at D:\ and then check the behaviour when VM Folders are created/moved to that Folder.
Discuss the VirtualBox 6.1.38 release
Re: Discuss the VirtualBox 6.1.38 release
Here you have, i noticed after rebooting, setup vm lost first char from path locationscottgus1 wrote: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.
location="M/machine.vdi"
- Attachments
-
- Logs.zip
- (46.79 KiB) Downloaded 4 times
Re: Discuss the VirtualBox 6.1.38 release
Already tried instead of use of D: move it all into D:\VM without success, now the lost char its the VmultiOS wrote:May be the case that Windows does not 'like' user Files being written directly to the Root of a drive as the Root 'Folder' is normally reserved for System Files and Folders.
I would suggest testing by creating a 'VirtualBox VMs' folder at D:\ and then check the behaviour when VM Folders are created/moved to that Folder.
Re: Discuss the VirtualBox 6.1.38 release
After a few test more even using another path including spaces, the problem here, after make the setup for the vdi image and attach to the setup vm, its wrong saved. Just work in fly first time but if you close the vbox and reopened gets screwdmultiOS wrote:May be the case that Windows does not 'like' user Files being written directly to the Root of a drive as the Root 'Folder' is normally reserved for System Files and Folders.
I would suggest testing by creating a 'VirtualBox VMs' folder at D:\ and then check the behaviour when VM Folders are created/moved to that Folder.
- Attachments
-
- Captura.JPG (59.83 KiB) Viewed 4586 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
I cannot tell you where the problem comes from, but perhaps I can give you a hint:
The screenshot.JPG in the Logs.zip file shows that the first letter is not simply missing, but replaced by a second '\' (contrary to your initial description). So you probably have to look for some mechanism doubling the backslash in "D:\" ...
The screenshot.JPG in the Logs.zip file shows that the first letter is not simply missing, but replaced by a second '\' (contrary to your initial description). So you probably have to look for some mechanism doubling the backslash in "D:\" ...
-
- 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 think the error message may be a red herring. The only place in the .vbox file that mentions "NADIN" is in the media registry in the .vbox file, where the VDI path is "M/NADIN-Master-22.4_22.09.2022.vdi". Note that this is a relative path, which is often a problem, so wherever the vbox file is, let's say it's in the root folder of drive D, then VirtualBox expects to find the VDI file in the folder "D:\M", and the complete filename is "D:\M\NADIN-Master-22.4_22.09.2022.vdi".
I would bet that the M subfolder doesn't exist.
"\\" is a well known C convention indicating '\' is intended, rather than some control code e.g. \n, \b). I'm not exactly how C conventions arise here, but I'm guessing that's at the root somewhere.
So in summary, I think the actual problem here is that somebody has manually (and clumsily) edited a relative VDI path into a .vbox file after building a VM around a pre-existing VDI. The main VDI of a VM should be in the same folder as the .vbox file - there should be no need of paths for that file in the media registry.
Oh - and this has nothing to do with 6.1.38, because this VM never worked as is.
I would bet that the M subfolder doesn't exist.
"\\" is a well known C convention indicating '\' is intended, rather than some control code e.g. \n, \b). I'm not exactly how C conventions arise here, but I'm guessing that's at the root somewhere.
So in summary, I think the actual problem here is that somebody has manually (and clumsily) edited a relative VDI path into a .vbox file after building a VM around a pre-existing VDI. The main VDI of a VM should be in the same folder as the .vbox file - there should be no need of paths for that file in the media registry.
Oh - and this has nothing to do with 6.1.38, because this VM never worked as is.
Re: Discuss the VirtualBox 6.1.38 release
You are right, after moving the .vbox setup file from D:\ path root drive into the same where the vdi is stored. Works!
Setup remain the same and the whole path stays. Still see the same location path including the whole path location="D:\VirtualBox VMs/machine.vdi"
Setup remain the same and the whole path stays. Still see the same location path including the whole path location="D:\VirtualBox VMs/machine.vdi"
-
- Posts: 8
- Joined: 30. Oct 2015, 16:10
- Primary OS: Ubuntu 12.04
- VBox Version: OSE Debian
- Guest OSses: Linux Mint, Windows 7, Windows 10, Mac OS 10.6.8
Re: Discuss the VirtualBox 6.1.38 release
Hi,
I am also seeing strange things happening with this 6.1.38 release. There are two classes of strangeness:
1) Windows aren't being displayed properly. It's like the menu bars of both the VirtualBox and the guest have been shifted up by about half their width, and the bottom part of the window has strange repetition of stripes of what should be there. This occurs for a Windows 10 and a Linux Mint 18.3 guest OS, and in full-screen mode. It makes most of the top menu bar unreadable and inaccessible.
2) Difficult startup for the Linux Mint guest OS. This happened the first couple of times after the upgrade and now it starts ok, but still has the issue from #1. The OS would hang on boot until I maximized and restored the window a couple of times, then the screen would come back and be normal, except that the desktop was unresponsive to the the mouse and keyboard. It "went away" after several forced shutdowns and reboots.
I'm attaching a couple of screen captures to demonstrate issue #1 which is the real problem for me. I have nothing on issue #2 but I'm reporting it in case others have seen something like it. Happy to provide any other information...
VirtualBox 6.1.38 r153438
Host: Linux Mint 20.3, 64bit 64 GB RAM
Guest: Windows 10, 64 bit, 5 GB RAM
Charles
I am also seeing strange things happening with this 6.1.38 release. There are two classes of strangeness:
1) Windows aren't being displayed properly. It's like the menu bars of both the VirtualBox and the guest have been shifted up by about half their width, and the bottom part of the window has strange repetition of stripes of what should be there. This occurs for a Windows 10 and a Linux Mint 18.3 guest OS, and in full-screen mode. It makes most of the top menu bar unreadable and inaccessible.
2) Difficult startup for the Linux Mint guest OS. This happened the first couple of times after the upgrade and now it starts ok, but still has the issue from #1. The OS would hang on boot until I maximized and restored the window a couple of times, then the screen would come back and be normal, except that the desktop was unresponsive to the the mouse and keyboard. It "went away" after several forced shutdowns and reboots.
I'm attaching a couple of screen captures to demonstrate issue #1 which is the real problem for me. I have nothing on issue #2 but I'm reporting it in case others have seen something like it. Happy to provide any other information...
VirtualBox 6.1.38 r153438
Host: Linux Mint 20.3, 64bit 64 GB RAM
Guest: Windows 10, 64 bit, 5 GB RAM
Charles
- Attachments
-
- VirtualBox.zip
- (136.4 KiB) Downloaded 6 times