Problem of deployment of an old image

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