Virtualbox install - sudden boot issue - nothing bootable found

Hi all… looking for any advice here.

I’m running HassOS as a Virtualbox VM (having recently migrated it from a a docker-based install on an old server). Everything has been running fine (mostly… still ironing out a few things) for a week or so, but now HassOS won’t start (freezes with 100% CPU usage). By running “record” on the initial startup in Virtualbox I was able to capture the following:

No idea what to do from here—looks like some kind of corruption of the EFI partition in the VDI maybe? Appreciate anyone’s thought on ways to fix, as I’d REALLY prefer not to do a re-install.

[as additional background, HassOS was installed using the recommended Virtualbox guide/VDI, and in the VM running on an Ubuntu Mate/Server 20.04 machine]

Tried using Rescatux to see if it could works its magic… nothing (UEFI check comes back good, other checks flag no bootloader in MBR)

Tried using SuperBootDisk… which sees a bunch of partitions (including ‘almost duplicates’ of the EFI partition… but when attempting manual boot of either one shows:
Screenshot at 2020-09-26 04-10-07

No luck so far trying to get this to boot, so now I’m trying to extract all of the config data from the VDI to rebuild. I can boot the VM in Virtualbox using an Ubuntu Live CD, and can see/access the ‘hassos-data’ folder/partition (which contains all of my config files and folders under the ‘supervisor’ folder, but I’m having issues copying the data anywhere.

Because I’m running a Live CD, I can’t use Guest Additions (so no Virtualbox shared folders etc).

When I try to use scp to copy data directly to my host server I get an input/output error (maybe a permissions issue with the ‘hassos-data’ partition?).

Any ideas?

My guess?
The files belong to another user and you aren’t in the group, so you will probably be denied copy permissions.

Use sudo when copying or moving the files.

Thanks… I was already sudo-ing (e.g. when using scp); however, I suspect the VDI partitions weren’t recognising privileges from thr Live CD (maybe?).

I have now managed to mount the VDI using qemu… so at least I have all my data.

I’ll try a fresh install and use the old config data etc. and see how I go.

Did you succeed to get a new VM working?

I have the same issue on my 2 testing VMs (I’m newbie and only have testing servers :slight_smile:).
It happened when I upgraded Virtual Box from 6.1.12 to 6.1.14 but it could have been a coincidence.

I’ve tried to build new VMs from the downloaded .vdi file, in both of the above versions of Virtual Box. In all cases, the VM boots and reboots several time . On one of the reboots (I think it’s the 3rd reboot) somehow it looses the boot configuration. The reboot process starts when it fails to start docker (see image attached)

Wondering what’s going on, and how can I make a new VM to work… This is a new install from the provided .vdi file, so I don’t understand why it fails.

Can anyone help?

Sorry @modem, this looks different to the issues I had - my clean installs work fine (and I’m running fine after a new clean install using the standard VDI—I managed to grab most of my setup data from the old VDI using qemu; still had a lot of cleaning up / fixing to do, but it got me a fair way there).

And when I had my boot issues, I wasn’t even getting as far as your boot seem to getting.

Have you checked the systemd logs as suggested by the error?

Well, that raises several questions… How to access the filesystem and where to find the log…
I was able to extract several .img files witn 7Zip, and I could open several of them also with 7Zip.

Mounting in Windows 10 did not work, maybe I need a different app for that.
Any ideas?

I’m running Ubuntu, so I used qemu to mount the VDI… something like this:

I then had access to all the logs and setting.

Thanks, I followed that guide without success, I got an error on the command

qemu-nbd -c /dev/nbd0 [path-to-vdi-file]

saying something like the VDI file was ending before expected.

I also tryed Sysinternal LinuxReader, it supports loading VM containers but I got the same output as when I accessed them with 7ZIP.

I eventually downloaded the VM in .OVA format, it created me automatically a new VM in Virtual Box. I got there the same error when trying to launch docker, but after a reboot it was finally launched and I could access the web interface. But other issues have arrised with the VM…
It’s too much effort to continue pursuing this path.

I need to free my Pi3 or Pi4 from their current roles to try HA there.