Testers

And it appears to be totally random whether it throws that error, cold boot, warm boot, reset, whatever. If blkid: error comes up I just keep resetting the vm until it goes away .

There is not quite enough info in your OP.

1. Is the computer a bios or uefi based?
2. Is your dhcp server configured for static or dynamic boot file names?
3. What is your dhcp server? (mfg and model)
4. Is it only this specific computer that has booting issues or do you have others that have similar failures?
5. It would be really handy to know what it flashed on the screen after it gave up with ipv4. Possibly video it with a mobile phone in slow video mode?
6. Is the firmware (bios) up to date on that target computer?

@Trev-lchs OK just for clarity the kernel is the FOS Linux kernel that does the imaging. That is independent of the pxe boot loader (that creates the FOG iPXE menu). Difficulty pxe booting then should be focused on undionly.kpxe for bios and ipxe.efi for uefi based systems.

@Trev-lchs Sorry I had to step away for a bit, it looks like you have it. The password found in the .fogsettings file should always be considered the master password since the fog installer/upgrade script will always reference this password when making system adjustments. If for some reason the web ui passwords get out of sync with this password you will get random failures as you saw.

@Trev-lchs you may need to be root or sudo it to view the file sudo cat /opt/fog/.fogsettings

@Trev-lchs OK, while you said you haven’t changed anything with passwords something else might be going on here. Lets have you run through this tutorial just to ensure everything is in its place and set properly: https://forums.fogproject.org/topic/11203/resyncing-fog-s-service-account-password

A good test once you complete the tutorial is to see if you can ftp from a windows computer to the FOG server using the user ID of fogproject and the password found in the .fogsettings file. (note you may have to drop the windows firewall to allow the ftp program to connect to the remote computer).

What version of FOG?

@george1421 You have a great point. I discussed it with the boss, and we went the path of no client on the laptops. It is a relatively small number right now that need a somewhat quick turnaround. I figure we can bang out renaming and joining manually for these. Perhaps I will investigate other methods if there is a future order or it is the direction we end up going. Thanks!

@ProfDrSir said in Imaging Windows 10 v2004 with UEFI - GPT Partitions onto 31GB or smaller drive. (and failing):

which fat standard are you using?

There are two methodologies here. The first is a thin image in that only the windows OS and updates are added to the reference image. All other applications like office, SAP, acrobat reader are added into the image on the target computer. The advantage to this is that when updated versions of acrobat reader or other applications come out you don’t need to rebuild your reference image (because it only contains windows + updates). You just change your post deployment tasks (snapins, or what every deployment tool you are using to deploy the later application)

The second is a fat image, in that you load all applications onto your reference image before you capture it with FOG (understand if you have applications that are based on a unique guid, like enterprise antivirus you must install those post imaging anyway). All of the time of loading these applications goes into the reference image and not post deployment. With MDT it takes about 1.5 hours to create and configure the reference image. When I capture it with fog the reference image is about 98% of the completed image. With a fat client I can take a workstation and go from bare metal to ready to move to the user’s worksite in 15 minutes. The system is fully configured and ready to roll. I don’t have to do much post install configuration.

To recap a thin install gives you the flexibility to modify the deployment with different applications or configurations at deployment time. A fat image you put all of your work in to the reference image up front and then enjoy rapid deployment on the back end.

Before win10 our methodology was to use the thin image approach because we could create a standard OS reference image and use it for a year or so. Basically the applications would update version more often than the OS. Now with Win10 we have to build a new OS every 18 months so the OS updates more frequently than the applications. That makes the fat image approach more beneficial.

As I mentioned a few times previously we use MDT and the lite touch approach to build our reference image. That way we can get a consistent build each time we rebuild our reference image. When we go between 1903 and 1909 we just copy our task sequences between builds and we get the same results (hopefully) when we build a new base image on the next release of windows 10 (the last OS you will ever have/need).

@ProfDrSir said in Imaging Windows 10 v2004 with UEFI - GPT Partitions onto 31GB or smaller drive. (and failing):

we can just remove / ignore that 4th partition it makes imaging slightly more tedious, but functionally should be the same as before I’d assume.

This is just my personal opinion but that recovery/restore partition really adds no value in a business environment. Using the windows recovery method it take an hour or more to bring a broken computer back. With FOG, and fat win image, I can go from bare metal to ready for the user in 15 minutes. Total tech hands on time is about 40 seconds for imaging vs dealing with the restore process. Now if you have irreplaceable data on the broken system your only option is to recover especially if bitlocker is involved.

In our case we never do an in place upgrade, its always nuke and pave when going between releases. I know the upgrade process works, its just we find its faster for nuke and pave (once the user’s profiles are backed up with USMT).