@rogerbrowntdl yes a smaller mother image would be best. 1.5.9 can grow the golden image to the size of the disk but not shrink it. Or just removed the recovery partition from the golden image. If you have an imaging solution in place is the recovery partition even useful?

I started with fog the shrink option really worked so I would create my golden image on a 70 or 80GB hard drive then expand it post deployment in windows. I also developed our golden images on a VM because I could snapshot the vm before critical steps. That kept me from having to rebuild the entire image again if I botched something. Stuff happens you know.

@brakcounty Here is a list that one of the developers created a while ago. Its still relevant so you should be able to use it as a basis of your settings:
https://forums.fogproject.org/topic/6162/firewall-configuration

If you use multicast imaging then you will need to take some additional steps.

@george1421 If I do everything manually as I’ve been doing, it works fine. Just looking to save some keystrokes. The boot.wim I’m building using MS Endpoint Config Manager Console does not have any task sequences but instead contacts the MG/DP for available task sequences and goes from there. Its easier this way. If we start to make stand-alone TS ISOs the wim files will become too large for ipxe.

@mgoh said in Reinstating Images to the Web UI:

I tried that, and the size of the image is 0 GB. Is that expected?

This is expected if you manually create the image definition. If you were to upload an image then that field gets populated. Its only used for display and not for any imaging activity. So it can stay at 0B forever.

@george1421 I made update of IPXE to the latest version and then I tried ipxe.efi and sucess! Thank you!

@george1421 So the second part of this is; I would create a custom FOG iPXE menu item to test this next bit. Since refind exists in the http path we can use the http protocol to grab the files you need.

I would start out by cloning the FOG provided refind.conf file to… for this example refind2.conf. Place any files you want to load in the http path on the fog server but not in the fog file path because an upgrade will delete your custom files. For this example lets create a new directory with
mkdir /var/www/html/crefind place your cloned refind2.conf file in there plus any other files you want to load onto the refind vhd.

set http-path http://${fog-ip} set custrefind-path ${http-path}/crefind set refind-path ${http-path}/forg/service/ipxe kernel ${refind-path}/refind_x64.efi imgfetch --name refind.conf ${custrefind-path}/refind2.conf refind.conf imgfetch --name os_linux.png ${custrefind-path}/os_linux.png os_linux.png imgfetch --name theme.conf ${custrefind-path}/theme.conf theme.conf boot || goto MENU

Understand I did not debug this menu at all, I just glued the bits together. So it might work or might now. But the idea is correct. Remember in your refind2.conf file the ipxe vhd has no paths so everything is stored in the root of the vhd. So this config file stanza
icon /EFI/refind/themes/rEFInd-minimal-drunkcj/icons/os_linux.png
Needs to be rewritten as
icon os_linux.png

@londonfog Not sure but I don’t think there are API calls for the iPXE menu stuff. I suggest you look into using a SQL query/insert or you might be able to code your own plugin to get what you want.

@jmccannon The current version of FOG only has admins and that is it. There is an admin plugin module, but I have never personally used it. I do agree that FOG needs to have and admin user and a capture/deploy/imaging user class.

Eu havia procurado antes mas não tinha achado solução no fórum para esse problema. Procurando mais, encontrei solução conforme esse post: Storage group activity - 1 active