Problem of deployment of an old image

[nicolas.illi]

Server

• FOG Version: 1.4.4
• OS: CentOS 7
• Kernel version : 4.13.4

Client

• Computer : Lenovo T450s
• OS: Windows 8.1

Description :

Hello,

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.

Cordially,

[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.

[Sebastian Roth]

@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.mbr or gdisk -l d1.mbr though 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: isdebug=yes ismajordebug=1

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.

[nicolas.illi]

@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]

@Sebastian-Roth Thank you you for your help !

Here the result of the order gdisk -l :

[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

[Sebastian Roth]

@nicolas-illi Just edit the host’s settings in the web UI and simply add to the field kernel parameters what I posted last.

[nicolas.illi]

@Sebastian-Roth You will find below the screenshot of the deployment with the Kernel parameters " isdebug=yes ismajordebug=1"

Thanks for your help !

[Sebastian Roth]

@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/sda and gdisk -l /dev/sda and post pictures of it all.

[nicolas.illi]

@sebastian-roth Hello, here the link for the download of the file d1.mbr : link there

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 :

fdisk -l :

gdisk -l :

Many thanks,

[Sebastian Roth]

@nicolas-illi Alright. In your case the so called “protective MBR” was missing in the d1.mbr file. 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.

[nicolas.illi]

@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.

[Sebastian Roth]

@nicolas-illi said in Problem of deployment of an old image:

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 fog command 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/sda and 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 w and hit ENTER, then y and 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.mbr file 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 fog again and it should deploy without an issue.

[nicolas.illi]

@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 !!