[SOLVED] Debian guest losing data after shut down

[fluxflax]

Hello.

I been having a recurring problem that I have started my virtualbox with debian LAMP and working all day. When I shut it down and reboot all my work is lost and it reverted to data from two shutodowns ago.

Just be clear, here is a time line:
Day 1:
- Started my virtual machine
- Adding code and database changes to an application I am developing on my virtual machine all day.
- Shutting down the virtual machine in the evening.

Day 2:
- Started my virtual machine.
- Saw that my virtual machine was reverted back to how it started on day 1 and all my work was lost!
- Restarted the virtual machine and then the data was there again.
- Added some more code all day.
- Did a backup.
- Shutting down the virtual machine in the evening.

Day 3:
- Started my virtual machine.
- Saw that my virtual machine was reverted back to how it started on day 1 and all my work was lost for the last two days!
- Shutting down (using "shutdown -h now" on the command prompt) the virtual machine and starting it again did not help.
- Restarting my virtual machine by using "reboot" on the command prompt and the data was back!
- Did a backup.


Anybody heard of this problem?


One clue I might have is that some times a close the virtualbox by clicking the top right cross on the window and choosing "Send the shutdown signal" (see attached image)


Configuration
Host: Windows 7
Guest: Debian 6.0.5 with Apache2, PHP 5.4, MySQL 5
Virtulbox 4.2.12 r84980
2 GB space free space (so the problem is not that I ran out of space)

[mpack]

Possibilities:

1. You are running from a live CD, i.e. you haven't installed the guest OS properly yet (all your work has been stored on a RAM disk!).
2. You have configured an immutable drive.

[fluxflax]

Thanks for your reply.

1. I am not using a live CD. I have installed Debian + Apache2, PHP 5.4, MySQL 5
2. It is not an immutable drive.

[mpack]

Well, you seem to have excluded all possible explanations that I know of.

Perhaps it would help if you posted a VM log file. See Minimum information needed for assistance.

[fluxflax]

Here you go

[mpack]

That log file is incomplete. You ought to shut down the VM before posting a log file, or alternatively post the log file from a previous session (e.g. the .1 log file).

The issues I see so far are:

1. You only allocate 384MB RAM to the guest, which isn't much by modern standards. With your host you can afford 1GB.
2. Likewise you only assigned 12MB VRAM, I would expect the settings dialog to be warning you about that.
3. You have ancient GAs installed (3.2.10 OSE). You might consider updating these, though in truth I don't see how they could cause your problem.
4. I see that you recently suspended and resumed the VM. I'd like you see you do a full shutdown and restart.
5. I see that your primary disk is in VMDK format and has a disturbing name - "Appliance-disk4.vmdk". That name makes me wonder if this disk is in a valid format.
6. I see that you have a secondary drive also attached to the VM. "F:\virtualbox\data2.vdi". What is drive F? Why is this VM addressing drives located outside the VM folder?

[fluxflax]

Will take your list and go through it before getting back to you. I have to say I am very much thankful for your quick and competent feedback!

[fluxflax]

Hello again.

After some research based on your list I think I found the problem. The sixth point on your list gave me a clue.

I have been messing around with cloning drives. "F:\virtualbox\data2.vdi" is a clone of "Appliance-disk4.vmdk". I think during startup both drives somehow are fighting for being the boot drive. Depending on which drive that boots I get different data.

What I have done now is start a completely new virtual machine from scratch to address your points 1, 2, 3, 5 and 6.

Again, thank you very much for your help.

[mpack]

I don't doubt your analysis, but I'm surprised that having two duplicate drives in the same VM caused these symptoms. It implies some kind of conflict, but what conflicted with what? A drive will typically be addressed either by UUID or by location (IDE primary master or SATA ch#0 etc). Now the drives can't have had conflicting UUIDs, because VirtualBox doesn't allow that. The hardware locations shouldn't be shuffling around either.

Having two drives attached which both have full MBRs, boot partition marked etc is an obvious unusual factor. But, I have regularly in the past attached the boot drive of one XP VM to that of another XP VM, in order to access the complete drive as a kind of superuser - both XPs being clones of an original XP template - and I've never had a problem, though XP does have a very basic boot mechanism.

What boot method does your Debian guest use? I assume it's the Linux norm: BIOS to find the MBR and then grub boot from there, grub selecting the drive by location rather than UUID? And no LVM?

[fluxflax]

I have to say that I am not an expert on Debian boot process or the inner workings of the system. I can set up an basic LAMP webserver and tinker around a bit. So some of what I say may be nonsense.

The Debian guest do boot like you assume. I think because one of the drives has been cloned it has exactly the same setup in terms as UUID etc. I assume that the boot process connect to the drive that is ready first and then the boot process continue on that drive.

I do not use LVM to manage the drives. Everything is just on the same partition, very basic.

Just a couple of minutes ago I tried to add/remove the drives from the virtualbox manager so only one was present during boot up. Everything worked as intended, no switching between old and new data.

So I can conclude the problem was that I cloned my first drive and added the newly cloned one in the virtualbox manager. All the problems went away when I removed one of the drives.