This would be a great feature to have, even if it were limited to only capturing to the image already assigned to the already registered host. It would be a good idea to have an extra confirmation message and invert the color scheme to make sure the user realizes what they’re about to do. However, deploying incorrectly can cause just as much damage as capturing incorrectly. FOG is a very sharp, double-edged tool.

Sometimes it’s a chore to go find another PC with network access so I can log in and set up the capture task or I’ll have to set up the capture task using the same PC before rebooting it. I can’t always carry my laptop with me and I don’t enjoy navigating any web interfaces on my phone.

@yeet said in UEFI and Legacy Bios coexistence with SonicWall DHCP:

Problem is we use our SonicWall for DHCP

Yes this can be a problem if your SonicWall doesn’t support dynamic boot options. The quickest and most direct route is to install dnsmasq on your FOG server to supply only the pxe boot information. Your sonicwall will supply all other dhcp settings except pxe booting.

I have a tutorial on how to add dnsmasq in about 10 minutes to your FOG server here:https://forums.fogproject.org/topic/12796/installing-dnsmasq-on-your-fog-server

If your pxe booting computers are on a different subnet than your fog server, you will need to update your dhc-relay/dhcp-helper service on your subnet router. Add the fog server as the last dhcp server in the helper service. Then everything will just work. If everyone is on the same subnet then just install dnsmasq and it will work.

Success! Dropped the files into /var/www and used set web-path to ${fog-ip}. In case anyone else has this issue this is my iPXE menu item parameters:
set tftp-path tftp://${fog-ip}/os
set web-path http://${fog-ip}
set pe-path ${web-path}/pm11_winpe
kernel ${tftp-path}/wimboot gui
imgfetch --name BCD ${pe-path}/BCD BCD
imgfetch --name boot.sdi ${pe-path}/boot.sdi boot.sdi
imgfetch --name bootmgr ${pe-path}/bootmgr bootmgr
imgfetch --name boot.wim ${pe-path}/boot.wim boot.wim
boot || goto MENU

@develroo I’ve had the FOG server running on raspberry pi 2 for quite a while. That is the 1.4.x series. For fog 1.5.x you should run that on a Pi3 or Pi4. The matter of fact, for fog imaging a Pi is more than enough for hosting the fog server. Now realize that the scope of service is for imaging a small number of system and no computers running the FOG client. The Pi4 is a bit more capable with 1GbE networking and USB3 for externally attached sata drives. The Pi 2 suffers with 100Mbs networking and USB2. The Pi3 has 1GbE networking and USB2.

For FOG imaging all the Pi needs to do is monitor the imaging process and move the image from local storage to the network adapter. The target computer does all of the heavy lifting. So the Pi3-4 is more than enough for acting as a limited or mobile FOG server.

@george1421

Good to know. I’ve been rolling with the same script since Win7 and likely would not have looked at another way to do it short of it failing to run on a new version.

@danieln I just realized that the persistent group plugin is not very well documented. It is covered a bit here: https://forums.fogproject.org/topic/8836/basic-persistent-groups-and-1-3-0rc16

The executive summary is

Add the Persistent group plugin Manually create a new host with a unique name that signifies it is a template host. Associate all of the snapins and what not that you want consistent for every host added to the group. Create a new Group that is exactly the same name as the template host. Now add hosts to this group (you can do this when you are registering the new computer with FOG too).

The settings will be copied over from the template host to the new host.

The workaround is just a patch file that needs to be replace on the FOG server. Replace this file BEFORE you install the plugin. If the plugin is installed before you add the patch file, uninstall the plugin then add it back.

We are discussing the discovered bug here: https://forums.fogproject.org/topic/15084/persistent-groups-snapins-added-to-host-but-not-deployed

The thread also has the temporary patch file link.

It works great !

Thanks a lot !

With apologies for the necropost, I’m looking at exactly this question at the moment. My thinking is you could possibly pair FOG with Relax-and-Recover or SystemImager for a complete backup/image/bare metal restore solution.

Looks like you would be able to add a Relax-and-Recover (ReaR) menu item to FOG’s menu for a full network-based restore, in the event of disaster. Since FOG can be used as a scheduler and general-purpose task executer, it is entirely possible to run one of these open source “live backup” solutions alongside FOG - i.e. on the same server.

I also note that ReaR can deal with UEFI/MD RAID situations, which seems to be a rare gift. 🙂

@george1421 Done. 👍

@boriquaboy115 FOG is an opensource project. AFAIK there is no physical location where The FOG Project exists. One of the developers might know for tax reasons if there is a specific mailing address.

As I said, The FOG Project is an opensource project with developers around the world. The senior developer that approves releases is based in the USA.

If you need this information for federal regulatory submission reasons, you may have a hard time getting opensource software approved for use.

@noithatgooccho There are different ways of getting what you are calling a “local cache”. Though the solutions have different restrictions or requirements.

Install a normal FOG master node in that location (no connection to the other server), register all your local hosts in that new server (it’s own database), create image definitions and manually copy the image files over to that server. Every time the image on the pre-existing FOG server is changed you need to manually copy the image over again. But local hosts can also capture an image to that new FOG server in that location.

Install a FOG storage node in that location - which needs to be able to constantly contact your pre-existing FOG master node to query information from the central database. The image files will be replicated from the pre-existing master node to the new storage node once (every time the image changes) - no manual copying needed. The hosts in that location can pull (deploy) an image from that new storage node (local cache) in unicast mode. But be aware that hosts in that location can only upload/capture an image to the pre-existing master node, not to the local storage node.

So it depends on what you want to achieve.

@seppim said in Ubuntu 20.04 Desktop live:

http://archive.ubuntu.com/ubuntu/dists/eoan/main/installer-amd64/current/images/netboot/netboot.tar.gz

Thank you Ubuntu… Try this link: http://archive.ubuntu.com/ubuntu/dists/focal/main/installer-amd64/current/legacy-images/netboot/

Ubuntu 19.10 has been removed from existence so the previous links are now broken.

@sebastian-roth Hi Sebastian,

thank you!

Well, the 3 partitions are because of the Ubuntu software Raid.

I need the Raid to prevent system halt, because the server is not local monitoring. so no one will check if the HDD goes failed.

I finish my setup and try to capture … as long he copy 1:1 the HDD for the backup its fine

@sebastian-roth

I wish you and your familie a happy and healthy new year.

I wanted to say thank you for your time.

best regards

Enrico

@tom-elliott Thanks very much!! That fixed it!

I found the path to the password to that user from another post I’ll copy here in case someone else runs into this problem.

Find the database information in /var/www/html/fog/lib/fog/config.class.php - with FOG 1.5.9 the database user is called fogmaster instead of root that was used in earlier versions.

@matthew73 This is a unique condition. I can understand what is going on because we use NAC and VLAN switching on my campus. I can say that I have not seen this issue (anywhere) on my campus.

I think I understand what needs to happen. Basically iPXE needs to say something and then wait XX seconds for your NAC system to identify the hardware and to switch it to the right vlan. The network link light winking happens 2 times during a normal pxe booting. The first time is when the PXE turns over control of the network adapter to iPXE and then when iPXE turns over control of the network adapter to FOS Linux. We see a similar issue when the network switches are using standard spanning tree and not one of the fast protocols (RSTP,MSTP, port-fast).

The developers have created a specific group of iPXE boot loaders that have an embedded 10 second delay before iPXE tries to request an IP address. This gives STP and powersaver functions on the switch a chance to react before iPXE starts to talk. These files are in the 10secdelay folder. So to use these update dhcp option from ipxe.efi to 10secdelay/ipxe.efi This will call in the 10 second delay boot loader. See if that makes things better or not.

I’ve added some more steps that should avoid those errors.

I’ve updated the chown command in the wiki. The user fogproject is something that came about after this article was written. The user used to be just fog

@george1421

Hi George,

That’s exactly what im looking for! Thanks, this would work for me. When we get hardware on our departmend i connect always mostley one kind of machine, so that works for me.

thank you for your great help and quik respons. Im gonna build further with this in a few weeks, and now it is a lot easier.

gr

Paul

@kdmiller45 The fog-client software will do the activation for you if it’s all setup correctly.

@george1421 Great, thank you for the quick response.