@jaapvdpol Well lets see if we can get a few things sorted out here.

Scale: I have not seen an install yet with 100 storage nodes. Each storage node will need to be managed at some point in time.

I kind of see this as a two phase project.

The initial push to move from windows to linux. Will you have boots on the ground at each location to do this? If yes they can bring a mobile deployment server with them (laptop kitted with what they need for imaging). If you are trying to do this all remote I can see it taking a while to complete. Post upgrade to linux. From time to time you may need to image failed computers. How will you handle that? Have a fog server at each site? Will you train local folks to be able to do this? Or is a drop ship a new system and they return the failed one for repair a bit of a better solution? Now I’ve used a raspberry pi for a fog server to image low volume systems. But that is before the prices of those critters when crazy. You think about it, with a site of 20 computers, you might, and I say ‘might’ reimage 1 computer a year. Is there value in having 100 storage nodes? I’m not saying one way or the other is right, just think about what you are trying to achieve and how much management work you are willing to do.

Now in regards to dnsmasq, that is a service we can install on the FOG server. With our configuration it will send out pxe boot information to the local subnet its connected to. You don’t need to touch anything on the router or network. So when the mobile fog server arrives, so does the pxe boot information. When the mobile fog server leaves, so does the concept of pxe booting. In this design (mobile deployment server) the target computers are not designed to pxe boot through the fog server, but instead a tech sitting in front of the computer presses F10 or F12 during booting to get to the efi boot manager where the tech picks pxe boot.

Understand I’m just trying to tell you what’s possible. Since I don’t know 100% of your use case I can only give suggestions based on how FOG works.

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

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

@FlareImp Issue fixed with

DELETE * FROM hostMAC where hmPrimary = '0';

@george1421 Thank You !
I reinstall fog with ./install and everything works now !
Maybe I did a bad installation and by restarting the installer it “fixed” the bootloaders. Have a great day !

P.S.: I really appreciate fog project thank you for all your work

@unknown56 The answer is its complicated but not impossible.

Lets take this one step at a time.

Is is possible to use a synology NAS or most other NAS’ that have nfs, and ftp support. I have a older tutorial on how to configure a synology nas for a storage node. https://forums.fogproject.org/topic/9430/synology-nas-as-fog-storage-node

Within FOG ecosystem, only master nodes (typically fog servers) can capture images from target computers. You can not capture images to Storage nodes. There is one way replication from a master node (fog server) to a storage node. This replication only runs on the master node or fog server. So you would normally have a storage group with the FOG server as the master node, and then add additional storage nodes to this storage group, as storage nodes. One way replication happens as expected master node to all storage nodes. (stick with me, I’m almost at the point). If you were to change this storage group to an unsupported configuration, where the synology nas was listed as a master node and the fog server was listed as a storage node, then the roles would be reversed. You could then capture and restore the files from the synology nas only. There would be no replication between the reversed roles of synology nas and FOG server since the replication service only runs on a real fog server. The only gotcha here is that the FOS Engine (software that runs on the target computer) connects back to the nfs share (on the fog server or synology nas) as user root. So when the nfs share is setup you will need to ensure that a user by the name of root can mount the share, this is typically done with a share level parameter of no-squash-root

@mashina Ok now for the hacky path.

You can view the menu program behind the fog ipxe menu by pointing your browser to http://<fog_server_ip>/fog/service/ipxe/boot.php in the following example I’m going to use 192.168.50.23 as the fog server’s IP address.

You will see that the text behind the fog server’s ipxe menu is akin to a computer program.

You will see the “Deploy Image” (old name is Quick Image or qi) menu where it calls the boot.php program once again but adds in the parameter qihost=1

So now if we call that url again with the new parameters http://192.168.50.23/fog/service/ipxe/boot.php?qihost=1&username=fog&password=yourpass note you will need to enter a valid user ID and Password for your fog server to get past this menu. So in this case there are 3 parameters that need to be passed (qihost, username, password).

At this next screen it will list out all of the images you have defined in fog with its image id.

Each section will look something similar to this

set imageID 1 params param mac0 ${net0/mac} param arch ${arch} param imageID ${imageID} param qihost 1 param username ${username} param password ${password} param sysuuid ${uuid} isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme

Now we add the imagid to the parameters list and call the boot.php program once again.

http://192.168.50.23/fog/service/ipxe/boot.php?qihost=1&username=fog&password=yourpass&menuAccess=1&imageID=1

That will produce this menu structure similar to what you are creating in your custom ipxe menu which is bootable via iPXE.

#!ipxe set fog-ip 192.168.50.23 set fog-webroot fog set boot-url http://${fog-ip}/${fog-webroot} set storage-ip 192.168.50.23 kernel bzImage loglevel=7 initrd=init_32.xz root=/dev/ram0 rw ramdisk_size=275000 web=http://192.168.50.23/fog/ consoleblank=0 rootfstype=ext4 nvme_core.default_ps_max_latency_us=0 mac= ftp=192.168.50.23 storage=192.168.50.23:/images/ storageip=192.168.50.23 osid=9 irqpoll chkdsk=0 img=Dell3630Base imgType=n imgPartitionType=all imgid=1 imgFormat=5 capone=1 type=down imgfetch init.xz boot

So this ipxe menu then will instruct the client to boot into imaging download mode.

Now to rewrite this into fog ipxe menu params block format

set imageID 1 params param mac0 ${net0/mac} param arch ${arch} param imageID ${imageID} param qihost 1 param username fog param password yourpass param sysuuid ${uuid} isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme

Now you can create multiple fog ipxe menus just use a different image ID for the image you want to deploy. You can see what these image IDs are from the FOG web UI when you look at the images in list form.