Latitude 7202 FOG PXE menu freezes

[george1421]

Thinking about bios mode. Does the 7202 have all usb 3.0 ports or are there a mix of 3.0 (blue) and 2.0 (black) ports? I can see maybe an issue with usb 3.0 and the iPXE menu. Also if you have a powered usb 2.0 hub you could try that also. Plug the hub into the tablet and the keyboard into the hub.

Also an observation, you might consider moving to fog 1.4.1. 1.3.5 had issues with resizing disk images under certain conditions. Also if we need to get the developers involved they will request you update first, because your issue may have already been resolved.

[Tom Elliott]

@george1421 add to that, it may have been resolved, but I’m always working from the “current” code, so stuff in 1.3.5 or 1.2.0 or before is not what I have to work with now. So being current helps me help you all out.

[dwcoleman]

Legacy mode would be easier I think. Most of the machines I image are Windows 7, but I’m starting to get some 8.1/10 machines.

I have the desktop dock, one USB 2.0 in the front. and two 3.0 in the back. Also the tablet itself has one USB 3.0 port. I’ve tried all of the usb ports, they all freeze the PXE menu.

I’ll upgrade to current and report back.

Thanks,

Darren

[dwcoleman]

Upgraded to FOG 1.4.1, same issue. I’m using undionly.kpxe as well, I’ve tried undionly.kkpxe as well.

The 7404 seems pretty similar to the 7202, its just an extreme rugged version.

Thanks

[george1421]

@dwcoleman

(just restating what we know already)

1. You are using undionly.kpxe (which is fine, you could try ipxe.pxe but might suspect you will get the same issue)
2. When you reposition to another menu item using the keyboard it freezes
3. I assume the same for when you use the touch screen on the tablet.
4. You are now running the latest version of fog 1.4.1 so you also have the latest version of iPXE.
5. When the tablet is in the dock and a keyboard is connected to the usb 2.0 port it still hangs.

Well if the above is true we just removed 2 of my three things we can do. We still have booting directly info FOS from a usb flash drive. If this fails then FOG is not the solution for this device. We will have to wait until the iPXE folks can catch up their design to your hardware.

https://forums.fogproject.org/topic/7727/building-usb-booting-fos-image

There is one caveat using the usb booting into FOS. Doing it this way we loose the tight integration between the pxe booting client (FOS) and the FOG management function. Meaning you MUST schedule a task before usb booting into FOS. If you fail at this you will get an error about the task not being defined. Just remember schedule the task first then usb boot into FOS.

Look at the FOG IM chat bubble at on the forum tool tray at the top of the browser

[dwcoleman]

@george1421

Thanks, I was able to pull an image this morning. I’m having an issue restoring it to another tablet, I’m getting a partition error about an unclean mount. I"m working my way through that issue.

Would using UEFI be easier you think?

I also tried ipxe.pxe, it wouldn’t even boot to the menu.

Thanks

[george1421]

@dwcoleman said in Latitude 7202 FOG PXE menu freezes:

I was able to pull an image this morning. I’m having an issue restoring it to another tablet

Did you sysprep the image before you captured it?

The unclean mount (I feel not the correct error) we see with windows 10 if its not shut down correctly before image capture. Remember with Win10 shutdown is an enhanced sleep mode not a true shutdown.

If you use sysprep before cloning, then have syspre power off the computer. That will properly close the disk for cloning.

[george1421]

@dwcoleman said in Latitude 7202 FOG PXE menu freezes:

I also tried ipxe.pxe, it wouldn’t even boot to the menu.

If you want uefi mode, two things.

1. Make sure that secure boot is disabled or you WILL have an issue with cloning.
2. If ipxe.efi doesn’t work try the older kernel ipxe7156.efi That kernel does seem to work on the MS Surface Pros better than ipxe.efi.

[dwcoleman]

@george1421

You’re right, that was the issue. I don’t have a lot of experience imaging UEFI.

The FOS solution should work for us, I’m booting a second tablet currently that I imaged and it seems fine.

Thanks so much for the help.

Darren

[george1421]

@dwcoleman said in Latitude 7202 FOG PXE menu freezes:

You’re right, that was the issue

Please clarify what was the issue for others that might find this thread.

And great on being able to image.

[dwcoleman]

I just needed to sysprep the Windows 10 image and I was able to image it successfully.

[dwcoleman]

So I created a new permanent VM for my Ubuntu installation. I then added a second volume and moved /images successfully, mounted it, and it works fine for ipxe clients.

I can no longer USB image the 7202 tablets though using Fog 1.4.2 on the new server. To prove this out I fired up my local VM and updated grub.cfg and I’m pulling an image using Fog 1.4.1.

Error is below. I’m pretty much a newbie to Fog, do I need to update my Fos USB image

Thanks, Darren

[Sebastian Roth]

@dwcoleman Re-creating the USB FOS image is a good idea. Could be that the addition of ZSTD compression is causing an issue here?

[dwcoleman]

Just recreated the image using @george1421 's excellent instructions, same error persists.

https://forums.fogproject.org/topic/7727/building-usb-booting-fos-image

Thanks

[Sebastian Roth]

@dwcoleman Do you have enough free disk space on your new server (/images partition)? Please post the output of df -h and ls -al /images on your FOG server here in the forum.

On the other hand… why would it fail that early (calculating bitmap…) if disk space is an issue? Exit code 141 I read means broken pipe. Why would partclone fail to read /dev/sda1 and not be able to deliver data trough the pipe? (just thinking out loud here)

[Quazz]

Afaik 141 is a pipe issue. Meaning that while partclone is still piping data, the compression manager has already exited (assuming). As to what caused it, I have no idea.

[george1421]

@Sebastian-Roth said in Latitude 7202 FOG PXE menu freezes:

On the other hand… why would it fail that early (calculating bitmap…) if disk space is an issue?

FWIW: The disk space issue is a bit misleading, we discovered it basically means that partclone failed for some reason and there is no way to trap the error programmatically.

[dwcoleman]

See below. /dev/sdb1 was my second 700GB volume that I added to the system. I thought it was the problem at first but verified it wasn’t.

I might downgrade to 1.4.1 again at this point since I"m running out of ideas.

[Quazz]

@dwcoleman What imagemanager do you use for this image? (on the image definition page)

[dwcoleman]

Partclone Gzip

I have two other images captured via PXE using Partclone Gzip that worked.