Deploy OK, but system won't boot (stays looping in Fog menu)

[Baite]

(continued from previous post)
[B]Experiment #3[/B] - Made in HP dc7900p computers (non-UEFI)

Restored an image I had in an external HDD (using TrueImage). This image was used in Fog 0.32 to this machines and I had them working perfectly.
Created an upload image task in Fog (image created as “Multiple Partition Image - Single Disk (not resizable)”).
Then, in the same computer, without changing anything, created a Deploy task in Fog and all went well. After image was deployed, computer shows default Fog menu, but after 3 seconds it starts loops in other menu (a different type of menu, with blue background and text options on the left) every 3 second (exactly as in Experiment #1).
This computer has [B]no UEFI[/B], so there must be something wrong with uploading this type of image.
This type of image backup/restore is [COLOR=#800000][B]not working[/B][/COLOR] on this type of system.
Configured machine to Download Debug and at the “command prompt” typed:
[INDENT=1]gdisk -l /dev/sda[/INDENT]
Got:
[INDENT=1]Partition table scan:[/INDENT]
[INDENT=2]MBR: protective[/INDENT]
[INDENT=2]BSD: not present[/INDENT]
[INDENT=2]APM: not present[/INDENT]
[INDENT=2]GPT: present[/INDENT]
[INDENT=1]Found valid GPT with protective MBR; using GPT.[/INDENT]
[INDENT=1]Disk /dev/sda: 312581808 sectors, 149.1 GiB[/INDENT]
INDENT=1[/INDENT]
[INDENT=1]Number Start (Sector) End (sector) Size Code Name[/INDENT]
[INDENT=1]1 2048 206847 200.0 GiB 0700 Microsoft basic data[/INDENT]
[INDENT=1]2 206848 312578047 149.0 GiB 0700 Microsoft basic data[/INDENT]
([I]see attached img7.jpg[/I])

[B]Experiment #4[/B] - Made in HP dc7900p computers (non-UEFI)

Restored the same image I had in an external HDD (using TrueImage) as in Experimt #3.
Created an upload image task in Fog (image created this time as “Single Disk (NTFS only, Resizable)”).
Then, in the same computer, without changing anything, created a Deploy task in Fog and all went well. After image was deployed, everything is [COLOR=#339966][B]working fine[/B][/COLOR].
Disk is exactly as the one in the image.
Again, after confirming everything is working, started a Deploy Debug task, and I got, after typying “gdisk -l /dev/sda/”:
[INDENT=1]Partition table scan:[/INDENT]
[INDENT=2]MBR: MBR only[/INDENT]
[INDENT=2]BSD: not present[/INDENT]
[INDENT=2]APM: not present[/INDENT]
[INDENT=2]GPT: not present[/INDENT]
[INDENT=1][/INDENT]
[INDENT=1]Found invalid GPT and valid MBR; converting MBR to GPT format.[/INDENT]
[INDENT=1][/INDENT]
([I]see attached image img5.jpg[/I])

[B]Experiment #5[/B] - Made in computers with ASUS B85M-G motherboard (UEFI in Legacy Mode)

Back to the first images I had in an external disk when I started this thread (restored with Acronis TrueImage), a few days ago.
Removed the extra partition and extended my Windows partition to use all space, so all I have is MSR, Windows and MBR partitions.
Created an upload task with a new image (“Single Disk (NTFS only, Resizable)”).
Then, in the same computer, without changing anything, created a Deploy task in Fog and all went well. After image was deployed, everything is [COLOR=#339966][B]working fine[/B][/COLOR].
The only difference from the original image that was uploaded is that I got a not used 9,31 GiB of disk space.
After testing that computer could not boot, made an Deploy Debug task and, at the prompt typed:
[INDENT=1]gdisk -l /dev/sda[/INDENT]
Got:
[INDENT=1]Partition table scan:[/INDENT]
[INDENT=2]MBR: MBR only[/INDENT]
[INDENT=2]BSD: not present[/INDENT]
[INDENT=2]APM: not present[/INDENT]
[INDENT=2]GPT: damaged[/INDENT]
[INDENT=1]Found valid MBR and corrupt GPT. Which do you want to use? (Using the GPT MAY permit recovery of GPT data.)[/INDENT]
[INDENT=1] 1 - MBR[/INDENT]
[INDENT=1] 2 - GPT[/INDENT]
[INDENT=1] 3 - Create blank GPT[/INDENT]
[INDENT=1] [/INDENT]
[INDENT=1]Your answer:[/INDENT]

([I]see attached image img6.jpg[/I])
Again, if I choose option 2 and then reboot computer, everything is still working fine.

CONCLUSION:

I think there’s something wrong with the way Fog is handling “Multiple Partition Image - Single Disk (not resizable)” images. I just hope all this tests can help you somehow.

[url=“/_imported_xf_attachments/0/925_img5.jpg?:”]img5.jpg[/url][url=“/_imported_xf_attachments/0/926_img6.jpg?:”]img6.jpg[/url][url=“/_imported_xf_attachments/0/927_img7.jpg?:”]img7.jpg[/url]

[Baite]

Tom:
Thank you for all your explanations through chat. Decided topost here in case someone else is interested.

In MPI (“Multiple Partition Image - Single Disk (not resizable)”) type, d1.mbr is 18k in size (meaning is a GPT partition information, as you said).
In SD (“Single Disk (NTFS only, Resizable)”), there are no d1.mbr files, only rec.img.000 (8.0 or 8.1M) and sys.img.000 (varies according to image) files.

You understood that I uploaded each type of computer image from the EXACTLY same computer and configuration, once as “Multiple Partition Image - Single Disk (not resizable)” and once as “Single Disk (NTFS only, Resizable)”. And when I deploy this images, MPI does not work and SD works.

My guess is that Fog does not read the disk information the same way in SD as it does in MPI and somehow it manages SD well but not MPI, regardless it is GPT or MB.

[Baite]

In Fog 0.32 I used MPI type of imaging to upload images and all went fine. I used that same configuration to upload an image to Fog 1.1.0.
In Fog 0.32 deployment worked fine… in Fog 1.1.0 does not work.
I repeat… it’s the same system, the same configuration, the same partitions.

[Baite]

Trying to upload the image gives some warnings:
(…)
[INDENT=1][B][I]* Preparing backup location…Done[/I][/B][/INDENT]
[INDENT=1][B][I]* Looking for Hard Disks…Done[/I][/B][/INDENT]
[INDENT=1][B][I]* Using Hard Disk: /dev/sda[/I][/B][/INDENT]
[INDENT=1][B][I]Caution: invalid main GPT header, but valid bckup; regenerating main header from backup![/I][/B][/INDENT]
[INDENT=1][B][I]Warning! Main partition table CRC mismatch! Loaded backup partition table instead of main partition table![/I][/B][/INDENT]
[INDENT=1][B][I]Warning! One or more CRC’s don’t match. You should repair the disk[/I][/B][/INDENT]

In [URL=‘http://msdn.microsoft.com/en-us/library/windows/hardware/dn640535(v=vs.85).aspx’]http://msdn.microsoft.com/en-us/library/windows/hardware/dn640535(v=vs.85).aspx[/URL], we can read:
"The protective MBR area exists on a GPT partition table for backward compatibility with disk management utilities that operate on MBR. The GPT header defines the range of logical block addresses that are usable by partition entries. The GPT header also defines its location on the disk, its GUID, and a 32-bit cyclic redundancy check (CRC32) checksum that is used to verify the integrity of the GPT header. Each entry in the GUID partition table begins with a partition type GUID. The 16-byte partition type GUID, which is similar to a System ID in the partition table of an MBR disk, identifies the type of data that the partition contains and identifies how the partition is used, for example, whether it is a basic disk or a dynamic disk. Note that each GUID partition entry has a backup copy. "

Can this be related to CRC testing not being properly executed due to this 32-bit / 16-bit ambiguity between GPT and MBR?

[Baite]

Other thing… updated to last SVN and now cannot upload image in this UEFI machine… stays showing errors (all the steps in the image files)

[url=“/_imported_xf_attachments/0/937_2014-06-09 16.27.44.jpg?:”]2014-06-09 16.27.44.jpg[/url][url=“/_imported_xf_attachments/0/938_2014-06-09 16.28.54.jpg?:”]2014-06-09 16.28.54.jpg[/url][url=“/_imported_xf_attachments/0/939_2014-06-09 16.29.11.jpg?:”]2014-06-09 16.29.11.jpg[/url][url=“/_imported_xf_attachments/0/940_2014-06-09 16.29.59.jpg?:”]2014-06-09 16.29.59.jpg[/url][url=“/_imported_xf_attachments/0/941_2014-06-09 16.30.16.jpg?:”]2014-06-09 16.30.16.jpg[/url][url=“/_imported_xf_attachments/0/942_2014-06-09 16.30.57.jpg?:”]2014-06-09 16.30.57.jpg[/url][url=“/_imported_xf_attachments/0/943_2014-06-09 16.31.19.jpg?:”]2014-06-09 16.31.19.jpg[/url]

[Baite]

(using latest undionly.kkpxe - with 2 ‘k’ as my undionly.kpxe file since the original does not work in this system - keeps restarting machine)