Configuring a standalone FOG VM under Ubuntu 20.04

by Dan MacDonald

FOG (Free Open Ghost) makes it quick and easy to deploy Windows, Linux or macOS images over a wired network using iPXE, partclone, apache and other open source software under the hood. The aim of this guide is to set up a FOG server running in a Ubuntu Server 20.04 VM hosted by qemu running on Ubuntu 20.04. I use virt-manager to simplify the process of creating and managing the VM.

This server will be running its own DHCP and DNS servers so that all you will need is your FOG VM, a switch and some ethernet cables to image machines. FOG and its required services (like DHCP and DNS servers) are things I don’t usually want to be running on my laptop or workstation which is why it’s useful to have FOG running inside of a VM so you can quickly fire it up as and when it’s needed.

User groups for virt-manager

If you want to run virt-manager as a normal user, make sure your user is in both the kvm and libvirt groups. Remember you need to log out and back in after adding your user to a group before it takes effect.

Create bridge interface on host machine

When you install virt-manager a virbr0 network bridge is created but this doesn’t work to host a FOG server. Instead we need to create a bridge interface, br0, by editing /etc/netplan/01-network-manager-all.yaml to look like this:

network:
  version: 2
  renderer: networkd

  ethernets:
    enp0s31f6:
      dhcp4: false
      dhcp6: false

  bridges:
    br0:
      interfaces: [enp0s31f6]
      addresses: [192.168.0.33/24]
      gateway4: 192.168.0.1
      mtu: 1500
      nameservers:
        addresses: [1.1.1.1]
      parameters:
        stp: true
        forward-delay: 4
      dhcp4: no
      dhcp6: no

Make sure you at least modify enp0s31f6 above to match the wired interface name on your host machine - run ip l to list your network interfaces. You will need to reboot for the new network config to take effect.

Note that using this netplan config will switch your Ubuntu box from using NetworkManager to using networkd, which is part of systemd. Whilst this will get FOG working, it also has the effect of breaking the network applets used by most Linux desktops because they nearly all use NM behind the scenes.

It is possible to configure netplan to connect to wifi when using systemd but its not as simple as when using the NM applet. It is also possible to connect to wifi using wpasupplicant and wpa_gui whilst using networkd but I have not tested those with networkd yet. I’ll only be using the above networkd bridge config on my laptop when using FOG and use default Ubuntu NM config the rest of the time for easier wifi access.

Create a FOG VM

Download the Ubuntu Server 20.04 install image. Ubuntu 20.04 has the advantage over Debian 10 or RHEL 8 in that its kernel and qemu packages are recent enough to enable you to use Virtio-FS to share the hosts disk with the VM if your host supports NUMA. It is still possible to use Virtio-FS without NUMA but that requires qemu 5.x and Ubuntu 20.04 ships qemu 4.2.

When creating the FOG VM in virt-manager, I assigned it 4 GB RAM and 4 VCPUs. You could get away with as little as 512 MB RAM, 1 VCPU and a 4 GB disk for your FOG VM and it should still run, if you don’t install any other software and you have the /images directory hosted elsewhere but generally you will want to make the VM disk as large as possible. You can easily use 200 GB imaging a modern Windows 10 box with a few big apps installed. On the last step of creating a new VM in virt-manager, for the Network selection I chose the option “Bridge br0: Host device enp0s31f6”.

I find it easier to configure a static IP using the Ubuntu server installer so choose the Manual network configuration. For your FOG servers subnet you will likely want to use something like 192.168.0.0/24. I used 192.168.0.44 for the address, 1.1.1.1 for the nameserver and my gateway is 192.168.0.1. If you skipped the manual network config screen of the Ubuntu Server installer, you can alternately edit /etc/netplan/00-installer-config.yaml to look like this:

network:
  ethernets:
    enp1s0:
      addresses:
      - 192.168.0.44/24
      gateway4: 192.168.0.1
      nameservers:
        addresses:
        - 1.1.1.1
  version: 2

I used the Ubuntu server guided disk defaults, using the whole disk. It’s debatable how much use LVM is when used in VMs, its much easier to resize disks without it but its the default in Ubuntu server.

On the Ubuntu server Profile Setup page, enter fog-server for the server name. Install the SSH server but don’t install any of the server snaps and cancel the updates at the end, we’ll update after booting into our newly installed VM.

FOG VM configuration

Reboot and login to your FOG server VM. Ubuntu server installs extra packages we don’t need so lets update then get rid of them:

$ sudo apt update && sudo apt upgrade
$ sudo apt remove bcache-tools btrfs-progs cloud-guest-utils cloud-initramfs-copymods cloud-initramfs-dyn-netconf xfsprogs lxd-agent-loader open-iscsi open-vm-tools
$ sudo apt autoremove

Then we’ll download and extract the latest FOG release:

$ wget https://github.com/FOGProject/fogproject/archive/1.5.9.tar.gz
$ tar xvf 1.5.9.tar.gz

This is a good point to create a snapshot of your VM should you mess any of the following steps up and need to start over.

Running installfog.sh

$ sudo ~/fogproject-1.5.9/bin/installfog.sh

Then choose:

Option 2 for Ubuntu packages
N for Normal installation
Don’t change the default network interface
Say Yes to setting up a router address for the DHCP server then enter your gateway (‘router’ - in my case its 192.168.0.1)
Say Yes to DHCP to handle DNS
For What DNS address should DHCP allow? Accept the default
Say Yes to Would you like to use the FOG server for DHCP service?
Say no to the language packs unless you want them
Say no to enabling HTTPS unless you want to configure that. I’m not covering that here.
Don’t change the hostname if already set to fog-server

The script will then download, install and configure the required packages. You will be required to click on a link or two to finish setting up the FOG database midway through the install script. Once the FOG install script has finished you can detach the host from the internet but still use FOG when its VM is running.

@george1421

Thanks George!

I had seen people talking about updating the kernel on here but I presumed they meant the FOG server kernel but now I realise that the FOG kernel is distinct from the kernel used by the FOG server. After updating the FOG kernel via the web UI FOG seems to be working on our new machines.

Does FOG currently offer any support for restoring images onto specific disks when the target machine(s) have two or more internal (SATA/NVME) disks?

I think at the moment the user would have to disable or remove all of the drives from the machines being imaged with FOG except the disk they want the image to be restored to right? If they wanted to restore to the second or third disk.

The way I’d like to see this work is there would be a way to enter a preferred device name for the target disk or optionally the user would get presented with a list of disks on each machine before the restore starts so that the user would have to manually pick the disk they wish to restore the image to.

Thanks

PS I’ve got FOG running great on a £30 X96 Air TV box running Armbian with gigabit ethernet and a nippy internal eMMC disk etc that fits in your pocket. Its very cool!

Oh so you can already configure the udpcast max wait in the current stable release? That’s good news. I have closed my github ticket because it focused on adding the max wait timeout. I’m happy enough with it being a global setting, I don’t need to change it per task.

I didn’t know to look for this setting until raising this problem here. I have mostly stuck to FOGs presets every time I’ve used it up until now, I just up the max number of clients, update the FOG kernel and tweak the DHCP config if required.

There doesn’t seem to be a guide to setting up multicast tasks in the official docs? Am I missing it? If there is such a guide it should mention adjusting this setting to suit your situation first.

I have created a gh ticket for this feature request:

https://github.com/FOGProject/fogproject/issues/496

Thinking about it, if you’re manually booting 50/60 machines all with passwords, I think 20 minutes is cutting it a bit fine. 30 minutes seems much more doable for that size of task so I think I’d prefer to use a 1800 second timeout as default.

@george1421

Hi George

I would say 20 minutes / 1200 seconds would make a good default timeout, if you have a lab of 50 machines that don’t support WoL and you have to manually PXE boot every one and enter a BIOS password to use the boot menu. Notice I say default because I’d prefer that the timeout was configurable when you create the multicast task.

As you say, it would be best if those machines that don’t make the timeout would shut themselves down rather than reboot because this works out for the best if you are using WoL.

Do you want me to open a github ticket for this?

@george1421

Yes, being able to start multicast tasks with a timeout would do the trick. I’m surprised FOGs lack of support for a receive timeout hasn’t been raised until now.

@sebastian-roth

I woke up thinking about this today and I know one potential way we could mostly fix this problem.

If a big FOG multicast task fails then, unless the user has AMT or whatever the AMD equivalent of that might be, they have to manually turn off many computers before they can start the next FOG task. Therefore it would be handy if there was a way to shutdown FOG clients that have booted and started partclone so that they can be remotely powered down by just ticking a checkbox next to that machine in the FOG web UI’s task list then choosing a ‘Shutdown selected hosts’ option.

This feature would ideally work with Intel, AMD and ARM based clients so it wouldn’t rely upon Intel-specific AMT for example. It would use a FOG client service to perform the shutdown. It’s not quite a full fix for my original stated problem but it would mostly heal the pain of dealing with large failed FOG multicast tasks in a way that fits the current workflow. Does this sound viable?

I’ve had it happen a couple of times this week where I’ve started a FOG multicast task with up to 50 machines and then I won’t be able to get one or two machines to boot into FOG (or, as happened earlier, one machine started writing the image early for some unknown reason) and then I’ve been forced to stop all of the tasks and start over, rebooting all of the machines etc because FOG is waiting on one or two last machines to appear before it will start the multicast.

I have tried to cancel/remove individual machines from a multicast task but it seems to stop/remove all of the existing tasks. Is there a way to fix this situation and to get FOG to start a multicast task without cancelling all of the tasks and starting over?

I also seem to be having an issue with machines not changing their hostname to match what they’re known as to the FOG server. We’re using Windows 10 on the clients. I’ve installed the FOG client, set the address of the FOG server for the client and it has worked for most of the machines but not all. They’re all on the same network / switch but there are two types of PC with different network adapters if that could make a difference?

Oops!

Turns out I can delete groups OK. I suspect what was going on is I’d had a long and stressful day and the password it was autofilling that I was mindlessly accepting was wrong. Today I manually typed the password of the FOG user and it worked.

Please excuse my noise!

I’m running the latest git version of FOG with the latest FOG kernel (5.15) under Ubuntu 20.04 and I’m unable to delete FOG groups with its web UI. When I try, it prompts me for a username and password. I enter my fog user credentials (which are the same as Linux users, so there’s only one set of responses here) but then it fails to delete the group(s).

I did end up re-installing FOG on this machine because I wanted to try using a different IP/subnet than the one I used at first. I tried to fully remove my old old FOG install by dropping its DB, removing /opt/fog etc but maybe this error is caused by me re-installing FOG and not doing the best job of uninstalling it first? It seems to be working fine apart from not being able to delete groups.

I’m sure I’ve not had this problem with FOG before. Hopefully someone knows how to fix it without a complete re-install of the OS and FOG?