EBR Signature Invalid

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

[StevenT]

@Tom-Elliott Not familiar with the utility (if you hadn’t guessed already). This should not lose any data, correct? Its not recreating the partitions, right?

[Tom Elliott]

@StevenT It is recreating the partitions, but doing so as it should’ve been done before. meaning, it’s currently broken. Fixparts will fix it if it really is broken. Otherwise I really don’t know.

[StevenT]

@Tom-Elliott Alright we’re stuck here. This is a master PC we have configured as needed. It is the only working copy we know of since we cannot restore the data to another workstation. I’m concerned about running the partfix because I dont know if it will wipe the drive or not and I’m not sure if that is what is causing the problem or not.
Is there anything else before we go this route? Is there a chance that partimage would work better than partclone in this instance?