Posts made by jemerson93

@george1421 Also I’m not sure how to change this to solved.

@george1421 George I’ll look into that for other USB nics (my Linux knowledge is not the greatest but growing)

I can deal with the longer erasing mbr/gpt partition for those specific devices (hoping newer kernels may resolve it)

Thanks again for the help! So greatly appreciated.

@tom-elliott @george1421

Update. I tested another one of our images just to test imaging and it successfully imaged. I appreciate the assistance so much.

I do have 2 questions. First question, I noticed when using this kernel compared to the current kernels I am using, I am back to the issue with the long erasing MBR/GPT partitions. Anyway to fix that with this custom kernel or just need to deal with it?

Secondly, is there a way for me add other usb nics as I find issues, or how to find a kernel that supports them instead of opening a forum post if I run into issues. Reason I ask is we have a Dell USB nic for some of the new XPS models and I have yet to test it.

@tom-elliott I have 1 storage node and I just tested that specific image (which used to work) on another laptop and it had the same issue.

When checking /images, I am finding all of my images except for that one listed. I will re-upload it now and test.

@george1421 said in Issue imaging with Surface Pro:

bzImage41713m

Did as you said, kicked in the eth0 interface and got further. Now running into this issue.

@george1421 George, this Surface only has 1 USB.

Here is what I attempted. Connect Microsoft usb nic, boot to FOG, select deploy image
As soon as I selected the image, I unplugged it and connected the generic one. I received the wwan error but after it failed a few times, it went into eht0 (this is with the generic usb nic) but I received a new error.

If I can get this error fixed, at least while you look into the microsoft nic (which I appreciate so much as this is out of my knowledge), this may work as you said as a sloppy fix

@george1421 Okay going to go in order from your post.

When inputting lsusb, I receive the following
Bus 002 Device 002: ID 045e:0927
Bus 001 Device 002: ID 045e:09c0
Bus 001 Device 001: ID 1d6b:0002
Bus 002 Device 003: ID 045e:094a
Bus 002 Device 001: ID 1d6b:0003

Manufacturer & Model: Microsoft USB Ethernet Adapter Model 1821
Hadware ID: USB/VID_045E&PID_0927&REV_3100
USB/VID_045E&PID_0927
Surface Pro Model 1807 (Looks to be the 2017 model)
All of the Surface Pro’s I have had issues with are either the 2017 model or 2018 model. All had LTE support enabled

If I use a generic usb nic, it does not even PXE boot on a Surface. I have had success using a generic USB nic with other tablets though.

@george1421 Basically this is what happens

[Wed Aug 15 root@fogclient /]# lspci -nn|grep etwork

• Press enter
  [Wed Aug 15 root@fogclient/]#

@george1421 I am using the USB Adapter

When inputting the command, I just get another input. Nothing displays.

@george1421 George, I do not see eth0 listed.

Below is the image.

@george1421 George, that is the correct IP Address.

Yes, the WWAN0 is what is confusing me. It is booting to the USB Ethernet adapter but booting as WWAN0 instead of ETH0.

If it helps, and I cannot quote this, I believe the specific Surface’s I have been having issues with have built in mobile connection as well.

Good morning,

I am having an issue with imaging Surface Pro’s. I am using the Microsoft Ethernet Adapter but once I select either Full Host Register or Deploy an Image, I get the following error. Currently I have Secure Boot off and TPM off. I am stumped on what to do to resolve it but I have had this issue with every Surface Pro we have attempted to image.

Please let me know if you need anymore information.

FOG Version: 1.5.4
Kernel Version: 4.15.2 (To fix the long MBR/GPT issue)

@Tom-Elliott Gotcha.

Here is more of what I have found. I deployed a new FOG server (different IP and updated the DHCP Server) just to test that it wasn’t the server itself. Same issue with how long partclone is taking.

Something else I’ve noticed is that if I image a VM on the same host as FOG, it images fast again (most likely due to not being done over the network).

Currently we use Proxmox for hosting all of our VM’s and FOG.

So still the issue still seems that once the process hits partclone to image, it slows down. Network speeds seem fine and the firewall doesn’t seem to be blocking anything. I’ve checked the DHCP Server and nothing seems off. Kind of at a loss still.

I should also add that the image manager being used is Partclone Gzip

Anyone have any further input? If I am correct partclone uses multicast. I don’t know if there is a way to check that. Pretty stumped on this.

@sebastian-roth Sorry for the late response. We currently have our work network being 192.168.1 and our lab network being 192.168.200. I went through the steps to re-statically assign FOG to the 2nd scope (completely different separate LAN).

I ran a LAN Transfer test and both tests came back relatively close together. Below will be those images. First image is the first network is was on when a base image would image in about a minute. Second image is our lab network where it is currently taking 12-15 minutes to image. Bandwidth tests had download a little lower on the 2nd network and upload extremely lower but I do not think that has a correlation when imaging.

@quazz The 4.16 bug I just haven’t downgraded to 4.15 yet. I’ve downgraded and just re-updated while I work on the new issue.

As for PartClone, the weird part is nothing has changed except for the FOG version and the subnet. Everything else has stayed the same.

Hello all!

Recently moved FOG to a different subnet and in the process, I also updated FOG. I am having an issue now where imaging is taking a lot longer, specifically the partclone process.

Example is before, our base image would take about a minute to image. Now the process it taking about 15 minutes (even longer once we add a 2nd device to be imaged).

I’ve gone through quite a bit of troubleshooting and I am stuck at where the issue could be. I considered that it may be from the update (1.5.3 to 1.5.4) but I don’t see any posts.

Just looking for some input.

Current Versions:
FOG: 1.5.4
Kernel: 4.16.16

@quinniedid Sure!

Base steps were I created a new image in GPT format.

Afterwards, on the FOG server itself I edited the config file located at /var/www/fog/service/ipxe/refind.conf

Below are what I have the values at. This was after some troubleshooting so some may be back to their default values.

timeout -1
scanfor internal,external (I also have both lines commented out at the moment)
uefi_deep_legacy_scan is uncommented
scan_delay 5

From my memory that is all that is changed. After the imaging is completed in UEFI, it will boot straight to the OS instead of pushing itself through FOG and/or rEFInd.

Hope this works for you!

@sebastian-roth Yes, I did.

As another update, I spent this weekend editing rEFInd’s timeout, scanfor, and a few other settings I found browsing the forums and this morning I have successfully imaged 2 computers with my new UEFI image and did not receive rEFInd pop up at all. After it completed imaging, it booted straight into the OS.

Safe to say this has been solved. Thank you to everyone for the assistance. It is greatly appreciated!

Trying to remove the need to hit any key to continue. I know this is technically a different issue now, if I need to open a new post, I understand.