[SOLVED] Grub fails after re-adding Ubuntu VM

[lobolmart]

hello,

i had to reinstall my host Windows 10 machine and didn't know about the correct backup procedure (import/export appliance) for my Ubuntu 17.04 VM which was running on that host.
so what i did is backup the Virtual Box VMs folder via regular copy.

after re-installing the host i've re-installed the same VirtualBox version from the setup EXE and chose Machine -> Add to add the same Virtual machine.
now starting the machine gives me a grub rescue command prompt saying:
"invalid arch-independent elf magic" and i don't know how to proceed.

what have i tried thus far after googling about this:
- tried the boot-repair application with default settings but it failed and told me that i should probably create a new boot partition which is a "closer to the BIOS".
- i've tried mounting the drive and then doing a grub-install from a live CD

both options didn't help.
please, mind that i'm not much of an expert when it comes to linux.

my work is on this VM and it took a lot of time to setup; is it still salvageable?

[socratis]

The procedure that you followed is the correct one. You do a normal file copy of the whole VM folder. Then you add the VM via Machine » Add. That is actually the proposed method in the FAQ: Moving a VM, where "Moving" can be interpreted as "Copying" or "Backing up". So, on that front you've done what you're supposed to do.

Now, as to your problem, do you still have the backup? I assume you do. I can think of a couple of things, like if the problem was there but it never surfaced, or something going wrong with the copy/restore. BTW I hope the medium you copied the VM to was not formatted as FAT32, was it? Because that has a limit of 4 GB/file and there would be serious truncation. I find both of these options to have a less than 1% possibility of happening for one reason; your VM boots.

I'll let the Linux experts handle the finer details of your Grub problem, but I don't believe it is a VirtualBox problem to tell you the truth.

[Perryg]

After you answer socratis concerns, elf issues at boot are almost always a grub related. Grub repair is out side of the scope here but without knowing what the repair showed and or said it repaired, there would be no way for anyone to tell you what happened. As for recovering your data that should be possible by attaching the broken guest vdi file to a working Linux guest as a second drive. You would then mount that drive ( standard Linux mount ) and recover what ever you need.

[lobolmart]

Now, as to your problem, do you still have the backup? I assume you do. I can think of a couple of things, like if the problem was there but it never surfaced, or something going wrong with the copy/restore. BTW I hope the medium you copied the VM to was not formatted as FAT32, was it? Because that has a limit of 4 GB/file and there would be serious truncation. I find both of these options to have a less than 1% possibility of happening for one reason; your VM boots.

I'll let the Linux experts handle the finer details of your Grub problem, but I don't believe it is a VirtualBox problem to tell you the truth.

thanks for the reply,

yes, i do still have the backup.
i copied the whole "VirtualBox VMs" folder to a backup drive which is formatted as NTFS. the Ubuntu VM in question has a big virtual disk - around 110GB.
and the backup seems intact as much as i can tell - i.e. i can see the folders of the virtual disk when i mount it under a live CD.

as a side note: there are no hardware changes and exactly the same Windows 10 version was installed on the host.

[lobolmart]

After you answer socratis concerns, elf issues at boot are almost always a grub related. Grub repair is out side of the scope here but without knowing what the repair showed and or said it repaired, there would be no way for anyone to tell you what happened. As for recovering your data that should be possible by attaching the broken guest vdi file to a working Linux guest as a second drive. You would then mount that drive ( standard Linux mount ) and recover what ever you need.

i will try posting the log from the boot-repair tool as soon as i can, should have saved that the first time...
it's 4am for me and i don't have access to the VM right now, so this will probably happen in something like 7-8 hours.

thanks

[lobolmart]

hello,

i've tried copy-pasting the old VM from the backup a second time and this time strangely it just started right away.
could it be that the first time the disk was corrupted during the copy?

i'm copying it between a regular HDD (backup drive) and an SSD (windows drive) and i was still able to mount it while running the live CD the first time.
...also the copy process didn't report any errors.

very strange...

[socratis]

Count your blessings that the corruption didn't happen the other way around, from the original to the backup. Imagine if you had a corrupted backup. Friendly suggestion, do not simply use 'cp', use something more robust like 'rsync'. Glad it worked at the end...

[lobolmart]

i'm now facing a lot of corruption on the disk drive.
fsck fixed a lot of things, but there are still a lot of corrupt files it seems.

i'm getting things like:

Code: Select all

rm: cannot remove <filename> Read-only file system

edit: i'm probably going to start re-installing everything in a new VM.

[pdonner]

I have a similar problem with Centos 7.3 and 5.2. May be related...

viewtopic.php?f=3&t=85158

Tomorrow I will look at repairing grub and seeing if that does the trick. However, after doing about 10 copy/moves to a second host and having them ALL break the same way as well as the lastest issue when I installed Guest Additions and rebooted and found my VM was broken the same way (booting to emergency mode). I think the problem is with base 5.2 and perhaps the extensions because during all 10 of the copy moves, there were no GA installed on the source VM.

[socratis]

I have a similar problem with Centos 7.3 and 5.2. May be related...

Actually it isn't. Except the fact that it involves VirtualBox, GRUB and failure...