EBR Signature Invalid
-
@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?
-
@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.
-
@Tom-Elliott is it just ‘fixparts sda’ ?
-
@StevenT I believe it’d just be:
fixparts /dev/sdaYou need the full path to the device to work…
-
@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.
-
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.
-
@Tom-Elliott So I just start the fixparts utility, ‘w’ to save (without changing anything else) and then try to image again?
-
@StevenT correct, at least in theory. The imaging, however is on the upload, as the upload is what’s broken at this point.
-
@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?
-
@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.
-
@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? -
@Tom-Elliott In addition I would be pretty surprised if the partitions were the issue. We did not reinstall the OS. We only configured it as needed from the factory. Its a brand new pc.
-
@StevenT If this really is your only working copy then I’d take a new disk drive, put it into that PC and take a sector by sector copy (e.g. using
ddfrom a linux live DVD or any other tool that you are familiar with) before you proceed.Then I’d use microsoft’s diskpart util and linux’s fdisk/sfdisk/gdisk to examine the partition table. See if they show any errors. As well there is a great linux tool called
testdiskyou might want to check out. -
@StevenT We use fixparts here all the time to upload MBR type images from computers that were previously GPT.
-
@Wayne-Workman So running fixparts will NOT wipe the drive data? When would a drive be “previously GPT”? When it used to be Windows 8 and reinstalled as 7, ect?
-
@StevenT Usually, yes.
Typically people using FOG 1.2.0 use legacy/BIOS mode because DHCP isn’t set up to allow co-existence for UEFI and BIOS network booting, so they configure DHCP for BIOS, and set computers to BIOS because that’s what works. When they do that, they unknowingly go from a GPT disk layout to MBR, because that’s what the Windows installation detects that the firmware is operating in BIOS mode, so Windows sets up the disk as MBR during installation, but the problem is that Windows does not do this correctly and pieces of GPT are left over on the disk.
There are other cases, too.
And I’ve never had fixparts destroy a disk. But you know what? What if it does? You’re out a half day and you rebuild the image - easy. It wouldn’t even be a concern if it were me.
-
@Wayne-Workman So this is a brand new OS straight from the factory. No reinstall. No changes made in the BIOS
and never touched by FOG until the backup. Why would it have pieces of GTP ‘left’ on the disk? -
@Wayne-Workman We are going to start over with a new machine. We are going to keep the original PC as reference for configuring the second. Before we start I’m going to low level format the beast and then try to image it as soon as the OS is installed to make sure it works. Not sure why it would have a problem from the factory, but hopefully that will fix it.
-
@StevenT said:
Not sure why it would have a problem from the factory
Generally, FOG 1.2.0 doesn’t work well with manufacturer images. It’s because of customized MBRs that are larger than normal. Generally, 1.2.0 will work on anything you built from scratch - that uses regular MBRs.
There have been a lot of improvements on this in FOG Trunk, by the way. A lot of improvements.
-
@Wayne-Workman @Tom-Elliott Interesting development. After wiping the drive everything appears to be working. In fact, I am even able to restore the original image that wasn’t working before. I believe the issue was not with the source master PC and the partitions on it, but I think FOG was having trouble trying to remove the partitions from the destination PC. I suspect the OEM partition #1.
