Virtualbox image fails
-
Hi! I’ve run into an odd situation that I don’t know how to address.
I’m attempting to deploy an image from our FOG server onto a VirtualBox instance. When I try, it goes like this:
- VirtualBox successfully boots from FOG;
- VirtualBox successfully registers as a host with FOG;
- I use the console to set up a deploy task for the new host, and reboot VirtualBox;
- It appears to pull an image, but it’s much, MUCH faster than expected, and the image is only 100 MB instead of 2 GB.
- It reboots, and fails to load Windows.
The image screens go by too fast to read, but I used VirtualBox’s video capture to record this happening and stepped through frame by frame. Here are some screen captures of what seem like key moments:
Apologies for the blurry text, the video had some pretty aggressive compression. Is that broken pipe and the following “aborted” message on the second screen normal?
I’m a longtime Linux user, but a comparative FOG newbie, having inherited this system from a coworker who left for greener pastures a few weeks ago. I don’t know what’s going on, or why it’s apparently sending only 100 MB instead of the 2 GB I was expecting. any suggestions welcome.
Thanks.
-
What version of fog are you using???
-
@wdmartin As you see in the first screen it says /dev/sda1 where it shows /dev/sda2 in the second screen (
Not expanding ...). So the 100 MB is only the first partition but not the whole image. The second partition fails. My guess is that the destination disk (in the VM) is simply too small to fit the sda2 image!Please check the original partition table (
/images/<image-name>/d1.partitions) on the FOG server to see what size the original disk was. You need to create the VM disk at least that big in your case - using legacy format partimage and sda2 obviously being a RAW/imager partition. Post the contents ofd1.partitionshere and we should be able to help you calculate the original disk size. -
@Sebastian-Roth Would it be hard to implement an error warning specifically for hard drive size?
-
@Quazz I thought about that a couple of times but never got to it. As well I am not exactly sure if we always have the information (original disk size) available. It’s probably easy to grep (and then calculate) if we have d1.partitions but would be a little bit trickier to get from d1.mbr (although possible I suppose). Would you please open a new topic in “Feature Requests” section and we see what we can come up with.
-
I don’t think this was uploaded at all. First, if you uploaded Part Image would not be the binary in use for deploying to a host.
-
@Wayne-Workman The version is 1.2.0.
@Sebastian-Roth I looked, and there is no
d1.partitionsfile as far as I can see. The image is stored in/images/Win7GeneralStaffSysprep, which contains the following:wdmartin@FOG:/images/Win7GeneralStaffSysprep$ ls -hal total 28G drwxrwxrwx 2 root root 4.0K May 12 2015 . drwxrwxrwx 32 fog root 4.0K Feb 9 09:58 .. -rwxrwxrwx 1 root root 8.5M May 12 2015 rec.img.000 -rwxrwxrwx 1 root root 28G May 12 2015 sys.img.000I tried making a fresh VirtualBox with 30 GB of allocated space. Unfortunately, it displayed the exact same behavior: grabbed a tiny 100MB image, then rebooted and found no OS.
-
@wdmartin This seams to be a very old image. We now usually have files like d1.mbr (MBR plus partition table) and possibly d1.partitions (partition table in text format). So it’s not easy to find out which size the original disk was! The size you see for the file (28G) is most probably only the data (compressed). So the original partition might have been a lot bigger!!
The easiest thing for you would be to create a large VMDK disk (not pre-allocated so it won’t be full size from the start anyway) - try 512 GiB or even 1 TiB. Then try deploying. The other thing would be to start a debug deploy task and check the partclone log (should be in /var/log/partclone.log on the client) after the error… Maybe the size is mentioned somewhere in the log.
-
I gave the virtual disk 200 GB, and it failed.
Not to be deterred, I gave it 400 GB – and it appears to be working!
It seems a tad peculiar that it failed with 200 GB available considering that the original partition is apparently 58 GB. Surely the remaining 142 GB should have been ample? But apparently it really needs lots of breathing room.
-
@wdmartin Is the virtual disk a dynamic one by any chance?
-
Yeah. Would that make a difference?
-
@wdmartin I’m not sure, I’ve never tried this, it should announce its proper size and thus work, but I guess it wasn’t doing so until you expanded it?
Is the original partition 58gb in size or is there 58gb of data?
Either way fixed size is better if disk intensive activity is going to take place anyway.
-
Well, it imaged, but the OS fails to boot. It may not like having been put on a VirtualBox when it was originally built against an Optiplex 990.
I got the 58 GB figure from the FOG imaging screen while it was building the second partition. The resulting VDI file is 58 GB, so I think that’s probably accurate.
At this point, the FOG part of it is working – it successfully deploys the image across the network to VirtualBox. It’s not FOG’s fault that the image doesn’t work on VirtualBox’s emulated hardware. I may give up and just do a manual install – I only need one VirtualBox installation. Perhaps I’ll pull an image from it for future use once I’ve got it built.
Thanks for the assistance! I greatly appreciate it when projects have helpful communities.
-
@wdmartin said:
It may not like having been put on a VirtualBox when it was originally built against an Optiplex 990.
For sure! Windows is very picky when it comes to IDE controller drivers… Not easy to get a system from bare metal to VM if you don’t adjust the drivers before capturing the image!
I got the 58 GB figure from the FOG imaging screen while it was building the second partition.
Ok, this meants the data within your second partition is 58 GB (28 GB compressed!) but does not tell you anything about the source partition/disk. It’s not an issue to put 58 GB to a 200 GB disk but a problem if the original file system used to reside on a larger disk - no matter how much free space there is!
