EBR Signature Invalid

[george1421]

@Tom-Elliott Unless I missed something that is exactly what the OP said:

@george1421 I finished setting up a completely new install of Ubuntu / Fog 1.2.0. I used SVN to upgrade to 6175. I kept the empty database and just registered the two hosts to test with.

I must have not been clear. First attempt was to “try” the new kernels and init. That failed so the OP spun up a new server with similar results. I have personally not had any experice with this new model Dell “Optiplex XE2” the release date is mid 2013 so it should be similar to the 7020/9020 but the chip set is listed as “Intel 8 Series Express” unless this is a type-o it is inconsistent with the other hardware of that era.

[StevenT]

@Tom-Elliott To reiterate what @george1421 said our final attempt was with a brand new OS / FOG installation upgraded to trunk via SVN. I registered only the master / slave hosts, uploaded the image and then tried to deploy it. Even with the brand new upgraded install we were getting an error trying to deploy. That is where we left off.

[Wayne Workman]

Can we take a step back, and try to upload from other computers just to see if it works? Doesn’t need to be anything special, doesn’t matter what’s on the drive. We just need to test uploading to verify if the FOG server works for other hardware.

[StevenT]

@Wayne-Workman Good idea. We are in the process now. The deploy just failed so we are trying to use alternative hardware for the entire process now - upload image from master HD in an alternative PC and deploy the image to slave HD in an alternative PC. The alternative PC we are using we know worked in the past.

[Wayne Workman]

@StevenT said:

upload image from master HD in an alternative PC and deploy the image to slave HD in an alternative PC

I’d disagree with that. It’s possible that the HDD itself is the issue.

I’d recommend just grabbing any other working computer and just uploading.

[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’ ?