@sourceminer said in After Adding Storage for Images / deploy image mounting failed:

I lost all my settings from prior. I had to append the file.

Yes I saw this too when I was developing NFSv4 for FOG. That uses a really different exports file. So now I keep a exportfs.sav file with the correct settings in case I forget in the future.

Ok so if anyone gets this error specifically this is seemingly due to Secure Boot being enabled in Proxmox when doing a windows 11 install. I had to disable Secure Boot:
https://jhartman.pl/2021/11/08/proxmox-7-cant-boot-to-uefi-home-assistant-and-other-uefi-images/

@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.

@george1421 Thank you for your explanation! This makes sense and I was thinking of that same scenario with having more then one of same cloned disk in the same system. I tested most of our external applications and found no issues including ones that record or reference the UUID of the disk in some way and found no conflicts. As you said, the disk is attached to the “parent” record.

@Sebastian-Roth Thanks for the code reference, this does appear to be the function performing what I am referring to and I appreciate your honesty

Thank you again to both of you on your input! Tremendously appreciated.
I’ve found this to be a great community and hopefully I’ll be able to be give back in one way or another

@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.

During the installation of the client, there is a part where it asks the name of the server. Type the IP address instead.

At least that worked for me.

@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

@sourceminer said in UEFI - Dell Precision 5760:

Turns out someone had added option 60 to the global Options

Yeah that’s not a good option to have. That tells the pxe booting computer that it needs to come back after the dhcp process and talk to the proxydhcp server on port 4011 for the boot info. You would only do this if you had microsoft wds server on the same server as your dhcp server. Or if you were running dnsmasq in the linux world to do the same thing.

@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!

@tcthorne If you want to switch over to the 1.5.9 dev branch I can give you instructions. That will take your fog build to 1.5.9.115 or later. The dev branch also contains fixes for single disk resizable function with windows 20H2 and later OS’

@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.

@jester805 similar to recent thread: https://forums.fogproject.org/topic/16399/upgrading-fog-1-5-4-to-1-5-9-stable-version-using-github?_=1658515431542

Answer No to the first question about reinstalling apache seems to let the OP of that thread get things installed on 16.04.

FWIW Ubuntu 20.04 LTS is the latest version supported by the FOG installer. 22.04 LTS has not been tested as of now.