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

@tadziuuu Just to be clear on a few points.

The .iso / memdisk route only works for bios based computers. This will not work for uefi based computers.

With the .iso image files and the parameter block I previously provided, you get the error message about initramfs? If yes, then I suspect the fetch command is not downloading the squashfs filesystem. I copied that command over from your initial parameter block. It looks like we need to focus on that bit then.

@jfernandz said in FOG and Secure Boot:

The problem is apparently I have to sign also the refind_x64.efi binary, not sure if refind.efi is actually loading refind_x64.efi … but I’d suggest also to include this point in your tutorial. In fact I’m guessing you should also sign refind_ia32.efi and refind_aa64.efi as your whole environment could include also another archs.

You are correct I really missed the refind files. I will update that info too. While I had 1.6k viewers of the file not many people have returned comments. I have that turned off in the tutorial because it makes the multipart tutorial a bit messy because of the way the forum works.

I think the signing process (with sbsign) may be automated in a bash script

Towards the bottom of the document there is a bash script easter egg. I initially wrote the bash script then broke it up to explain what each part did. For those that never made it to the bottom of the post, they missed out on the bash script. I intentionally did it that way so people knew how it worked before they simply cut and pasted the script.

@professorb24 I’m really not understanding what the issue is.

Are you asking “How do you deploy an image?”

if that’s the case, you’re not using the GUI?

I don’t fully understand what you’re asking here.

Well, first of all … I’m sorry for getting up this old post.

Secondly … I’ve been reading some posts on this forum … and I’ve found this one which I think it’s very interesting to be linked in here (not sure if you’ve linked it yet, but I’d say I can’t see the link anywhere).

After researching a little bit more about this topic … I’ve found this project … which not sure if it could be interesting also. What do you think? Could this make easier the process described in @george1421’s tutorial?

Thank you guys, and so sorry again because I’ve created a new topic instead replying in here 😞 maybe some mod can remove it 😄

@flight What manager are you talking about?

Fog isn’t a “package” for Yum/Apt like other packages.

You need to locate where the installer resides for your environment and update that information, or download/extract to another location and install from that location.

https://wiki.fogproject.org/wiki/index.php?title=Getting_FOG

@Kram-Man Is your main ipxe server running ipxe as the bootloader or syslinux? If its truely iPXE then on the FOG server, in the tftpboot directory there is a file called default.ipxe At the bottom of that is a chain load command or chain load the default.ipxe You can look at this line on github. https://github.com/FOGProject/fogproject/blob/a4bb1bf39ac53c3cbe623576915fbc3b5c80a00f/src/ipxe/src/ipxescript#L32 Just replace ${next-server} with the IP address of your fog server.

@JJ-Fullmer Thank you for the info this worked for me.

@Tom-Elliott said in Update to Ubuntu 23.10 arise Kernel Panic on Fog 1.5.10 with Kernel 6.1.22:

@herman This must’ve been changed by someone else at somepoint. Glad you found it and returned here. It seems you were missing the file entirely so that explains the kernel panic.

@Tom-Elliott Thanks man.

@Alan-Lim Just deploy the snapin task