Posts made by JYost

The dropdown option “Snapin file exists” has disappeared from the Create new snapin page after the 1.5.10 update. I used to be able to copy a file to the snapin directory, then select it using the dropdown. Now it forces me to browse to the file and download to the /snapin folder. I selected the .msi I wanted to import into the /snapin folder but it never shows up. I must be missing something but there doesn’t seem to be a way to create a new snapin any longer.

I have about 20 snapins which I’ve made available for techs to select during the pre-imaging setup for workstations. One of the newly created snapins I have disabled temporarily as I did not want it made available (YET), however it is showing up in the “Available Snapin” list, and techs are able to select it and install it without any problem. To me, disabling a snapin (should) make it unavailable for selection to install although I may be incorrect in my assumption of exactly what disabling a snapin does. Can you elaborate - is this a bug or normal operation? Aside from actually deleting the snapin is there a way to have the snapin present, but not available for techs to select/install? Thanks in advance. FOG 1.5.10 on Ubuntu 20.04.

@Sebastian-Roth
Thank you Sebastian, I will give that a try. Thanks again for the excellent support! You can close this ticket.

Background: We recently changed the user account that we use with FOG to join the domain. That account was set in the FOG settings page / Active Directory section.
Whenever we image devices now we come to the Active Directory tab in the web interface, but it is still showing the old user account in the Domain Username field. If we uncheck and re-check the ‘Join Domain After Deploy’ checkbox the field auto-populates with the correct/new username. My question is whether there is some cached data that we need to clear out so that the new account name automatically appears in the Domain Username field without having to uncheck and recheck the top checkbox. We have over 2000 hosts on multiple servers - that is a lot of unchecking and rechecking boxes!!!

We’re running FOG 1.5.9 on Ubuntu 20.04

@george1421

I just tried another capture after changing the FOG client on the image to point to our FOG server in Germany. This time there was a normal 1 minute pause during the resizing process then Partclone G-zip started and imaged without problems. All seems normal again…gremlins have been eradicated. You can mark this as solved.

@jyost

I did notice something odd about the latest image capture though…
Normally using Partclone G-Zip we end up with 10 files in the image…this time we ended up with 11 files:

And here is the 21H2 image I captured immediately prior to the iPXE boot loader update - 10 files:

@george1421
The VM partition is 60GB - as far as fragmentation goes the partition resides on an SSD which shouldn’t be defragmented. I’m not of the opinion that fragmentation had anything to do with the slow resizing as the image I captured immediately before the iPXE boot loader update resized within a minute or so. The same image was captured after the boot loader update (the only difference being the FOG client installation using a different IP.)

Even with the long resizing the second time around the image uploaded and downloaded fine without any errors.

Sidenote: You stated that FOG 1.5.9 had issues with 20H2 and possibly even 20H1. Ironically we have been using FOG 1.5.9 with 20H1, 20H2, and 21H1 without any issues whatsoever. 21H2 is where we ran into problems.

So, moving forward…for the rest of our fog servers I take it that the order of operations to fully update our servers should be as follows:

1.) Update FOG to v.1.5.9.111 by updating the FOS init (is server restart or re-run install fog.sh required here?)
2.) Update Kernel to latest version, then restart FOG server
3.) Update iPXE to latest version, then re-run installfog.sh

Again, thank you George, Sebastian, et al. for the excellent tech support. You guys are geniuses.

@george1421
No, I never do in place upgrades. This is a fresh copy of 21H2 straight from Micro$oft.
The strange this is I created a 21H2 image with no problems whatsoever immediately before doing the iPXE boot loader update. After the boot loader update I went back into the VM, Opened the pre-sysprep snapshot, uninstalled the FOG client and reinstalled it with a different IP address (for a different site in India) as I’ve done countless times before. Re-ran sysprep and attempted the capture. That’s when the problems started…

EDIT: AS I AM TYPING THIS Partclone finally started the capture (~25+ minutes later). Strange.

I will need to test this image to see if it’s working and report back…

@george1421

Closer…after updating the FOS init and restarting the server, the Init Version is now 20210807. The blkid error is also gone. “New fixed partition for (/dev/nvme0n1p4 added.” message is now displayed (which I assume is good ). The only issue now is that the PXE boot process is now hung up on Resizing filesystem…
Normally this passes within a minute or so and PartClone does it’s thing. It’s been 15 minutes now and we’re still stuck.

@george1421
How does one get to the dev-branch to download 1.5.9.111??? The Kernel has already been updated to the latest.

Screenshot below:

I’ve gone through 5 of our FOG servers and updated the iPXE boot loaders on all of them, then re-ran the FOG installer and restarted. On our primary FOG server I am now unable to capture images. (NOTE: I was able to capture an image immediately prior to performing the iPXE boot loader update)

During the capture sequence I am getting the following error immediately after mounting the partition:

blkid: error: /dev/nvme0n1p4: No such file or directory…

The process continues running the partition resize test, then begin the resize process where it hangs indefinately. With limited Linux knowledge I’m at a loss on what to look for. Googling the error I found someone that said that the libblkid-dev package may be missing so I installed that package but the problem persists.

Screenshot:

Just heard back from our Cali, Columbia office. All is well, device imaged fine with no errors. Thanks again for the awesome support!

Thank you George for the instructions - I have updated the iPXE boot loader and re-run the FOG installer as directed. Currently waiting on our user in Cali Columbia to try imaging again. Fingers crossed that this will resolve the issue…

UEFI IPv4 is enabled
UEFI IPv6 is disabled
SecureBoot is disabled
Normally, the Lenovo BIOS on other models has the following options under the Startup Tab…
Network Boot - set to PCI LAN
UEFI/Legacy Boot - Set to BOTH
UEFI/Legacy Boot Priority - Set to UEFI First
Boot Mode - Set to Quick
However, on this particular model (E14 Gen2) it gives only the following options:
Network Boot - Set to PXE BOOT
Boot Mode - Set to Quick

@sebastian-roth
We are running FOG 1.5.9 on Ubuntu 20.x

During PXE boot I am receiving the following messages -
…
Waiting for link-up on net0…ok
Configuring (net0 MAC…No configuration methods succeeded (http://ipxe.org/0040ee186)
Configuring (net0 MAC…No configuration methods succeeded (http://ipxe.org/0040ee186)
DHCP failed, hit ‘s’ for the iPXE shell; reboot in 10 seconds.

Other models of laptops are imaging fine (Lenovo T480, T14, and L14). I suspect that the Realtek NIC drivers for this particular model/variant are not included in the Kernel. Suggestions/comments?

FYI - Kernel on the FOG server has been updated to 5.10.74 (64-bit)