@kaptain_zero
Thanks for testing. Okay it appears than that older VirtualBox versions do not handle zerofree handled/packed ova files gracefully in some cases. I read something about this as well during bid internet research. Good that it works with the current version.
About the interface:
- Jep, the own hosts internet interface/adapter need to be chosen of course.
- Does it show any error there or offer my own hosts interface/adapter there on import? Maybe I can remove it by manually adjusting the ovf file before exporting. At least from within export GUI it is no possible to unselect the hosts adapter/interface without unselecting the whole network setting.
First off, a small update. My friend has successfully installed the image in Ubuntu by unzipping the *.OVA, for whatever that is worth.
I have yet to find the time to remove Virtuabox from my Ubuntu machine and pull down the newest version directly from Oracle, but I’m going to suspect that it would work fine.
Does it show any error there or offer my own hosts interface/adapter there on import? Maybe I can remove it by manually adjusting the ovf file before exporting
No errors, it’s just when you go to start for the first time, it complains there is no such interface, so please change it so the image can boot. I change it and away it goes.
I’ve run into similar things myself. I often export installed images of other operating systems as a backup and I sometimes transfer them to another computer. Most of my computers have 8GB of ram, but one has 16GB and an image on that machine was set to use as much ram as I could allocate on that machine. When I attempted to import and start that image on another machine, it would not start due to the lack of ram… it was easy to edit and then it was happy.
To who it may concern…
Both .ova and .img of native PC Bios x86-64 do not work on openmediavault with phpVirtualBox 5.0-5 / Virtualbox 5.1.14_Debianr112924.
Previous Diet-PI version did work, and i hope it will be fixed soon, I use DietPI as mini servers for pi-hole, vpn etc.
Kind regards,
Sander Dol
MichaIng, I believe he is using Openmediavault on an X86 computer (I’m guessing here) and is unable to install the new *.OVA in the Virtualbox that is running within the OMV guest OS for X86. The issue is not about the OMV implementation that was dropped in the Dietpi images. This is likely to be same problem as with attempting to import the current dietpi.ova into another guest OS such as Ubuntu 16.04 LTS. Something strange has happened since the switch to Debian and affects some guest hosts and not others. As I have been mentioning… it will not install without heroics such as decompressing the image first manually.
Perhaps that might be a possibility for sanderdol , uncompressing the *.ova and then attempting to install it?
Perhaps it is the guest OS being used to build the *.ova that is causing the issue? I have never had this issue with *.ova’s exported from a Ubuntu guest?
Ah of course, thanks for clarification. I should better not reply when already attempted to sleep 
.
Okay I installed VBox on my VBox now 
and test(ed) a bid around:
- Was able to identify the issue with the network interface: Indeed when I export appliance, even with OMF 1.0, my hosts network adapter is exported as well:
- Sadly it is not possible to avoid this, if you want to keep bridged mode chosen, and it is not possible to somehow set this value to auto-detect. Would be reasonable option, to allow VBox on VM start chose the first found network interface or allow startup with simply “no” interface chosen (as per setting) without showing an ugly error, but: and at least both show the same error
. It is not a big issue, as if you open VM settings, the right interface is chosen directly and the error offers to open network settings before startup. But for next VM images I will set , as this is at least right for some Linux hosts .
- The alternative would be to set non bridged network before exporting, e.g. NAT, but I needed to search around on first VBox attempts how to allow internet and SSH and then failed on setting up a manual network bridge on windows, which is not necessary since a while, as VBox brings it’s own bridged network driver… Thus I think it is a benefit to set this up for end users as default network mode, who then only need to open their guest network settings once press okay and are fine.
When unpacking the .ova via 7zip on Windows as well as on Debian (7z x .ova), I face an “unexpected end of file” error as well. The export actually went fine still, I am able to import and start the machine, but I guess older VBox versions didn’t finish the import when facing this, where newer versions maybe ignore or handle this error by possibly fix the file ending themself.
Extracting a fresh exported .ova without any packaging etc. shows the same error. I will see if I find time to try exporting from within Debian VM to see if this is Windows host specific.
Well, I would be happy with
eth0
as that is what I use… but honestly, it is not a big deal to change at import time.
I am glad that you were able to find a way to reproduce the
unexpected end of file
issue as it is awfully hard to fix when you cannot! :mrgreen:
It will be interesting to hear what you discover about the cause of the “unexpected end of file”. Perhaps it is the version of Virtualbox you are using that is causing the problem, in which case it’s an Oracle problem?!?!?!
Just a quick update… I never found time to install VB directly from Oracle, but Ubuntu released an update a few days ago and now the image imports without issues.
So thank you for all the efforts, and unfortunately it appears it was a slightly broken version of Virtualbox in Ubuntu 16.04 that caused the issue and NOT the image you provided.
Regards
Christian