GPT images fail deployment
-
Hey
We use FOG for almost all our bigger image system deployments. If everything is straight-forward, then there are no problems and all works flawless. But what I noticed is that FOG doesn’t like new hard drives that have no partitions on or hard drives that have been wiped clean.
I uploaded an image with FOG from a PC. This PC is running Windows 7 Pro 64 bit with a 500GB HDD. It has 4 partitions = EFI, MSR, Primary, Primary. The first partition os 100 MB, the second 128 MB, the third 451GB add the fourth 13GB. It had been “downgraded” from Windows 8, so the disk layout is GPT. The upload completed successfully and has valid file sizes on the upload location. It stores 4 images files.
When I deploy this image on a exact same model machine with the same original hard drive partition and disk layout, it deploys flawlessly.
Issues
1.) When I deploy this image on a exact same model machine, with a new hard drive (no partitions) it doesn’t even start. When deploying, it says “task completed” and then shuts down or restarts (whichever I chose as a task completion option)
2.) I need to manually create the partitions on the new hard drive, and make the hard drive layout GPT. The partitions need to be the exact same sizes as the original. This starts the deployment, deploys onto partition 1,2 and 4 BUT it SKIPS the 2nd partition , the 451 GB one (which I actually need). I use diskpart for doing this.
I was in fact unable to deploy to ANY system with a unformatted, unpartitioned new hard drive running GPT. The thing is, I would need this to work as sometimes I replace the hard drive of a machine, which crashed and then need to restore it to factory default and thus I want to use the FOG images we created.
So what must I do, so that the deployment on new clean hard drives works just as well ?
The only workaround I have is to use Ghost or Acronis to make an image from a new original machine and deploy it onto a new hard drive and install that drive into the required machine.
Additionally, this all is no problem when working with a MBR image that was uploaded.
-
I’m going to ask, are you using FOG 0.32 or FOG 0.33b?
I think this problem is still existing in FOG 0.33b as I haven’t added anything for gparted, though I imagine this is relatively easy to do. I’m just one guy though, so making all these edits and testing is a bit rough. I’ve basically been trying to get things back to a sort of operational state from the Perspective of the init.gz, kernel, and WEB GUI and have edited the fog scripts pretty heavily. However, theh things I do notice is that FOG doesn’t like anything more than three partitions. The problem, I imagine, is that the images are saved from partition to partition rather than disk to disk.
I don’t know if disk to disk is even possible so I’ll try playing with that today. If it goes disk to disk, I’d imagine imaging would be a little better off as we don’t need to loop through each of the files in a specified order to get things imaged. We only need the one file, but what implications this has on varying disk sizes is questionable.
Questions I ask myself are:
Would this method copy the data appropriately?
Does this mean your drives are resized according to the drive parameters?
Will this work for GPT/EFI/MBR?
Does partclone do disk copies in this manner with bit to bit, or block to block?While these are just a couple of questions, I think these are the biggest of them all as we would need to know the implications of this.
-
This post is deleted! -
It’s running on 0.32
Will test with the RAW image upload. Since time will be a problem, I cannot use this option on 200 or 300 units - as this would delay the delivery date exponentially.
EDIT
I would need to know how I can update it with the update I downloaded :
1.) Update without overwriting the current settings, plugin configurations…
2.) If 1 fails then details on what files I should backup or where and what lines I must copy so I can restore the current configs to the 0.33b version
3.) There is no internet connection on the deployment server, so I can’t do it online…
EDIT 2
I ran the install file and it actually ran through fine… but nothing changed. The version in FOG still says it’s 0.32 …
-
[quote=“Tom Elliott, post: 21323, member: 7271”]I’m going to ask, are you using FOG 0.32 or FOG 0.33b?
I think this problem is still existing in FOG 0.33b as I haven’t added anything for gparted, though I imagine this is relatively easy to do. I’m just one guy though, so making all these edits and testing is a bit rough. I’ve basically been trying to get things back to a sort of operational state from the Perspective of the init.gz, kernel, and WEB GUI and have edited the fog scripts pretty heavily. However, theh things I do notice is that FOG doesn’t like anything more than three partitions. The problem, I imagine, is that the images are saved from partition to partition rather than disk to disk.
I don’t know if disk to disk is even possible so I’ll try playing with that today. If it goes disk to disk, I’d imagine imaging would be a little better off as we don’t need to loop through each of the files in a specified order to get things imaged. We only need the one file, but what implications this has on varying disk sizes is questionable.
Questions I ask myself are:
Would this method copy the data appropriately?
Does this mean your drives are resized according to the drive parameters?
Will this work for GPT/EFI/MBR?
Does partclone do disk copies in this manner with bit to bit, or block to block?While these are just a couple of questions, I think these are the biggest of them all as we would need to know the implications of this.[/quote]
In this thread you said that FOG doesn’t like more than 3 partitions, when I use the Lenovo disk to install the OS, there are 6 partitions.
Is this why my images fail, and is this why the RAW image format works for me?
-
Most likely.
Besides that, MBR ONLY ever allows 4 maximum partitions. That’s it. No more. You can “fake” more partitions by using Extended, but primary can only be 4.
-
So, it’s not the GPT or MBR, but FOG has a limitation, because of how Lenovo loads their machines.
I guess I have to live with the RAW image then, correct.
I have to say, it works very well, but it’s very slow, thank you for your thoughts.
-
[quote=“Thomas Rucker, post: 40196, member: 1970”]So, it’s not the GPT or MBR, but FOG has a limitation, because of how Lenovo loads their machines.
I guess I have to live with the RAW image then, correct.
I have to say, it works very well, but it’s very slow, thank you for your thoughts.[/quote]
THIS IS NOT A LIMITATION OF FOG, this is a LIMITATION of HDD and the format the partitions are created. MBR can ONLY have 4 primary partitions.
-
[quote=“Thomas Rucker, post: 40196, member: 1970”]So, it’s not the GPT or MBR, but FOG has a limitation, because of how Lenovo loads their machines.
I guess I have to live with the RAW image then, correct.
I have to say, it works very well, but it’s very slow, thank you for your thoughts.[/quote]
If you have 6 primary partitions it’s GPT.
[url]http://en.wikipedia.org/wiki/GUID_Partition_Table[/url]
