Windows 10 guest crashes AND destroys MBR-host permissions
Re: Windows 10 guest crashes AND destroys MBR-host permissions
Belay that last --- used Synaptic Package Manager to reinstall ntfs-3g. I'll run some test and see what goes. More concerned at this point how that driver became corrupted BUT, that's not for these forums.
Re: Windows 10 guest crashes AND destroys MBR-host permissions
Good thought but the ntfs-3g driver was not the fault --- system crashed again following a reinstall, wiped the MBR and changed the host file system to read-only. Now, before you folks start shouting such is not possible consider this --- the PC shop that did a 36 hour low-level test of my hard drive (which showed no problems) setup a lab PC similar to my setup and reproduced the same result --- they also have a PC with similar setup running without the shared folder configuration and so far no issues.
So here's the deal IMHO --- a Windows 10 VM accessing an NTFS partition through a Linux host does not play well together. Maybe it's LM 17.3, maybe it's W10 or who-knows-what. The fact is, one should not use a W10 VM to write and read to an NTFS partition going thru a Linux 17.3 host machine. I therefore won't being doing so.
Thanks to all who tried to help out on this --- I think it's a BUG!
So here's the deal IMHO --- a Windows 10 VM accessing an NTFS partition through a Linux host does not play well together. Maybe it's LM 17.3, maybe it's W10 or who-knows-what. The fact is, one should not use a W10 VM to write and read to an NTFS partition going thru a Linux 17.3 host machine. I therefore won't being doing so.
Thanks to all who tried to help out on this --- I think it's a BUG!
-
- Site Moderator
- Posts: 34369
- Joined: 6. Sep 2008, 22:55
- Primary OS: Linux other
- VBox Version: OSE self-compiled
- Guest OSses: *NIX
Re: Windows 10 guest crashes AND destroys MBR-host permissions
Only way to get it fixed then is to raise a ticket at bugtracker with diagnostician information and link to this topic.Thanks to all who tried to help out on this --- I think it's a BUG!
-
- Volunteer
- Posts: 2561
- Joined: 30. May 2007, 18:05
- Primary OS: Fedora other
- VBox Version: PUEL
- Guest OSses: XP, Win7, Win10, Linux, OS/2
Re: Windows 10 guest crashes AND destroys MBR-host permissions
The crash is most probably a bug, Vbox should never take down the host os.
But we don't yet know if it is only a Vbox bug, maybe it is also a host os bug which cannot handle an application crashing in such a way.
Also the NTFS/MBR problem is not "created" by VBox, it is a subsequent error created by the host os with ntfs-3g which doesn't survive such a host crash.
But we don't yet know if it is only a Vbox bug, maybe it is also a host os bug which cannot handle an application crashing in such a way.
Also the NTFS/MBR problem is not "created" by VBox, it is a subsequent error created by the host os with ntfs-3g which doesn't survive such a host crash.
-
- Site Moderator
- Posts: 27329
- Joined: 22. Oct 2010, 11:03
- Primary OS: Mac OS X other
- VBox Version: PUEL
- Guest OSses: Win(*>98), Linux*, OSX>10.5
- Location: Greece
Re: Windows 10 guest crashes AND destroys MBR-host permissions
I completely agree. But it cannot be a VirtualBox bug, simply because VirtualBox does not have access to that part of the disk. Not even read-only. It's like saying that going to an ATM and putting my cash card opens the main vault inside the bank. Every time. Of course there is a bug somewhere, but it's definitely not in my cash card.
Do NOT send me Personal Messages (PMs) for troubleshooting, they are simply deleted.
Do NOT reply with the "QUOTE" button, please use the "POST REPLY", at the bottom of the form.
If you obfuscate any information requested, I will obfuscate my response. These are virtual UUIDs, not real ones.
Do NOT reply with the "QUOTE" button, please use the "POST REPLY", at the bottom of the form.
If you obfuscate any information requested, I will obfuscate my response. These are virtual UUIDs, not real ones.
-
- Site Moderator
- Posts: 39134
- Joined: 4. Sep 2008, 17:09
- Primary OS: MS Windows 10
- VBox Version: PUEL
- Guest OSses: Mostly XP
Re: Windows 10 guest crashes AND destroys MBR-host permissions
I agree. This has to be a problem with the host drive, either a physical problem or a driver bug - or both. The "invalid handle" error is something I would only typically expect to see with a removable drive, e.g. after the drive has been unplugged and then plugged back in again: all open transactions should fail with "invalid handle".socratis wrote:I completely agree. But it cannot be a VirtualBox bug
But, all of this still can't result in a corrupted MBR. The only way to corrupt an MBR is to overwrite it with something else, and why would any task be writing to the MBR? ... though the thought occurs that if the drive does get unplugged (internally, never mind physically) and then plugged back in, then conceivably an ongoing write might default to location zero on the drive, which is the MBR. Note that it is the drive or its driver which would have this default, not VirtualBox. VirtualBox really has nothing to do with it: despite appearances, VirtualBox is not writing to the host drive at any time. Only the host OS does that, via its driver.
So, why would the drive go offline? Perhaps some kind of problem with energy saving settings on the host and their interaction with the host's NTFS driver.
Definitely not a VirtualBox problem.
-
- Posts: 114
- Joined: 22. May 2010, 23:27
- Primary OS: Debian other
- VBox Version: PUEL
- Guest OSses: many
- Location: Germany
Re: Windows 10 guest crashes AND destroys MBR-host permissions
Just stumbling in out of curiosity:
I myself ran into a couple of misunderstandings while learning to use virtualisation - and i still do occasionally - and the hint, that lets me think of a similar problem here is the lack of clarity in distinguishing host installments and guest use. It would be interesting to learn a few things, as many different scenarios could be mixed up.
I have several host OS myself, with each of them able to start a host vbox process, while in use, accessing THE SAME VM's (only recommended, if you have a means to deal with the different directories in a proper way, which seams difficult with the difference in Windows path names (backslash) compared to Linux Mint (forward slash) )
Another scenario (as assumed by someone) would be the raw disk access by any guest, but i think, you would know, what this means, if you used it.
But since Guest Folders were mentioned several times, this points to guests accessing some filesystem ony, which would in fact prohibit MBR corruption on the host. Thus it may also be possible, that the use of partitioning tools from 2 different OS may cause corruption, especially, since the OP (or some of his preferred tools) doesnt seem to be aware of the differences between MBR and GPT partitionning.
Indeed, i think, communication is key to make the OP understand differences before asking questions, and also from the OP to be careful at using terminology, that has specific meanings to the skilled user, without even noticing the bias himself.
Good luck at sorting this out!
I myself ran into a couple of misunderstandings while learning to use virtualisation - and i still do occasionally - and the hint, that lets me think of a similar problem here is the lack of clarity in distinguishing host installments and guest use. It would be interesting to learn a few things, as many different scenarios could be mixed up.
I have several host OS myself, with each of them able to start a host vbox process, while in use, accessing THE SAME VM's (only recommended, if you have a means to deal with the different directories in a proper way, which seams difficult with the difference in Windows path names (backslash) compared to Linux Mint (forward slash) )
Another scenario (as assumed by someone) would be the raw disk access by any guest, but i think, you would know, what this means, if you used it.
But since Guest Folders were mentioned several times, this points to guests accessing some filesystem ony, which would in fact prohibit MBR corruption on the host. Thus it may also be possible, that the use of partitioning tools from 2 different OS may cause corruption, especially, since the OP (or some of his preferred tools) doesnt seem to be aware of the differences between MBR and GPT partitionning.
Indeed, i think, communication is key to make the OP understand differences before asking questions, and also from the OP to be careful at using terminology, that has specific meanings to the skilled user, without even noticing the bias himself.
Good luck at sorting this out!
-
- Site Moderator
- Posts: 39134
- Joined: 4. Sep 2008, 17:09
- Primary OS: MS Windows 10
- VBox Version: PUEL
- Guest OSses: Mostly XP
Re: Windows 10 guest crashes AND destroys MBR-host permissions
Just to make it clear for the Nth time... shared folders are NOT a filesystem.
A filesystem is a data structure, like an index, stored on disk to help the OS find files and manage the disk contents. The filesystem has a specific documented format: FAT, EXTx, NTFS, ISO-9660 etc.
A "shared folder" is a piece of software that works like FTP does. When you (the VM side client) ask the software what's on the disk, the software asks the server OS and then tells you. If you ask it for data then it reads from a host file and tells you. This software has absolutely no idea how data is organized, it knows sweet FA about filesystems and partitions, and it is incapable of giving the client side physical access to anything and therefore it is absoiutely impossible for this to result in filesystem damage unless the host OS is buggy.
The map is not the territory. The map is a piece of paper.
A filesystem is a data structure, like an index, stored on disk to help the OS find files and manage the disk contents. The filesystem has a specific documented format: FAT, EXTx, NTFS, ISO-9660 etc.
A "shared folder" is a piece of software that works like FTP does. When you (the VM side client) ask the software what's on the disk, the software asks the server OS and then tells you. If you ask it for data then it reads from a host file and tells you. This software has absolutely no idea how data is organized, it knows sweet FA about filesystems and partitions, and it is incapable of giving the client side physical access to anything and therefore it is absoiutely impossible for this to result in filesystem damage unless the host OS is buggy.
The map is not the territory. The map is a piece of paper.
-
- Site Moderator
- Posts: 27329
- Joined: 22. Oct 2010, 11:03
- Primary OS: Mac OS X other
- VBox Version: PUEL
- Guest OSses: Win(*>98), Linux*, OSX>10.5
- Location: Greece
Re: Windows 10 guest crashes AND destroys MBR-host permissions
At least *I* learned something new from this thread. Sweet FA? Funny Addams? That's a nice British expression I can't say I've heard before.mpack wrote:sweet FA
Thanks Don
Do NOT send me Personal Messages (PMs) for troubleshooting, they are simply deleted.
Do NOT reply with the "QUOTE" button, please use the "POST REPLY", at the bottom of the form.
If you obfuscate any information requested, I will obfuscate my response. These are virtual UUIDs, not real ones.
Do NOT reply with the "QUOTE" button, please use the "POST REPLY", at the bottom of the form.
If you obfuscate any information requested, I will obfuscate my response. These are virtual UUIDs, not real ones.
-
- Site Moderator
- Posts: 39134
- Joined: 4. Sep 2008, 17:09
- Primary OS: MS Windows 10
- VBox Version: PUEL
- Guest OSses: Mostly XP
Re: Windows 10 guest crashes AND destroys MBR-host permissions
I think you'll find that "Fanny Addams" is a British rhyming slang cleanup for the real phrase (which is what I was actually thinking off) , which I don't think is solely British - I think dem Yanks, Canadians and Aussies use it too...
Or perhaps I'm wrong. Wikipedia seems not to mention the other meaning I thought it had... I'm sure Wikipedia can always be entirely trusted.
Or perhaps I'm right: the link you gave is not the same one I read. Your link has both definitions.
Or perhaps I'm wrong. Wikipedia seems not to mention the other meaning I thought it had... I'm sure Wikipedia can always be entirely trusted.
Or perhaps I'm right: the link you gave is not the same one I read. Your link has both definitions.