@jaapvdpol In theory its possible to do with FOG. The concept in FOG terminology is master node at HQ and storage nodes at the remote locations. The master node will replicate the images created at HQ to all remote storage nodes. One caveat is that the remote locations must be in constant and routable contact with HQ 100% of the time. PXE booting computers at the remote site will contact the FOG master node (at HQ) to find its local storage node. Once identified it will image directly from that local storage node. Only status update packets are sent between the imaging remote computer and the FOG server at HQ. So by design it will work, I’m just not so sure about the scale you propose.

I wonder about your update frequency of these computers and if the proposed design is the right one based on how often you think you will reimage a remote computer. Will it be a one time imaging and then only reimage when the system fails? Would a mobile FOG deployment server work better for your deployment plan? In this design you would have a laptop running linux with FOG installed. You would also include dnsmasq with this mobile deployment server to provide pxe boot information to the pxe booting computers. You won’t need to adjust your remote sites networking to support pxe booting, you just drop the mobile deployment server on the network. Once booted you can pxe boot into the FOG iPXE menu and pick deploy image (system builder load and go methodology). You wouldn’t have post imaging management with the load and go method, but is that in your plan or only to migrate operating systems?

@boros There is no RHEL/CentOS since they are both dead to me now that IBM had its way…

BUT, someone with the proper motivation can probably make it work. I would start with my post here: https://forums.fogproject.org/post/103324 That will give you the basic layout. Now lets mix it with these instructions. https://docs.centos.org/en-US/8-docs/advanced-install/assembly_preparing-for-a-network-install/

The most useful section is from the syslinux boot menu.

label linux menu label ^Install system menu default kernel images/CentOS-8/vmlinuz append initrd=images/CentOS-8/initrd.img ip=dhcp inst.repo=http://10.32.5.1/CentOS-8/x86_64/iso-contents-root/

While FOG uses iPXE its possible to translate between the two formats. From the first link this is what I used to call centos 7 installer.

kernel tftp://${fog-ip}/os/centos/7/vmlinuz initrd tftp://${fog-ip}/os/centos/7/initrd.img imgargs vmlinuz initrd=initrd.img root=live:nfs://${fog-ip}:/images/os/centos/7/LiveOS/squashfs.img ip=dhcp inst.repo=nfs:${fog-ip}:/images/os/centos/7 splash quiet boot || goto MENU

So to update the syslinux format to iPXE

kernel tftp://${fog-ip}/os/centos/8/vmlinuz initrd tftp://${fog-ip}/os/centos/8/initrd.img imgargs vmlinuz initrd=initrd.img ip=dhcp inst.repo=http://${fog-ip}/centos8/ splash quiet boot || goto MENU

So you will need to copy vmlinuz and initrd.img from the iso to the fog server into /tftpboot/os/centos/8 directory. This places the boot files in scope of the tftp server. The next is to place the contents of the iso (extracted) into the scope of the web server in /var/www/html/centos8 directory. So the target computer will load linux and the initrd from the tftp server and then access the rest of the centos files from the contents uploaded to the web server.

@george1421
Thanks, that’s very helpful. I’ll do some debugging and see what I can find.

@sega You can try something like this:
https://superuser.com/questions/29450/how-to-do-a-powershell-or-other-script-to-change-screen-resolution

Sure it’s a help site, but it should be there to help out.

@ShiraiKasumi said in How much editable is the boot menu?:

can I use html files to configure the boot menu

The quick answer is no…

The boot menu is managed by the boot loader called iPXE. iPXE uses a batch/cmd/bash script like macro commands to build the FOG iPXE boot menu. Its not a html or other mark up language. If you have a fog server already running, go to your browser and key in http://<fog_server_ip>/fog/service/ipxe/boot.php?mac=0 To actually view the iPXE script behind the FOG iPXE menu.

Now with that said, that boot.php page referenced in the URL is responsible for creating the FOG iPXE menu. FOG is opensourced so you can do what ever you want to modify the FOG iPXE menu in that php page.

Lastly FOG has a built in iPXE menu maker where you can add custom iPXE menu items to boot unique tasks. I have a tutorial on how to add menu items into FOG’'s boot menu to load installers for different operating systems over PXE boot https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images
That page will give you examples on how to add entries to the boot menu.

@PhilienTaylor I’m not sure what your question is here. Your end goal is not clear based on what you have posted.

FOG doesn’t support imaging over Torrent. FOG doesn’t support Secure boot. There is a tutorial on how you can create your own keys and then sign the boot files. This will require you to upload the certificates into each hardware. Or to go to microsoft and go through the process to get microsoft signed signing keys for what you want to boot on the target hardware. FOG doesn’t have any utlity for hypervisor environments. The FOG server can run as a vm client, but FOG has no relationship with virtualization.

@george1421

Absolutely, I already had http serving in-place so the additional 1GB size result was negligible impact. Thanks for the additional insight, however.

Happy to help out, I just noticed a majority of posts about this ended with users reporting Hiren over PXE was “solved” by simply updating their wimboot version, with no other notes. While it does fix booting it, it is only part of the solution. It’s necessary to do that but it is not a complete fix. You need the Y:\ mount fixed or else the booted ISO is still heavily broken. Hopefully this helps some people out. HBCD is a great Swiss Army knife.

PS: I changed BOOT EXIT TYPE and EFI BOOT EXIT TYPE and the rEFInd menu appeared and the Windows was booted.

Just curious to know if that fixed the situation or renaming the files which I mentioned before.

@AisleWay The WOL Broadcast plugin is designed specifically for your use case.

Seeing as fog server is running on 10.133.x.x, the WOL packets are restricted (by default) to that particular subnet.

If you add the broadcast of 10.20.x.x to the plugin, it will send there.

If you need it to go to 10.10.x.x, add it to the plugin and wol will send via that as well.

Not sure what else we can provide.

This seems, to me, to indicate that the other networks are separated.

For example:

10.x.x.x is generally the whole scope, (10.0.0.0/8) but you have your network broken into seperated subnets.

For example:
10.0.0.0/16
10.1.0.0/16

etc…

If all systems in your network is in the 10.x.x.x scope, why the separation when you want not to have to worry about what network to send across?

@mashina said in Providing installation media via pxe booting for UEFI systems.:

Interestingly, the problem doesn’t occur when Ubuntu is already present, and then Windows is deployed. Anyway, that is not a big problem at this moment.

But in this case the uefi firmware has already registered ubuntu as a bootable OS. So it just goes, oh hello I see you again on disk1. But if the entry doesn’t exist then it needs to be fixed up. You might be able to test this on a working system, go into the uefi firmware and delete the entry for ubuntu on the second disk, only leaving windows in the uefi boot manager. Upon reboot does it need to fix itself up again?

Just be aware that FOG doesn’t touch the uefi firmware or boot manager. BUT you can do that with in a FOG post install script and using the linux uefi manager (not the actual name) app. You can add remove uefi boot manager entries at your need.

Your suggestion works well for putting Linux on Disk1, but if the user needs to reinstall Windows, it’ll also go to /dev/nvme1n1, messing everything up

True it will mess everything up. But also I took your inital post as you will load windows once and then could potentially reload ubuntu or the OS on the second drive multiple times. If you “had to” you could write a FOG preinstall script to ask what drive do you want to send the image too, but that gets a bit messy, but its possible.

@Orfeous said in FOG Project instead of CloneZilla Lite Server:

My goal here is to install Debian or Ubuntu on a PC to be run as a Server. I have a couple of NUCs that I want o deploy an image to via isolated network. Server and Client machines connected to the same switch. No router or such in play.

You can do this on an isolated network completely or install 2 nics in your FOG server and have one connected to your imaging network and one to your business network for remote management on the fog server.

You can also set this up on your business network without interfering with your business network communications. So it can work either way. In some instances you might need access to your business network for AD integration as your target computers boot during its first boot. I understand your goal is linux so AD is not required. But the point is either way FOG will work.

I want this Server to run a DHCP server and broadcast ips to the client machines that will be netbooting via PXE.

If you want to run on an isolated imaging network, just pick to include the FOG DHCP server and the installer script will install the dhcp server and configure it for you.

I want to use those NUCs to boot via PXE and then automatically disk will be restored from image.

If i get other PC vendors and models I want to use another image for those.

No problem on multiple vendors. You just need to really be mindful of the firmware on the target computer bios or uefi modes because the target image is handled a little bit differently between the two firmware classes. FWIW you can not deploy a bios computer captured image to a uefi based computer. The same holds true in reverse.

Is it possible to use my CloneZilla disk image that has already been saved?

While Clonezilla and FOG both use partclone to capture the disk image, the images are stored and compressed differently on either platform. So you can not share the images between the two environments. You will need to capture with FOG if you want to deploy with FOG, or capture with Clonezilla if you want to deploy with clonezilla.

Client NUCs uses NVme ssd and Windows 10 or 11 is located on the disk image.

Now you introduced Windows 10 into the picture. No problem, but that also might mean needing AD during firstboot. You have to remember that the FOS engine (the OS that boots on the target computer) is linux based. So nvme drives have a different disk label that sata drives. But you can capture from a sata drive and deploy to an nvme drive, but that is not a common situation.

Is this possible with FOG Project?

Yes it is

@george1421 Thank you for the information. I have managed to migrate/images, /snapin and the database to another new FOG server. Some steps needed to be done such as replacing the original IP with new IP. Because I intended not to use the original IP for the new FOG server as a backup plan. If anythings goes wrong with the new FOG server and I can revert to the original FOG server. 🙂