Windows 8 with FOG 0.33b
-
Hi all,
I’m having quite a strange problem with deploying Windows 8 on some DELL 9020 AIO pc’s. I made the image without any problems but when i try to download the image to a PC everything goes really fast even though the last partition (sda4) has 11 GB.
I searched the forum but i don’t seem to find anyone else with this problem.
I think that partclone is not writing the image to the disk but the partclone log is empty.
I did find this in the ntfs-mount-output log:NTFS signature is missing.
Failed to mount /dev/sda4: Invalid argument.
The device /dev/sda4 doesn;t seem to have a valid NTFS
Maybe the wrong device is used? Or the whole disk instead of a partition.Image type: Multiple partitions - Single disk
I use FOG 0.33b from the SVN on a Debian 7 server. I will attach a screenshot with the problem.Thank you for your time.
[url=“/_imported_xf_attachments/0/724_error.JPG?:”]error.JPG[/url]
-
My guess is you’ve attempted to make an image of a Windows 8 system, but didn’t properly clean the drive first?
FOG 1.0.0 does have checking to use GPT or MBR style backups and restores for the Partitioning table, however it’s very basic checking at the best. I don’t know of any sure-fire methods to check what type of drive is “SUPPOSED” to be there. The checking on upload basically goes like this.
During Upload:
Does the table recognize GPT information? gdisk -l /dev/sda is the command run to check if the drive is using MBR or GPT format. If the GPT: part comes back as “not present” it creates an MBR backup using dd as the backup medium. If it returns anything else back it assumes it is GPT and creates a backup of the partitioning table with sgdisk.During Download:
Does the d1.mbr file size equal 32256 bytes or 512 bytes? If so restore using dd as it’s most likely an MBR backup file it’s dealing with. If it’s any other size, it uses sgdisk to restore the partitioning table.What does this mean?
It means that if you’re trying to create an MBR style image but have not properly wiped the partitioning table or the drive properly before creating your image, it’s most likely going to have GPT data still found on it. This means that FOG 1.0.0 will assume it is in GPT format even if this is not the intention of the creator of the image.As I’ve stated multiple times now, I can only make the most basic of assumptions, but I have no way of knowing what your intentions of the uploaded image are actually going to be. Do you mean you want it to be MBR, or do you mean you want it to be GPT is easy enough to ask here on the forums, but trying to make those guesses programmatically is nearly impossible.
-
Hi Tom,
Thank you very much for your answer. I will try to answer your questions. I did not have to much time to debug this situation.
“Does the table recognize GPT information?”
Yes.
“Does the d1.mbr file size equal 32256 bytes or 512 bytes?”
The size of d1.mbr is 17920.
I restored it with sgdisk but something strange happened. Just to be sure that everything is ok, I did a sgdisk -Z /dev/sda first to delete the GPT and MBR tables. Then I did a restore using sgdisk -l /images/d1.mbr /dev/sda. When I did a gdisk -l /dev/sda it showed no partitions. A read on a forum that before you restore you have to issue sgdisk -G /dev/sda. Apparently this command “Randomizes the disk’s GUID and all partitions’ unique GUIDs (but not their partition type code GUIDs). This function may be used after cloning a disk in order to render all GUIDs once again unique”. After I issued this command and did a restore again, all partitions were created on /dev/sda.When I have a little more time I will continue debugging and post the results.
Thank you for your time.
Bogdan
