First of all its not the best place to put the recovery partition at the beginning of the disk. The MS recommends the efi partition be on disk 1 partition 1. It has been that way for years. Also I would question the logic of needing a recovery partition at all. With FOG its much faster to rebuilt the system then to try to recover it. I understand (as someone recently pointed out) that if the computer is at a remote location to the FOG server then the only option is to try to recover it. On my campus I don’t use/create the recovery partition at all. I do use MDT to build the golden image, with MDT I can chose how to create the disk layout for both bios and uefi systems. If I had a choice I would place the recovery partition before the drive partition, that would make the biggest resizable partition last on the disk where it can be easily resized.

GParted 0.33.0 x86

1. First we’ll create the required directories:

mkdir -p /tftpboot/gparted
mkdir -p /tmp/gparted

2. Download the gparted zip file from sourceforge site and save it to the /tmp/gparted directory
3. Change to the /tmp/gparted directory and expand the zip file. Then change into the live directory and finally copy the required files to the tftpboot/gparted directory

cd /tmp/gparted
unzip gparted-live-0.33.0-2-i686.zip
cd live
cp {vmlinuz,initrd.img,filesystem.squashfs} /tftpboot/gparted

4. In the fog WebGUI go to FOG Configuration->iPXE New Menu Entry
   Set the following fields
   Menu Item: os.GParted
   Description: GParted 0.33.0
   Parameters:
   kernel tftp://${fog-ip}/gparted/vmlinuz
   initrd tftp://${fog-ip}/gparted/initrd.img
   imgargs vmlinuz initrd=initrd.img boot=live config components union=overlay username=user noswap noeject ip= vga=788 fetch=tftp://${fog-ip}/gparted/filesystem.squashfs
   boot || goto MENU

Menu Show with: All Hosts
5. That’s it, just pxe boot your target system and pick GParted 0.33.0 from the FOG iPXE boot menu.

References:
https://gparted.org/livepxe.php

@jahilton2002 Partclone is the default for FOG 1.2.0 and later. Partimage is left in the configuration for legacy images so they will deploy correctly with newer releases of FOG.

The next question you might ask is zstd or gzip compression. By default gzip is selected since it has been part of fog imaging for many years. The new compression technology is zstd. zstd is known for having a fast decompression speed as compared to gzip. zstd also creates smaller image files on the fog server. The only down side(s) to fog using zstd:

1. zstd is a newer compression format than traditional gzip compression.
2. It takes longer to compress the image with zstd than with gzip, but decompression times more than make up for the slower compression times (consider you typically capture once and deploy many times).

So what should you pick? partclone with zstd with compression ratio 11.

Also there are 2 bugs in FOG 1.5.4 that have been patched in the 1.5.5 beta release that have not been back ported to 1.5.4.

1. Roll the FOS kernels back to 4.15.2 (done in fog setup->kernels). Download both the 64 bit (bzImage) and 32 bit (bzImage32) x86 images. This will fix the 3-5 delay (in some cases) creating the partition table (this issue is being actively worked on by the developers)
2. If you run into an imaging issue with out of memory condition (under rare circumstances) there is another fix that I can tell you about if you run into it.

@technicaltroll So what is partition #4. Is it was would be the C drive?

If yes, windows some does things a bit problematic in that it will encrypt free/unused space on a drive where bitlocker is not enabled.

From an elevated windows cmd prompt key in

manage-bde -off C:

manage-bde -status C:

and confirm that bitlocker has been disabled.

@danboid First of all let me say great job documenting the installation process on a current (at the time of writing) OS.

I do have a few comments

1. For new FOG Admins it may be a bit confusing why you are doing the virt-manager stuff. I fully understand why but its not clear in your documentation. And if the read doesn’t want to setup a containerized VM that they can just skip to the part of installing FOG. That part is great for both virtualized and physical fog server (minus a few of the VM container bits). Or you need to make it clear in the beginning that you are setting up a containerized VM using ubuntu and on that host (hypervisor so to speak) you will be installing FOG on a VM using that host. I guess my point is if the FOG admin that is following your guide is only copy and pasting they won’t know why and if it breaks they won’t know how to fix it.

2. While the tar method to install FOG is OK, I would recommend using the git method because updates can be quickly downloaded and installed with just a few commands. Its really a toss up to which method to use tarball vs git pull but there are options here.

3. On the fog vCPUs, that number is really dependent on the number of computers that have the fog client installed. 2 vCPUs should be sufficient for most SMB installations with 300 or less fog clients in play. The FOG Server for itself for imaging doesn’t need a lot of vCPUs. I even have FOG server running and deploying on a Raspberry Pi3 server. For the server’s standpoint the critical path is between disk and network. The fog server really doesn’t do number crunching during imaging.

4. When setting up the fog server its best to move the /images onto its own partition. That way when the /images partition fills up it doesn’t bring down the FOG Server. On centos (I realize you are talking ubuntu here) it will allocate 50GB for the root directory and then give /home the rest of the disk on its own partition. Again for centos I will rename /home to /images when installing centos so that all of the free disk space beyond 50GB is allocated to /images. Even better for a VM is to place /images on its own disk using a standard partition (not LVM) then you can extend the vm disk and then the partitions to make more room for images.

Overall your write up is very nicely organized and pretty clear for the beginner fog admin. Well done!

@sudburr Ah, just for clarity your fog server is 1.4.4? If so you need to fix a few things since the instructions build a 1.5.4 compatible FOS environment.

The solution is pretty easy, just copy from /var/ww/html/fog/service/ipxe the following files to the /boot directory (I think, check to see where they are on the flash drive) replacing…

bzImage32
bzImage
init.xz (probably the root of your error)
init_32.xz

The inits where changed between 1.4.4 and 1.5.1 which is probably causing your error. The FOG USB was developed using FOG 1.4.4 so it should work.

@azer Yes this is a problem with iPXE not FOS Linux “the kernel”. But with the E14 both @Larmurier1383 and @maxcarpone are right. You need to rebuild iPXE to get the latest hardware support as well as when you start imaging you will need the 5.15.x version of the FOS Linux kernel.

The simple rule is if you can’t get to the FOG iPXE menu then the problem is in iPXE (unidonly,kpxe or ipxe.efi). If you can get to the FOG iPXE menu but you get an error after you pick a menu item then the issue is in FOS Linux kernel (bzImage).

Well let me see if I understand this. Your fog server was running in vmware (ESXi ??) and you were getting 9GB/m. This is a reasonable results from FOG running under vsphere where the vmware server is running across a 10GbE network and a recent (current) target computer is connected via a 1GbE network connection. In my environment I get about 12GB/m transfer.

FWIW on a pure 1GbE FOG infrastructure I would expect to see about 6.1GB/m transfer rates on a well designed network.

Now you have moved your FOG server to virtualbox and you see 3GB/m transfer rates? Do I understand that correctly?

If so, I can understand why. ESXi is a type 1 hypervisor (i.e. the hypervisor runs directly on the hardware) and virtualbox is a type 2 hypervisor (i.e. the hypervisor runs on top of a guest operating system). FOG has to complete with the host OS running the hypervisor for system resources.

Also that CPU is a 4 core 4 thread processor. If you are only running 1 vm client on that server then you are probably OK granting the vm client computer 4 vCPUs, but you could end up with resource contention if that virtualbox server is loaded. The FOG server itself doesn’t really work hard or require much CPU. In the deployment process the FOG server manages the deployment and copies the files from the local hard drive and sends them out the network adapter. The taret computer does all of the heavy lifting of image deployment.

Zstd will give you a better deployment time than gzip, at the cost of increased capture time. But given that you typically capture once per image and deploy many times. An ideal compression for zstd is 11. You can go higher or lower. A compression of 0 “should” give you a faster write speeds on the target computer at the penalty of image size on the server and network load. Remember, if you are changing compression protocols or compression ratios, that must be done before you capture the image. You can change these setting post capture, but they will not have any impact on the image already captured or deploying the current image.

The numbers you see in partclone as its running (3GB/m) is actually a composite speed. Its the combination of disk reads on the server, nfs protocol, tcpip data stream, gzip or zstd file expansion on the target computer and write speed to the target computer’s hard drive. Its an end to end transfer speed, not specifically related to network performance (but network performance is a part of the total).

@jamie002 First let me say I haven’t tried to deploy windows 11 or even develop a golden image for it as of now. My job has taken me in a different direction. So what I will say is based on windows 10 golden image development.

1. Bluescreen: There are a number of causes for this. It could be drivers, hardware changes, disk structure, not being properly sysprep’d/power off correctly before imaging. More on this in a bit.

2. SID. The SIDs are a software thing. Having different images for different machines is a hardware issue (kind of). I can tell you on my campus we deploy to 13 different models of computers with the same golden image. The key to doing this is syspreping the computer and either injecting the correct drivers for the hardware or preinstalling the needed drivers in the golden image before image capture. We do the first option of injecting the drivers just after FOG imaging but before the first boot of the target computer.

3. Template: Use a virtual machine to create your golden image. Take a snapshot of the computer before sysprep and image capture, then restore the snapshot (basically undoing what sysprep did so you can make other changes to the system) On the next update repeat the process of snapshot, sysprep, image capture, reset the snapshot. In our case we use Microsoft’s MDT to consistently build our golden image the same way on each time we create a new golden image. We still create it on a VM, but don’t need to manage snapshots. The Windows build is a FAT image in that all of the common applications are already installed in the golden image and only departmental software is installed post deployment. The other option is a thin Windows build where only the OS and updates are installed and all applications are installed post deployment.

4. Imaging hundreds of computers. It is surely possible with FOG. You will spend the most time perfecting your golden image which will be outside of FOG scope. On a well managed 1GbE network with contemporary computers we can push out a 25GB mother image in under 4 minutes to a target computer. Then upon reboot WinSetup and OOBE takes over to complete the workstation setup. With a well managed network with a 10GbE core network a 25GB image push is just over 2 minutes to push the image.

Recommendations.

1. Build your golden image on a VM for a few reasons. a) Its a hardware independent build. This way you won’t install unnecessary drivers in your golden image. You will have the snapshot capabilities (you will probably need that during the actual building of your golden image if you are doing it manually). I’ve more than once made a mistake where I had to role the machine back to the last snapshot. The alternative is to rebuild the golden image from start. \

2. For the hard drive on the VM use around 100GB or the smallest size you “need” to contain your image. With FOG imaging its easier to expand a 100GB hard drive to a larger one than to shrink a 500GB disk image onto a computer with a 127GB hard drive. Save your self some aggravation use the smallest disk size that will contain your image. If you use FOG’s single disk resizable it will only capture your data so the actual size on the FOG server will be only the data, not the size of the disk.

3. Sysprep your golden image before image capture. Use the proper sysprep commands to power off the computer after sysprep is done. This will close all of the files properly for disk image capture. Normal windows shutdown will leave open files and cause an error during image capture. Google “microsoft windows dirty bit” to learn more.

4. Configure FOG to deploy the machine specific drives to the target computer during imaging.

5. Use Microsoft Volume Licensed media so you can get a VLK key. You only need one license key if you are deploying the same Windows version that is on the target computer. For example if your computers came with windows 10 pro OEM and you have 1000 of them. You can purchase 1 windows 10 pro vlk license key for all 1000 computers. What you can’t do is upgrade software versions with that one vlk key. So if your computers come predeployed wiht windows 10 oem you can’t upgrade to windows 11 with this vlk key, you need to purchase an upgrade license key.

6. Try to limit the number of different hardware models you have on your campus. Or at the bare minimum stick to one vendor (i.e. Dell, HP, Lenovo, etc). Trying to manage hardware drivers for 7 different vendors, on 20 different models of computers would be a nightmare.

7. Use FOG Post install scripts to adjust deploy time settings to the target computers. For example in our case we don’t have FOG connect the target computer to AD, but we let windows sysprep do it. We have a post install script (which runs after the image is deployed to the computer but before the first OS boot) update the unattend.xml script with deployment time settings like computer name (calculated based on install site, hardware type, computer asset tag), target OU based on install site, hardware type (laptop/desktop), image name deployed. These are all deploy time values that aren’t know ahead of time. This also helps us keep “one image for all” mentality.

Ok after a lengthy discussion in chat we have a working solution with the updated bzImageVLAN and the patched vlinit.xz files. Since ipxe WAS getting an ip address in this configuration we could avoid all of the syslinux configuration stuff and just go into FOG and update the kernel and init with the new names, then under kernel args add in vlan=2223. The OP setup a debug task on the FOG server and pxe booted into FOS. FOS picked up the right IP address on the vlan and we are golden. The OP was going to try to image using this setup, but since FOS got the right IP address the reset should be just normal fog stuff.

@Developers While this is a fringe (one-off) case, I don’t see any real value in integrating it into the FOG kernels, but I’ll document it here.

1. I added the vlan support by Networking support->Networking options-> 802.1Q/802.1ad VLAN Support then recompiled the kernel.
2. I unpacked the current inits with the guidance from here: https://wiki.fogproject.org/wiki/index.php/Modifying_the_Init_Image
3. I updated the /etc/init.d/S40network startup script by adding

# At the top
. /usr/share/fog/lib/funcs.sh
vlid="$vlan"

#then in the ifaces loop
    echo "Starting $iface interface and waiting for the link to come up"

    if [ -z "$vlid" ]; then
        echo -e "auto $iface\niface $iface inet dhcp\n\n" >> /etc/network/interfaces
    else
        echo -e "auto $iface\niface $iface inet manual\n\n" >> /etc/network/interfaces
        echo -e "auto $iface.$vlid\niface $iface.$vlid inet dhcp\n    vlan-raw-device $iface\n\n" >> /etc/network/interfaces
        echo "Waiting for physical adapter to be ready"
        /sbin/ip link set $iface up
        sleep 10
        echo "Assigning vlan $vlid to interface $iface"
        vconfig add $iface $vlid
        iface="$iface.$vlid"
    fi
    echo "Brining up network interface $iface"
    /sbin/ip link set $iface up

    # Wait till the interface is fully up and ready (spanning tree)

4. Then I repacked the inits and sent them with the bzImageVLAN kernel to the OP for testing.

With this method I added a new kernel parameter called vlan which sets the proper vlan and brings up that interface. The only caveat with this code is that if there are multiple interfaces that defined VLAN will be created on each interface until it finds one that works.

Here is the patched S40network startup script.
S40network.txt

My guess is what you really want to do boot a linux live image in a pxe boot environment.

First let me say that fog is not intended to be used in this manner. And what you are doing is not supported by the FOG developers.

With that said you might want to look into live boot options here http://cdimage.ubuntu.com/netboot/ If you are using the trunk build or 1.3.0-rc1 of FOG you should be able to do this since the trunk build allows you to add custom iPXE boot menu options right from in the FOG management gui.

If you grabbed the latest kernel and inits you will need to make a modification to the grub.conf file.

You need to up the kernel parameter for virtual memory from 127000 to 275000

ramdisk_size=127000 would become ramdisk_size=275000

i.e. where:

menuentry "1. FOG Image Deploy/Capture" {
 echo loading the kernel
 linux  $myimage loglevel=$myloglevel initrd=init.xz root=/dev/ram0 rw ramdisk_size=127000 keymap= web=$myfogip/fog/ boottype=usb consoleblank=0 rootfstype=ext4
 echo loading the virtual hard drive
 initrd $myinits
 echo booting kernel...
}

would become

menuentry "1. FOG Image Deploy/Capture" {
 echo loading the kernel
 linux  $myimage loglevel=$myloglevel initrd=init.xz root=/dev/ram0 rw ramdisk_size=275000 keymap= web=$myfogip/fog/ boottype=usb consoleblank=0 rootfstype=ext4
 echo loading the virtual hard drive
 initrd $myinits
 echo booting kernel...
}

You need to change it in all spots

I guess the first thing is we need to collect a bit of information before we can begin to help you.

1. What version of FOG are you using?
2. What target OS are you deploying that is stating boot error?
3. What does the partition table look like for this linux host (are you using LVM or native partitions?)
4. As for thinstation (I know of this and use it) are you trying to deploy the devstation or the compiled target OS? (we use a micro usb flash drive and don’t mess with any local hard drive, we also pxe boot some thinstation computers and that works really well too).

[edit] having a screen shot of the exact error would also be helpful to see what is going on.

How about something like this

mkdir /ntfs
ntfs-3g -o force,rw $part /ntfs

where you will replace $part with the partition where the drive is. $part needs to be expressed in /dev/ format. You can probably find that part by using lsblk to find the /dev/disk_part format

@dholtz-docbox said in DNSMasq Setup - No Boot Filename:

I was in sync with what you were saying until here

where DNS is handled by the route

I assume you meant that DHCP is now handled by your router.

If you are installing dnsmasq on your FOG server then all you need to do is install dnsmasq and ensure it starts upon reboot then update/create /etc/dnsmasq.d/ltsp.conf then restart dnsmasq. That is all.
As long as your dhcp server, fog server, and target computers are on the same subnet it will just work. If your target computers are on a different subnet than your dhcp server and FOG server then there are a few more things you need to do.

I do have a tutorial on how to set dnsmasq up under Centos with an example config file you can use.
https://forums.fogproject.org/topic/6376/install-dnsmasq-on-centos-7

As part of installing fog you should have already disabled the firewall on the fog server as well as set selinux to disable.

What I would recommend is you install your linux distribution on your new hardware. Make sure you manually provision the disk partitions and mount points to match what you have today to the old servers fstab structure. Once the new server’s OS is installed, fixed IP address is assigned, and all other FOG prerequisites are done, then do the following.

1. Download the current FOG program using the git method (hopefully your old fog server and new fog server are the same versions of FOG)
2. Run this command to make the FOG disk structure mkdir -p /opt/fog
3. On your old fog server there is a hidden file called /opt/fog/.fogsettings Copy that file from your old fog server to the new fog server in the same location. You can use the linux command scp to copy the file from the old server to the new server.
4. Run this command on the new fog server to look at your network settings ip addr show collect the network interface name and the IP address of the new fog server.
5. On the new FOG server edit the /opt/fog/.fogsettings file and update the network adapter name and IP address in that file and save it. This .fogsettings file contains all of the answers you answered the first time you installed fog on the old server. When we rerun the fog installer next it will not ask you in questions, but take the answers you provided the first time. This should make the new fog server the same configuration as the old fog server just running on new hardware.
6. Now change to the cloned git repository for FOG in the bin directory run ./installfog.sh to reinstall FOG. We are doing this to use the installer to install FOG and make sure the permissions are set correctly on all files it needs.

Now at this point you should have an old FOG server with all of the configurations and a new fog server (functional but not configured). The next steps are covered in the wiki to moving your fog server to a new host: https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG

When you are done you will have the old fog server and the new fog server. So you might ask why I took you this route. The simple answer its a bit more fool proof than the faster but more likely way of breaking your new server’s linux install if you make one mistake of copying partitions around.

A fog install has 3 components.

1. The FOG program code
2. The mysql database
3. The raw data files in /images directory.

This method takes you through rebuilding part 1, and then you can just copy the configuration and raw data files for parts 2 and 3.

And in the FWIW bucket.
That 790 is fast enough for a small SMB (< 50 workstations) environment as long as the /images directory are on an SSD drive. The OS can be hosted on a traditional HDD if needed. Where the 790 falls down is if you are using a traditional HDD for image storage. That traditional HDD is not fast enough to keep up with more than 2 simultaneous unicast images being send to the target computer. At the point of 3 simultaneous unicast images being transmitted you will run into issues with that single GbE network adapter (assuming you have the images on a SSD drive). But for a small SMB, how many times are you going to image 3 computers at the same time? Probably not very high. With image push time in the 4-6 minute range, just stagger the start times if you really NEED to image 3 computers at the same time.

@cpast The developers confirmed and fixed the issue and it was done in time to get into the RC15 release. If you have not done much configuration the easiest way to get this fog server back on track is to:

1. If you have any configurations you want to save make sure you export the settings.
2. Refresh the installer to RC15 (git pull or svn up )
3. Login to mysql using mysql -u root (provide a password if you gave root a password for mysql)
4. key in drop database fog; (understand when you do this your entire fog configuration will be gone, and then reset to default in step 6. Save what you need saved before you execute this command).
5. Key in exit
6. Run the installer again in the …/bin folder (this will install RC15 and rebuild the fog database)

@lebowski-0 said in I have the same problem with the last bzimage:

I’m having the same issues, FOG version 1.5.9.222, on Debian 11, bzImage Version: 5.15.68
bzImage32 Version: 5.15.68.

Some additional questions on this issue:

1. What mfg and model of computer is doing this?
2. Does the same thing happen on a second computer of the same model?
3. Does this problem happen on all models?
4. Is it repeatable, meaning does it happen every time on the same computer?
5. Does it fail in the same spot every time?
6. Did you create any custom post init scripts on the fog server?

I’m kind of leaning towards a memory fault here, but now that 3 people are seeing the same issue, we need a bit more info to correlate.

OR to translate what Tom said:

cd <place_where_to_save_installer_files>
git clone https://github.com/fogproject/fogproject.git
cd fogproject
git checkout dev-branch
cd bin
./installfog.sh -y

@gabrielzeit said in UEFI: NBP downloaded successfully - then blackscreen:

Sadly USB boot is not suitable for my use case

You are not getting to the FOG iPXE menu, this is an iPXE issue or as I mentioned before your pxe booting is getting hijacked by that WDS suspicious server. Your firmware doesn’t really indicate what is wrong, it just reboots. So that’s not really helpful in debugging.

You could load ipxe onto a usb stick (yes I know you said that USB wasn’t an option) to see if ipxe will boot from the usb drive for testing. If it does then you know the problem is somewhere along the pxe booting chain and not ipxe itself.

I don’t have the pcap anymore, but looking over the thread, I see this WDS server is responding with a bios boot file (wdsnbp.com) that, if sent to the uefi computer, would cause a uefi computer to download it and just reboot. I wanted to see if the DHCP DISCOVER from the client was saying it was a uefi computer, and then this rouge dhcp server was responding with a bios boot loader. That would be strange but also cause the symptoms.