EBR Signature Invalid

[StevenT]

@Wayne-Workman We’ll try that next to make sure. It *appears the master disk is working ok. It boots, runs the OS, ect fine. We have also tried to deploy the image taken from the master to 3 different XE2 PCs with no luck. I wouldn’t think its a hard drive issue, but we will make sure.

Also I have been able to image and deploy other PCs on this FOG server. I’ll admit the image was taken from and restored to the exact same PC (backup/restore), but that at least proves the server is ABLE to take and deploy an image.

[Wayne Workman]

@StevenT But have you successfully taken and deployed an image since this issue?

[StevenT]

@Wayne-Workman I think I’ve narrowed it down to either the source hard drive. Its either bad (which i doubt), there is a problem with the partitions on the source hard drive or FOG is unable to support the source hard drive or partition setup.

-I have tried to capture deploy using the native XE2 hardware platform and failed.
-I have tried to use a current patch version of FOG to capture / deploy using the XE2 hardware and failed.
-I have tried to move the hard drive to an older hardware platform that worked previously and failed.
-To make sure FOG still worked at all I tried to backup and restore and completely different 7020 and it worked fine.

There is sometime about this drive or partition setup causing the problem.

[george1421]

@StevenT Not to add confusion here. But do you have a single image you are deploying to the XE2 and the other Dell computers? The question is, is the issue specific to deploying to the XE2 from a common image or if you capture the image from an XE2 does it deploy to a standard dell? Its not clear how you deploy images.

[Wayne Workman]

@StevenT If you can do a debug deploy/capture to that problematic hardware and when you finally get to a shell, run the command lsblk and see what it says. Take a picture and post here.

[george1421]

@Wayne-Workman said:

@StevenT If you can do a debug deploy/capture to that problematic hardware and when you finally get to a shell, run the command lsblk and see what it says. Take a picture and post here.

I think that is the next step is getting to a command line and running the lsblk command that way we can see what the FOS (fog operating system) is actually seeing for a disk structure. If you can’t get it into debug mode we may have you setup a bootable usb. But lets try to do it through the fog server first.

[StevenT]

@Wayne-Workman Sorry about the delay. I’m getting ready to do the debug process now. This is the first I time running the debug. I’m concerned about the way the description is worded on the web page and I do not want to overwrite my master hard drive by mistake. For the master PC I want to select the 'Upload Debug", correct?

[Wayne Workman]

@StevenT Yes. in FOG Trunk it’s just a checkbox on the upload confirmation page. In 1.2.0 you have to go into advanced tasks and find the debug upload task.

We won’t be doing anything to change the disk at this point. We’re just trying to gather information that will hopefully lead us to the next step.

[StevenT]

@Wayne-Workman Here is the debug information you requested and diskpart info from the Windows as well. 

[StevenT]

@Wayne-Workman Not sure if that worked. If not I have the images here as well:

http://imgur.com/3hAvede
http://imgur.com/sM4V4Fg

[StevenT]

@Wayne-Workman Were you able to review the images? Did anything stand out?
Thanks.

[Tom Elliott]

@StevenT I see what the problem is. You have a lot of partitions on that disk, which would indicate the layout of the partition table is setup for GPT. However, windows has made the disk “MBR”. The EBR file is what tells the FOG system to use logical/extended partitions. Because the disk is still containing (I think) GPT structures, but reporting as MBR layout, the EBR is indeed invalid.

[StevenT]

@Tom-Elliott This is a pretty standard setup for us. There is OEM and recovery partition and then two windows drive letters. Is there a way around the issue?

[Tom Elliott]

@StevenT I don’t know what the issue is, so first we need to figure out where the problem lies.

I’d maybe recommend booting the system to upload-debug an run fixparts. This should see if the disk is laid out properly if it is supposed to be MBR layout. Then, you will have to reupload the system. This should fix the issue, though I can’t say for certain that it WILL.

[StevenT]

@Tom-Elliott is it just ‘fixparts sda’ ?

[Tom Elliott]

@StevenT I believe it’d just be:
fixparts /dev/sda

You need the full path to the device to work…

[StevenT]

@Tom-Elliott Wasn’t sure what you wanted me to do once I started the fixparts app, but I check in Windows and it does not list the disk as GPT.

[Tom Elliott]

That’s part of the problem. Windows won’t recognize the GPT structures on the disk, nor will it fully remove them when converting them. Diskpart, while useful, is not useful for showing the system. Fixparts will fix the gpt structures and maintain the disk as MBR.

[StevenT]

@Tom-Elliott So I just start the fixparts utility, ‘w’ to save (without changing anything else) and then try to image again?

[Tom Elliott]

@StevenT correct, at least in theory. The imaging, however is on the upload, as the upload is what’s broken at this point.