Dell latitdue imageing problem
-
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!
-
@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.
-
it reads 1.2.0
-
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.
-
@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]
-
@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.
-
@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.
-
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!!
-
@JTech Any update on this?
-
we are still working on this and have made progress but it is still happening
-
I work with @JTech
Upgrading to the newest SVN Trunk version worked.
To answer your previous questions we were using:
- 1.2.0
- It was not a SVN Trunk version, simply the latest stable version
- The image capture was Capture with Legacy boot (secure boot off)
- FOG was installed on Ubuntu 14.04.3 LTS
The Functional/upgraded setup is:
- 1.2.0
- SVN 5688
- Image captured with Legacy boot (secure boot off)
- Fog is installed on Ubuntu 14.04.3 LTS
-
@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?
-
@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
-
@Tom-Elliott I thought SVN 2094 was the 1.2.0 release? I’m very confused right now.
-
@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
