Thanks Sebastian. I was able to get my local debian mirror setup and working. I had to pass a bunch of kernel options over to get things started. Here is my boot option.

:Debian95Full kernel http://${fog-ip}/bootimgs/debian/oldIso/install.amd/linux preseed/url=http://10.0.0.3/preseed.cfg ksdevice=bootif netcfg/link_wait_timeout=10 netcfg/dhcp_timeout=60 netcfg/choose_interface=auto auto-install/enable=true priority=critical hostname=unassigned-hostname domain=unassigned-domain console-setup/layoutcode=us console-setup/ask_detect=false locale=en_US ipv6.disable=1 initrd http://${fog-ip}/bootimgs/debian/oldIso/install.amd/initrd.gz boot || goto MENU

Also here is a good tutorial for having your own Debian repository mirror if anyone else stumbles upon this topic
https://www.tobanet.de/dokuwiki/debian:debmirror

We recently had an issue where the time zone wasn’t being set correctly/updating on imaged machines. We edited the registry with a script on those machines to set the correct time zone.

@nextechinc said in Booting System Rescue CD 5.2.2:

cpuid --ext 29 && set arch 64 || set arch 32
set path /netboot/systemrescuecd
set nfs_path /var/www/netboot/systemrescuecd
kernel http://${fog-ip}${path}/isolinux/rescue${arch} docache setkmap=us
initrd http://${fog-ip}${path}/isolinux/initram.igz
imgargs rescue${arch} initrd=initram.igz netboot=http://${fog-ip}${path}/sysrcd.dat setkmap=us dostartx
boot

Thank you so so much. I was struggling to get the SystemRescueCD to work at all, now it works 🙂

I think I used some tutorial on here or wiki somewhere and my paths were different, I had to use

path /srcd

And had to change the paths in kernel and initrd to

kernel http://${fog-ip}${path}/rescue${arch} docache setkmap=de

and

initrd http://${fog-ip}${path}/initram.igz

As well as imgargs to:

imgargs rescue${arch} initrd=initram.igz netboot=http://${fog-ip}${path}/sysrcd.dat setkmap=de dostartx

This may be my specific setup being somehow messed up, but in case somebody else has the same setup as I do …

I put in a shebang. It should work now, please re-download the install file.

@Vincent-Caraby Well lets see if I can explain this, but the answer is simple and complicated at the same time.

The FOS engine connects to the master node as root so the synology nas needs to allow root to connect to the /volume1/images and /volume1/images/dev as root.

Also the FOS engine will use ftp to connect to the NAS using the adminfog user and password you defined in the Storage Node configuration to move the files from /images/dev to /images directory.

@andrewg78 What I want you to do is start a new thread.

I want you to pxe boot the target computer using FOG 1.5.4 and the post a clear screen shot of the exact error. Lets work through why its not working on your hardware there.

@mpatel If you look towards the bottom of the thread the drivers on the fog server go into /images/drivers (you will need to create the drivers directory because its not fog standard.) Below is the basic structure of the directories needed.

/images ├─/drivers ├─Optiplex7040 ├─win7 └─x86 └─x64 ├─win10 └─x64 ├─Optiplex7050 ...

@mpatel It’ll work, but the capture will be really slow since it’s copying from & to the same physical disk. You’ll want to setup FOG with DHCP and you’ll want to use Bridged-mode for the NIC on both VMs. FOG requires internet connection to be installed. After installation, it does not need internet connection.

@quazz Okay, thanks for your help. You can mark this post as solved.

I took the initiative an I upgraded it to 1.5.4
By downloading the latest version from https://github.com/FOGProject/fogproject/archive/1.5.4.tar.gz

tar -xzvf 1.5.4.tar.gz
cd fogproject-1.5.4/bin
sudo ./installfog.sh

@gabriel-de-souza Very nice!. This question might show my ignorance of Docker, but how are you handling NFS port redirection? NFS is not a very “firewall” friendly protocol.

If you can successfully run FOG in a Docker, you could potentially run FOG under MS Windows in a Docker container.

Since you have a history with FOG in a docker container, what transfer rates are you able to achieve pushing an image to a target computer?

CentOS 7.4 and 7.5

Works with: UEFI or BIOS

To start we need the installation files in our /tftpboot/os/centos directory. This can be done by manually copying the required content from a CentOS iso or by using rsync to sync from an online mirror. A list of official mirrors with rsync links can be found here. The following will presume the latest version of CentOS (at this time 7.5.1804) but altering the version to your desired version in the steps should work.

You do not have to do the steps in BOTH “Using Files from ISO” and “From rsync”, its one or the other.

Using Files from ISO:

Create the directory for CentOS/version if it doesnt already exist: mkdir -p /tftpboot/os/centos/7.5.1804 Mount the ISO and copy the required files to the above directory: mount /{path to the iso}/filename.iso /mnt/iso/ cp -R /mnt/iso/* /tftpboot/os/centos/7.5.1804 umount /mnt/iso

Using rsync:

Do not create the subdirectory for the CentOS version, just have /tftpboot/os/centos ready, rsync will create the subdirectory.

run the rsync command using a rsync url from the list of mirrors you want to use. This can take hours to run:

rsync -avzP --log-file=/var/log/rsync_cron/rsync_yum_mirror.log --delete --include="/7.5.1804" --include="/7.5.1804/**" --exclude="*" rsync://mirrorurl/centos/7.5.1804/os/x86_64/ /tftpboot/os/centos

feel free to change the path/name of the log file. I use this rsync to also pull updates allowing me to use my FOG server as a local YUM repo as well. If interested in doing so change the rsync path to be rsync://mirrorurl/centos/ instead. This will make the amount of data downloaded much greater, but will later let you use the FOG server as a YUM repo. I placed the rsync command above in my crontab -e without the -P switch for rsync and have it sync once a day. Doing so is a bit beyond the context of this guide though.

Also note that if the mirror is down the command can fail, you may need to switch to another mirror or if setting up cron having it sync multiple mirrors just in case.

Adding iPXE entry:

From the FOG web GUI, create a new iPXE entry (or edit an existing one) as follows:

Menu Item: name as desired (ex: os.centoslatest) Description: as desired (ex: CentOS 7.5.1804 - Install). Note: This is what is seen in the iPXE menu on the host machine! Parameters:

Manual or rsync without wanting YUM server too:

kernel http://${fog-ip}/os/centos/7.5.1804/images/pxeboot/vmlinuz initrd http://${fog-ip}/os/centos/7.5.1804/images/pxeboot/initrd.img imgargs vmlinuz initrd=initrd.img root=live:http://${fog-ip}/os/centos/7.5.1804/LiveOS/squashfs.img repo=http://${fog-ip}/os/centos/7.5.1804 boot || goto MENU

With rsync pulling all data for YUM:

kernel http://${fog-ip}/os/centos/7.5.1804/os/x86_64/images/pxeboot/vmlinuz initrd http://${fog-ip}/os/centos/7.5.1804/os/x86_64/images/pxeboot/initrd.img imgargs vmlinuz initrd=initrd.img root=live:http://${fog-ip}/os/centos/7.5.1804/os/x86_64/LiveOS/squashfs.img repo=http://${fog-ip}/os/centos/7.5.1804/os/x86_64 boot || goto MENU Menu Show With: as desired. Save changes

Alternate directions here.

As an additional note: each label you use must be unique across all of your menu entries.

IE: If you make a menu entry for ESXi 6.5 and another for 6.7, then these lines:

iseq ${platform} efi && goto esxi_efi || goto esxi_bios :esxi_efi ... :esxi_bios ...

must have unique labels, for example esxi65_efi vs esxi67_efi instead of both having esxi_efi (or esxi_bios).

If you use the same label in 2 different menu entries than iPXE will go to whichever is listed first in your boot.php.

My two cents.

In RHEL7 I have compiled the dnsmasq 0.78 version using these instructions and doing some changes.

Install the necesary packages:

sudo yum install nettle-devel sudo yum install libidn2-devel sudo yum install libnetfilter_conntrack-devel sudo yum install dbus-devel

config.h options:

/* #define HAVE_LUASCRIPT */ #define HAVE_DBUS /* #define HAVE_IDN*/ #define HAVE_LIBIDN2 #define HAVE_CONNTRACK #define HAVE_DNSSEC

Compiling and starting the service:

sudo make install sudo systemctl start dnsmasq sudo systemctl status dnsmasq

Output:

dnsmasq -v Dnsmasq version 2.78 Copyright (c) 2000-2017 Simon Kelley Compile time options: IPv6 GNU-getopt DBus no-i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC loop-detect inotify This software comes with ABSOLUTELY NO WARRANTY. Dnsmasq is free software, and you are welcome to redistribute it under the terms of the GNU General Public License, version 2 or 3.

What you want to achieve is getting into the realms of software like AppSense. May be worth a look but from experience I know that it ain’t cheap!

You can start here: https://forums.fogproject.org/topic/1341/requests-for-wiki-access-ask-here/131

@Tiagoluz Could you please post an english translation as well.

@jgallo We must be aware of a few things here.

The github site always contains the latest release. So (currently) the files contained are for FOG 1.5.0. If you are working on a down level version of FOG then you need to take the route of extracting the inits. You don’t need to repack the inits, because you only need the file you want to tweak. Once you have the file you want to patch, then you may unmount the loop directory and remove the unpacked init. The structure of files may change from release to release. In the case of FOS, it was split out into its own branch. The correct path (as of 1.5.0) to the file in question is: https://github.com/FOGProject/fos/blob/master/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog.man.reg (full disclosure, it took me a bit to find the right path too). The only caution is as newer versions of FOG are released, your patch file may become stale, where you might need to update a newer versions of fog.man.reg as newer versions of FOG are released. The risk is that you might be applying an older version of fog.man.reg over an updated version fog.man.reg breaking FOG without a clue why.

The rest of the instructions by @JGallo are still accurate (at least for 1.5.0). You can still use the post init scripts to “patch” the current FOS image as in the original post.