Dell latitdue imageing problem

[george1421]

@JTech Ok to ensure #3 works we need to verify the version number. Because the stable 1.2.0 does not support uefi images very well. But the SVN trunk (pre 1.3.0) has address uefi deployment issues, plus the pxe boot kernels may not support the 6540 because it is so new. But if you don’t know what SVN/Git is, I’ll assume you are running on the 1.2.0 stable release.

On the login page for FOG, if you look in the upper right corner of the browser page. There should be the word FOG with a cloud picture behind it. To the right of the word FOG there are 4 numbers. What is the numbers.

[Sebastian Roth]

@JTech said:

However when I go to down load this image to a dell latitude E6540 with AMD Graphics card It zeros out the image on the client pc under the fog management console.

Could you please let us know what exactly that means? I have no idea. Do you see any error messages? What exactly goes wrong and when?

[KellyM]

Sebastian,
I am experiencing the exact same thing as JTech.
To answer your question, here is a screenshot of my image that had the same issue.
When I first loaded the image, the “Size on Client” was accurate. After attempting to download my image onto a new hard drive as a test, it then changes to what you see, after failing to actually reimage the new hard drive.

For Reference, we are running FOG 1.2.0, no SVN, I believe a UEFI image, (though our machines are set to boot using legacy BIOS, so I am not sure how FOG sees it) and our OS is Ubuntu 14.04 LTS hosting FOG.

Any help you can provide would be tremendous!

[Tom Elliott]

@KellyM @Jtech This is because of the way the “size on client” gets calculated.

The size on client get’s updated (just in case something changed) every time there’s an image task. This way things will be as accurate as possible. In order to do this, relatively simply, I zero out the original value. Due to this, if there’s a problem actually deploying the image, it would leave it in a “zeroed” out state.

This does not mean there is a problem with the image or fog though. This is just a calculation, so this (itself) is NOT a problem to be concerned about.

[JTech]

@george1421

it reads 1.2.0

[JTech]

Kelly m post with the picture is doing exactly what my system is doing. hope fully this clear some stuff up there are no error code in this process.

[george1421]

@Tom-Elliott It appears that the OP is using the 1.2.0 stable image on pretty new hardware (2014). It was my understanding that 1.2.0 stable had issues with uefi image deployment. It would capture the image no problem but it would not lay it down correctly on the disk. It was my understanding that it was fixed in the mid 4000 range of the Git trunk. Is that accurate? For me I would recommend the OP upgrade to the latest SVN trunk, with the understanding it is still beta and pre 1.3.0 release (i.e. there may be a few bugs in the system, but they will get stamped out pretty quick).

[edit] corrected a grammar error in my post [/edit]

[Tom Elliott]

@george1421 I would recommend the same for both people having the problem.

Highly recommend the users switch to trunk, though I can’t say for sure UEFI imaging will just “work” but hopefully it will do much more in a better sense than what you are seeing with 1.2.0.

https://wiki.fogproject.org/wiki/index.php/Upgrade_to_trunk

[george1421]

@KellyM said:

For Reference, we are running FOG 1.2.0, no SVN, I believe a UEFI image, (though our machines are set to boot using legacy BIOS, so I am not sure how FOG sees it) and our OS is Ubuntu 14.04 LTS hosting FOG.

UEFI vs Bios is a state of being. You either are or are not. On the Dells you CAN have UEFI enabled with the legacy roms turned on. In this case uefi emulates bios. For me its not clear either if fog sees a uefi system or an emulated bios device. There is a way to tell if you capture the initial bootp request from the client as its asks for an IP address. It will state the arch in object 60 or 93 (I believe). It will be 00000 for bios, 00006 for uefi 32 and 00007 for uefi x64. There are a few others but that is what I can remember.

If you are using the 1.2.0 stable then you may have the same issue as the OP, hang tight.

[KellyM]

Hey guys!

Just wanted to update you to let you know that my image is working just fine. Just like Tom said, The image appears to still be good. I was attempting to use an old hard drive off our shelves and I’m just gonna chalk this issue up to a bad hard drive. I was just able to successfully upload the image to a new Dell SSD (which is ultimately the type of hard drive we are wanting to use anyway).

I didn’t have to switch to trunk or anything and I was still able to successfully download the new image.

I hope JTech’s issue is as simple to solve as mine was.

Thanks for your help guys!!

[george1421]

@JTech Any update on this?

[JTech]

we are still working on this and have made progress but it is still happening

[Atech]

@george1421

I work with @JTech

Upgrading to the newest SVN Trunk version worked.

To answer your previous questions we were using:

1. 1.2.0
2. It was not a SVN Trunk version, simply the latest stable version
3. The image capture was Capture with Legacy boot (secure boot off)
4. FOG was installed on Ubuntu 14.04.3 LTS

The Functional/upgraded setup is:

1. 1.2.0
2. SVN 5688
3. Image captured with Legacy boot (secure boot off)
4. Fog is installed on Ubuntu 14.04.3 LTS

[george1421]

@Atech Thank you for the feedback. So the ultimate solution was to update to the latest trunk version.

If that is accurate and the issue is resolved, can I mark this issue resolved?

[Tom Elliott]

@Atech can you tell us what the cloud version shows? It sounds like you got the latest which is not known as 1.2.0.

1.2.0 on 5678 is still 1.2.0. The tag hasn’t changed just the revision has. I’m just trying get the information more directly so new users and searches can find the info in this thread

[Wayne Workman]

@Tom-Elliott I thought SVN 2094 was the 1.2.0 release? I’m very confused right now.

[Tom Elliott]

@Wayne-Workman you’re absolutely correct. 2094 is the svn rev at which we made the tag of 1.2.0. But if you’re pulling the tag instead of trunk, the rev will display the current rev of the repository, not the rev of the tagged released