EBR Signature Invalid

[Sebastian Roth]

@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 dd from 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 testdisk you might want to check out.

[Wayne Workman]

@StevenT We use fixparts here all the time to upload MBR type images from computers that were previously GPT.

[StevenT]

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

[Wayne Workman]

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

[StevenT]

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

[StevenT]

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

[Wayne Workman]

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

[StevenT]

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

[zolo]

hi,
i have same error,
when i download error
i try :
wipe computer destination with fog = solved with one partition no allow
but i investigated my master, i have one partition in logical
i change this partition in primary partition,fix boot fix mbr
download fine : )

[Wayne Workman]

If you are using anything older than FOG 1.3.5 and have this error, please upgrade to 1.3.5 (or newer) or migrate to a new box that has 1.3.5 (or newer). For those that would like to migrate, this article is helpful: https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG

If you have this error on 1.3.5 or newer, please create a new thread in the forums. This thread is locked.