EBR Signature Invalid
We are having a problem sending an image to workstations. We are able the upload the image from the master to the fog server fine. When we try to download the image to additional clients no data appears to be send. The process completes in less than 5 seconds. The following error is displayed on the client during the download process:
Erasing current MBR/GPT Tables … EBR signature for logical partition invalid: read 0xB5F8, but should be 0xAA55
Error reading logical partitions! List may be truncated!
We are running Fog 1.2.0 on Ubuntu 14.04.3. I have found some other threads on a similar topic but none seem to be resolved.
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.
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 @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.
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 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 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 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 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 We use fixparts here all the time to upload MBR type images from computers that were previously GPT.
@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.
@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.
@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?
@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 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 correct, at least in theory. The imaging, however is on the upload, as the upload is what’s broken at this point.
@Tom-Elliott So I just start the fixparts utility, ‘w’ to save (without changing anything else) and then try to image again?
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 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.
@StevenT I believe it’d just be:
You need the full path to the device to work…