@wt_101 Well juggling three with running chainsaws doesn’t make it a bad idea, does it?

The 15 character limit is a windows NT thing. Since the majority of the folks that use fog for image deployment the developers have set it to 15 characters. If you have a use case where you need more than 15, I don’t see the harm in expanding it to more than 15 characters. That is the beauty of opensource. If it doesn’t work for you out of the box, if you have the skills you can change it.

You just need to be mindful if you have to interact with windows that the computer name might get truncated 15 characters when the computer name is set.

But also be aware that I don’t know of anyone who has tried to set computer names long that the MS defined standards either. Other things in FOG may break (thinking fog client if its hard coded at 15 characters).

@nickw Check if the real time clock is set correctly.

@sourceminer said in Capture Image partclone fail.:

Suggestion: would it be a good idea to test these dirty flags prior to running the lengthy imaging process

I know there is a check for the dirty bit before imaging starts, but that might only be on the OS partition. Looking in the code I see a resetFlags function that actually runs the “ntfsfix -d” command. I’m not sure how its applied. I know if your drive contains the windows dirty bit the imager will stop before it starts deploying anything. So its not clear why it didn’t catch the issue on the 4th partition. But I do have to say its rare that the recovery partition would have been shut down uncleanly.

But in the end I’m glad you have it worked out.

great thanks @george1421 i understand now, basically to do this right, you need to sysprep using an unattended xml file which i dont do, so best case scenario is i can just leave the drivers there and install once im on the desktop,

thanks again george

@riry Yes and no. Lets follow this tutorial https://forums.fogproject.org/topic/7727/building-usb-booting-fos-image

Also look at the FOG Forum chat bubble for a few more hints.

@zaboxmaster The short answer is no. That wiki page refers to FOG 0.3. That feature is already built into FOG 1.5.9 through a different method. At the FOG iPXE menu, you can select Deploy Image. You can thus deploy an image without registering the computer with FOG. A system reseller might use this feature to load a base OS on a computer then never see it again.

There are a few caveats with this method. The big one is that the FOG client can’t be used because the target computer is never registered with FOG. So this means your image deployment needs to be complete and not use any function provided by the FOG Client. I can tell you in my environment I don’t use the FOG client. I use the windows unattend.xml to name the computer and connect it to AD. I use a FOG Post install script to update the unattend.xml file with deployment time settings (computer name, Domain OU, timezone, keyboard mapping, etc). So it can be done rather well without the FOG client.

@rubix8 OK there are a few things here, but lets try the easiest first.

FOG has two components. One is iPXE. If you can get to the FOG iPXE menu then its not an iPXE issue. The second part once you make a selection on the FOG iPXE menu bzImage and init.xz are transferred to the target computer. That is FOS Linux. You should make sure your FOS Linux kernel is up to date. You do that via the Web UI -> FOG Configuration -> Kernel update. You should download 5.15.x series for both x64 and x32 kernels. That will (should) take care of the can’t get hard disk. If it does not then we will debug more.

@rayne Well this isn’t getting us to a solution then. The issue is between the uefi firmware and iPXE. If your firmware is up to date on this system (please check), then we will probably need to create a usb boot disk to load into FOG imaging. You will lose some capabilities that iPXE has but you can unicast image with this route.

First check the firmware then if that is up to date I can give you guidance on how to create a FOG usb boot drive.

@blueberry Cancel the shutdown task after a few minutes when those being on are shutdown. Don’t think there is any kind of logic within the FOG power management scheduler to detect shutdown clients and ignore those.

Hi, seems it was failing to update the DB at the end of the imaging,

We reset the DB creds and now its working perfectly 🙂

@pbelzile If you are running FOG 1.5.9 then M$ changed the disk structure starting Win10 20H2. They marked the recovery partition as non-movable. That causes resizing the disk a bit complicated when going from larger to smaller. FOG 1.5.9.115 (i.e. dev branch) has a fix for it so if you switch to the dev branch then you might work around it.

Or removed that recovery partition because it has little value because in my opinion you can just reimage with fog faster than trying to save the OS by using windows recovery. Now there are times where based on your installed applications you need to save the OS for some reason, then boot from a usb recovery disk to try to revive the system.

Now in your case, when you capture the image. On the largest partition watch to see if partclone is in raw mode. This is a block clone method that records all blocks on the disk. In this case you will get about the same size on disk in the captured image. Depending on the target OS, it might say ntfs or ext4 then that is file based capture. That capture value should be the size of the actual data on the disk.

@sebastian-roth Ok - thank you - that works! ( I actually did see mention of this but did not quite follow through on testing it)

ipxe boot issues with https enabled (I enabled https on the old server and it all went wrong).

Ran into this issue again with new server this morning – looked at the system time of the pc, date was way off – corrected and booted fine…I gather system time + UEFI + https ipxe is crucial?

Regardless, I appreciate the quick replies!

@ouédraogo Please update your FOS Linux kernel to version 5.15.x series for both x64 and x32. FOG UI -> FOG Configuration -> Kernel update.

That should address this issue.

@trev-lchs it appears this was a one off and subsequent installs have not had this issue. So this one can be written off as solved. Seems the resize NTFS partition failed to work one time.

@geekyjm said in PXE client not seeing new Fogserver:

How do I tell if the PXE server is running on the Fog server?

If you want to get literal, there is no such thing as a PXE server. PXE is a protocol not a thing.

DHCP tells the client where to look for the boot file. Then the client downloads what its told from a tftp server. That is the pxe process in 20 words or less.

The pcap is important to ensure the client computer is being told to load the right file from the proper computer. If you look in the OFFER packet (that comes from the dhcp server). In the header there will be a {next-server} field. That should be the IP address of the fog server. There should also be a {boot-file} field, that should be ipxe.efi or a uefi system and undionly.kpxe for bios system. That should match dhcp options 66 and 67 respectivly.

@george1421 Thanks George, i will leave well alone, I am a great believer in “if it isn’t broke don’t fix it”. Thanks for all your help with this.

@george1421

Thanks for the hint! Turns out a field in the Web Server section had the old IP address. All is well now.

@trev-lchs that was the Ticket George, I just thought the config would go across to the fail over DHCP Server, live and learn eh. Thanks very much for your help

@jacob-woolbright said in Fog management website throws 500 error:

Would it be best to just revert to 20.04?

Yes or debian 11 if you want to switch to FOG’s dev branch a.k.a.1.5.9.115 or later. When its released it will become FOG 1.5.10. The newest version of PHP in 22.04 needs a little clean up on the FOG side before its ready for release with FOG 1.5.11.