Problem of deployment of an old image
- FOG Version: 1.4.4
- OS: CentOS 7
- Kernel version : 4.13.4
- Computer : Lenovo T450s
- OS: Windows 8.1
I have just set up a new FOG server 1.4.4 on CentOS 7.
The creation of new images, the capture and the deployment of a new computer occur well.
I had before this new server, a FOG server 1.2.0 on which was various images.
I recovered these old images and I copied them from the new server. (In /images).
I imported my old database SQL on the new server and the old images are quite present on the Web interface and the listing of the old computers too.
However, the deployment of the old images does not function
Here the error message :
Error trying to restore GPT partition tables (restorePartitionTablesAndBootLoaders) Args Passed : /dev/sda 1 /images/Lenovo_T450s_W81 7 all CMD Tried : sgdisk -gl /images/Lenovo_T450s_W81/d1.mbr /dev/sda Exit returned code : 2
Here contents of the folder where the image is:
[root@srv-fog2 /]# ls -lah /images/Lenovo_T450s_W81/ total 22G drwxrwxrwx. 2 fog root 116 Oct 23 09:46 . drwxrwxrwx. 17 fog root 4.0K Oct 24 13:02 .. -rwxrwxrwx. 1 fog root 18K Oct 23 09:34 d1.mbr -rwxrwxrwx. 1 fog root 195K Oct 23 09:34 d1p1.img -rwxrwxrwx. 1 fog root 25M Oct 23 09:34 d1p2.img -rwxrwxrwx. 1 fog root 1.8M Oct 23 09:34 d1p3.img -rwxrwxrwx. 1 fog root 13G Oct 23 09:40 d1p4.img -rwxrwxrwx. 1 fog root 9.7G Oct 23 09:46 d1p5.img -rwxrwxrwx. 1 fog root 100M Oct 23 09:46 d1p6.img [root@srv-fog2 /]#
Here first partition d1.mdr :
[root@srv-fog2 Lenovo_T450s_W81]# file d1.mbr d1.mbr: data [root@srv-fog2 Lenovo_T450s_W81]# fdisk -l d1.mbr Disk d1.mbr: 0 MB, 17920 bytes, 35 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes [root@srv-fog2 Lenovo_T450s_W81]#
I tried to deploy another old image, but the problem is the same one.
I sought a solution on the forum and on Internet before carrying out this post but unfortunately I did not succeed in correcting my problem.
Could you help me please.
Thank you by advance for your assistance.
@sebastian-roth Thank you very much! You are brilliant!
You saved to me an invaluable time!
I carried out the test of your procedure and all functions perfectly.
Thank you still for your assistance, and thank you for this software!
I love FOG ! It is the best !!
I have 11 more images which I had created with FOG 1.2.0.
Ahh, I kind of figured that would be the case. But before we get to that let me say that I insist on you taking fresh images after having fixed and deployed those to your machines. Keep a backup copy of the old image files just in case (somewhere on a backup disk) and upload/capture fresh new images using the new FOG server!
Ok, so what do you need to do to fix those MBR files. Schedule a debug deploy task, boot up the client and start the process running the
fogcommand when you get to the shell. It will fail and drop you back to the shell. But it also deployed the MBR/partition layout half way. Back to the shell run
gdisk /dev/sdaand it will tell you about a corrupt GPT and so on but it should also have the correct partition layout and all that. Simply type
wand hit ENTER, then
yand ENTER again to write changes and correct the whole layout. Now you have a proper MBR/partition layout on that client’s disk which you can check and then get a dump like that:
gdisk -l /dev/sda ... ... sgdisk -b /root/d1.mbr /dev/sda
Now you only need to get that back to your server’s image directory. The easy way is to plug in a FAT32 formated USB key to your client and run:
mkdir -p /media/usb mount /dev/sdb1 /media/usb mv /root/d1.mbr /media/usb umount /media/usb
Unplug the USB key, go to your FOG server and save that
d1.mbrfile into the
/images/...directory of that image you just used on that client.
Now back to that client - no need to reboot or anything - just run
fogagain and it should deploy without an issue.
@sebastian-roth Hello, thank you very much, the deployment it passed well!
Can you give me the procedure allowing of patcher the other old file d1.mdr?
I have 11 more images which I had created with FOG 1.2.0.
@nicolas-illi Alright. In your case the so called “protective MBR” was missing in the
d1.mbrfile. I am not exactly sure but I think this came from FOG 1.2.0 having an older version of the gdisk/sgdisk tools which behaved differently.
Anyhow, here is a patched version of your d1.mbr file. Make a backup copy of the original file, download the new one and put into your image directory on the FOG server. Then schedule another deploy task, boot up that client and watch it do its job. Should be all working.
For the screenshot of the computers, I cannot provide you only the pictures of the destination host. I do not have any more the master machine degree.
There, the pictures of the destination host :
@nicolas-illi Ok, I need to have a look at the d1.mbr myself. Please upload that small file to dropbox or google drive and post a link here.
Comparing the “save/restore MBR/partition layout” code in 1.2.0 and 1.4.4 I can’t actually see why there should be a problem (reference for myself: (1.2.0 up/sgdisk -b, 1.2.0 down/sgdisk -gel - 1.4.4 up, 1.4.4 down) . So I need to check the d1.mbr to get an idea.
As well I need disk information of both machines, the master machine you uploaded this image from and the destination host you are trying to deploy this to. For both schedule a debug upload/download (either will do) task and when you get to the shell run
fdisk -l /dev/sdaand
gdisk -l /dev/sdaand post pictures of it all.
@Sebastian-Roth You will find below the screenshot of the deployment with the Kernel parameters “
Thanks for your help !
@nicolas-illi Just edit the host’s settings in the web UI and simply add to the field kernel parameters what I posted last.
@Sebastian-Roth Thank you you for your help !
Here the result of the order
[root@srv-fog2 Lenovo_T450s_W81]# gdisk -l d1.mbr GPT fdisk (gdisk) version 0.8.6 Warning! Disk size is smaller than the main header indicates! Loading secondary header from the last sector of the disk! You should use 'v' to verify disk integrity, and perhaps options on the experts' menu to repair the disk. Caution: invalid backup GPT header, but valid main header; regenerating backup header from main header. Caution! After loading partitions, the CRC doesn't check out! Warning! Error 25 reading partition table for CRC check! Warning! One or more CRCs don't match. You should repair the disk! Partition table scan: MBR: not present BSD: not present APM: not present GPT: damaged Found invalid MBR and corrupt GPT. What do you want to do? (Using the GPT MAY permit recovery of GPT data.) 1 - Use current GPT 2 - Create blank GPT Your answer:
Can you tell me how to set up the parameters of the kernel for this host ?
Thanks a lot
@Wayne-Workman Thank you for your reactivity and your answer.
I had thought of doing that, but I wanted to know if there were not other solutions or if it were necessary to configure various parameters for the old images.
@nicolas-illi As we see from the output FOG detects this to be a GPT partition layout. Possibly CentOS’ fdisk is not able to read that from the MBR file. You might try
sgdisk -p p1.mbror
gdisk -l d1.mbrthough I am not sure if those two can handle reading and showing the partition layout from a file. Give it a try. As well you could upload that d1.mbr to you dropbox and post a link here. I can have a look.
Other than that you might add the following to the hosts’ settings as kernel parameters:
Then schedule a new deploy task for that particular host and when you hit the error take a picture and post here in the forums.
Wayne Workman last edited by Wayne Workman
@nicolas-illi While the developers and community try hard to make FOG backwards compatible with older images, those capabilities aren’t perfect… It may be the most simple and least effort path to just setup a 1.2 server and deploy the image with it, then capture using 1.4.4.