Deploy OK, but system won't boot (stays looping in Fog menu)
-
Tom:
Thank you for your patiente…
-
Just started a new image… made sure every boot option in BIOS were set to Compatible Mode.
In WinPE, used DISKPART to clean disk entirely.
Started Windows Setup from USB flash drive.
When I got to
Started setup and created partition for OS. Finished setup and went to Disk Management - Disk 0 - Properties says it’s MBR
Started Image-Download Debug and run #gdisk -l /dev/sda
It says:
Partition table scan:
[INDENT=1]MBR: MBR only[/INDENT]
[INDENT=1]BSD: not present[/INDENT]
[INDENT=1]APM: not present[/INDENT]
[INDENT=1]GPT: present[/INDENT]Founf valid MBR and GPT. Which do you want to use?
1 - MBR
2- GPT
3 -Create blank GPTYour answer:_
So I guess somethings happen when i upload my image. Seems like Fog is converting MBR to Protective MBR the partition where Windows 7 is installed. Maybe it is getting confused about Microsoft Reserved Partition is in GPT format.
What do you think?
-
If everything is Legacy based, the FOG Installer will install it as MBR based image. If the system is in and type of UEFI mode, it will automatically default to GPT.
My guess is the boards not properly disabling UEFI.
-
To bypass this… do you think it is possible to install everything until image is ready, then use older computer to upload image (by older I mean withouth EFI)?
I mean, install HDD from my new system in a Lagacy computer…
-
That wouldn’t work because the drive partitioning would already be setup in GPT.
-
Another message that I’m getting might be important.
I’ve created a simple image, made sure Windows 7 was on a MBR partition.
When I made an Upload with Debug, when I execute #gdisk -l /dev/sda, i receive also this information:
Found invalid GPT and valid MBR; converting MBR to GPT format.
I guess it’s here the problem… the drive isn’t in GPT before uploading… it’s at that moment that it is converted to GPT.
-
DISKPART erases partitions, but i don’t think it modifies the boot sector. you didn’t wipe the old gpt data off the drive. you can use gdisk to wipe the boot sector
-
(after reading all previous posts and the following thread: [url]http://fogproject.org/forum/threads/clonezilla-works-fog-does-not-both-use-partclone-0-2-69-help-please.10699/[/url])
I have 35 computers with ASUS B85M-G motherboard. They all have an Intel 4770 processor and 8 GB RAM.
This board is UEFI, but as a CSM (Compatibility Support Module) with is enabled and all configurations are set to “Legacy OPROM only”. This options I set are:
[INDENT=1]Boot Device Control[/INDENT]
[INDENT=1]Boot from Network Devices[/INDENT]
[INDENT=1]Boot from Storage Devices[/INDENT]
[INDENT=1]Boot from PCI-E/PCI Expansion Devices[/INDENT]
Secure boot is set as:
[INDENT=1]OS Type = “Other OS” (the other option was “Windows UEFI mode”).[/INDENT]My server is a x64 Intel system, with CentOS 6.5 (updated). Had previously Fog 0.32 working here. Reinstalled OS and installed non-official version 1.1.0 of Fog (through SVN). Installed Fog and everything is working fine (hostname changer, add to AD tested so far), except for the deployment of images.
Here are a few experiments I made to help debug this problem:
[B]Experiment #1A[/B] - Made in computers with ASUS B85M-G motherboard (UEFI in Legacy Mode)
Made a “Download Debug” job in Fog and, at prompt, typed:
[INDENT=1]# sgdisk -Z /dev/sda[/INDENT]
Rebooted and started Windows 7 Enterprise x64 installation. Accepted License Agreement and chose Custom Installation (Advanced).
Created a 200GiB partition and Windows automatically created also an MSR partition (100MB). Created another partition with the remaining space. Chose the 200GiB partition to install Windows into and pressed Next. Windows copied files, extracted files and so on.
After reboot, uploaded image immediatly with an Upload 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 ([I]see attached img2.jpg[/I])
Went to BIOS and deactivated boot from NIC. Turned computer on, but doesn’t boot… returns to BIOS after a few seconds, never booting
This type of image upload/deploy 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: 1953525168 sectors, 931.5 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 1953519615 931.4 GiB 0700 Microsoft basic data[/INDENT]
([I]see attached img1.jpg[/I])[B]Experiment #2[/B] - Made in computers with ASUS B85M-G motherboard (UEFI in Legacy Mode)
Made a “Download Debug” job in Fog and, at prompt, typed:
[INDENT=1]# sgdisk -Z /dev/sda[/INDENT]
Rebooted and started Windows 7 Enterprise x64 installation. Accepted License Agreement and chose Custom Installation (Advanced).
Created a 200GiB partition and Windows automatically created also an MSR partition (100MB). Created another partition with the remaining space. Chose the 200GiB partition to install Windows into and pressed Next. Windows copied files, extracted files and so on.
After reboot, uploaded image immediately with an Upload task in Fog (image created this time as “Single Disk (NTFS only, Resizable)”).
Gave me an error saying this type of image only allows for a maximum of 3 partitions.
Went to Windows and removed the partition with the remaining space and expanded the 200 GiB partition to use all free space (then, I got the MSR partition and a second partition with the remaining space where Windows was installed; the 3rd partition is MBR).
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.
Configured machine to Download Debug (to compare with previous experiment results) and at the “command 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 img3.jpg[/I])
If I answer 2, I get what’s in [I]attached img4.jpg[/I].
Then reboot computer and everything is still working fine.[B]Experiment #1B[/B] - Made in computers with ASUS B85M-G motherboard (UEFI in Legacy Mode)
[B]Note:[/B] After running Experiment #2 with only 3 partitions, repeated Experiment #1 with the same 3 partitions, but the result is the same: [B][COLOR=#800000]not working[/COLOR][/B].
[url=“/_imported_xf_attachments/0/916_img1.jpg?:”]img1.jpg[/url][url=“/_imported_xf_attachments/0/917_img2.jpg?:”]img2.jpg[/url][url=“/_imported_xf_attachments/0/918_img3.jpg?:”]img3.jpg[/url][url=“/_imported_xf_attachments/0/919_img4.jpg?:”]img4.jpg[/url]
-
(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]
-
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.
-
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. -
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?
-
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]
-
(using latest undionly.kkpxe - with 2 ‘k’ as my undionly.kpxe file since the original does not work in this system - keeps restarting machine)