VirtualBox

Ticket #4928 (new defect)

Opened 5 years ago

Last modified 4 years ago

VMDK disk corrupt after discarding snapshots

Reported by: mast Owned by:
Priority: major Component: other
Version: VirtualBox 3.0.4 Keywords:
Cc: Guest type: Windows
Host type: Linux

Description

I had a working windows vista guest where I had made two successive snapshots. After discarding the snapshots, vista won't boot anymore, halting in the Windows Boot Manager with:

Status: 0xc00001 Info: An unexpected error has occurred.

I've not yet been able to verify the integrity of the ntfs file system.

There is more than 25 Gb of free space on the hosting file system. VBoxManage showhdinfo on the corrupt(?) disk image shows this:

UUID:                 be4813bf-f885-4c0d-c49b-c848c3a7039a
Accessible:           yes
Description:          
Logical size:         32768 MBytes
Current size on disk: 22170 MBytes
Type:                 normal (base)
Storage format:       VMDK
In use by VMs:        miffot (UUID: d7316699-797f-467b-b08b-24ef2687b1c4)
Location:             /home/mast/more/vms/windows-vista-x86_64/sysdisk.vmdk

Two logs attached: One before the snapshots were discarded, and one from a broken boot afterwards.

Attachments

VBox.log.3 Download (51.1 KB) - added by mast 5 years ago.
Log before problem
VBox.log Download (49.4 KB) - added by mast 5 years ago.
Log after the problem
VBox.2.log Download (49.4 KB) - added by mast 5 years ago.
Log after the problem

Change History

Changed 5 years ago by mast

Log before problem

Changed 5 years ago by mast

Log after the problem

Changed 5 years ago by mast

Log after the problem

comment:1 Changed 5 years ago by mast

Please ignore the last log. It was a duplicate attachment.

comment:2 Changed 5 years ago by mast

I did some things before the snapshot discardings that might be relevant:

  1. Took a backup (using cp -r) of the vm directory containing the vmdk and the snapshots.
  2. Ran virtualbox 3.0.6 b1 for a short while, but without making any changes to the snapshots or the vm configuration parameters.
  3. Removed the original vm directory and put the backup in its place.

Note that I did not backup and restore the .VirtualBox config dir during this. Is it possible that an inconsistency between the config xml file and the vm directory could produce this fatal result?

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use