Lets make sure we understand. You CAN create a linux reference image and deploy it to many hardwares. You don’t have to do anything special. A typical mainstream Linux distribution has all of the drivers on the hard drive already. When Linux boots, it identifies the installed hardware and automatically loads the correct drivers. The only thing you can’t do is capture an image from a bios based computer and deploy it to a uefi system. This won’t work. But that is also the same for MS Windows.

Are you having a specific problem, or is this just an open question?

IMO, you would be better off (now that you are on the trunk release) to just use the native trunk tools for creating your custom menu. Its quite easy now (as compared to hand editing the config files) and can all be done via the gui. Instead of putting effort into making the older way work, focus those efforts on the recommended and supported solution moving forward.

I wrote a tutorial that may be of some use on how to boot a MDT iso image from the new FOG menu.
https://forums.fogproject.org/topic/6284/booting-mdt-2013-litetouch-with-fog/8

There is also a geat wiki page with more helpful hints.https://wiki.fogproject.org/wiki/index.php/Include_any_ISO_in_the_FOG_Bootmenu

@fry_p ok now I think is time for some hokus-pokus magic without breaking much.

From your production server export the image definitions and import them into your dev environment.

From your production server export and then import the host definitions into the test setup. This will create a clone of your production environment without the image files.

Temporarily move the production FOG server’s IP address (i.e. just swing it out of the way) and move the dev FOG client server’s IP address in place of the production fog server (understand this may impact pxe booting if you have them boot through FOG). The goal here is to apply real world loads to the FOG client server. We should watch the CPU usage on the FOG client server (we may need to increase the number of php-fpm workers to satisfy all of the requests) as well as the mariadb service on the dev imaging server. We are looking for high cpu usages on both systems. This might tell us if we need to spin off the sql server onto its own server. We should also gauge the web ui performance on the imaging server, because that was a pain point when you had the check in times set to the default.

I’m not sure I’d leave the check in time at 30 seconds in a production environment, but it would be interesting to see the load.

When you are done testing then swing the dev FOG client server out of the way and put the production fog server back in place.

All I have is what I see in the tea leaves, but it looks like your hard drive has some bad spots near the end of the disk.

And for me the upload/download terminology is a bit loose. That is why the devs changed it to capture and deploy. I assume you were capturing the image from the 7440? If it was a capture, also ensure you have enough free space on your server, just as a safety check (even though the error seems to be a crc error).

IMO the quickest way to migrate from another platform (and to be sure its right) is to deploy with clonedeploy, clonezilla, or what ever you captured the image with to a disposable system and then turn right around and recapture with FOG. Don’t let the target computer boot into the target OS, but just deploy and then recapture. That way you can also use FOG’s more advanced compression tool zstd over gzip which clonedeploy appears to use. If you deploy to a modern computer or a vm on a fast server it will take you less time then extracting, converting, trying to understand the FOG meta data and then recompressing the files. Remember you are dealing with GBs size of files here.

@issa1998 I just noticed this is fog (FOS) version 0.32. I’m not surprised that its having an issue with the graphics. The screen is running in 80x25 character mode instead of the 132x(a number I can’t remember).

Well it looks like its possible.

Lets first start by creating a new iPXE menu.

FOG Configuration->New iPXE Menu (something like that posting from old memory)

Menu Item: os.Reboot
Description: Wait and Reboot
Parameters:
reboot || goto MENU
Menu Show with: All Hosts

Then go and save that menu entry.

PXE boot the target computer into the iPXE menu and pick the Wait and Reboot menu. Does it do what you want (not the wait part, but the reboot). If it does then go back into the iPXE menu editor and make that entry the default menu item.

Understand I have not personally tested this so it may work, and it may not. If the system reboots then when its selected as default you will get the wait and then the default action will be to reboot the target computer.

Just adding some background to what Sebastian posted.

During the pxe booting process there are 3 distinct transitions as each of the kernel(s) boot PXE ROM -> iPXE, iPXE->iPXE, and finally iPXE->FOG target OS [FOS]. Each one of these transitions causes the network link light to “wink” or go out for a second or two as the new booting kernel configures the network interface. If spanning tree is enabled, in normal mode, it takes about 30 seconds to the switch port to move to a forwarding state. Since the booting process is so fast, by the time the switch goes into the forwarding state its too late. So when this happens the developers will recommend that you put a mini or unmanaged switch between the target computer and then building switch for debugging purposes. These mini switches are dumb (which is a good thing) they just pass traffic and don’t do any advanced stuff. This also isolates the target computer’s network wink during booting from the building switch, so the Spanning Tree stays in the forwarding mode the whole time. If this is the case, then the recommendation is for you to contact your network people and to confirm that the building network ports are in RSTP, fast STP, or port-fast (depending on the switch manufacturer)

If the mini switch doesn’t work for debugging then we can focus on other things.

@kaywokke said in Clonezilla intergrate in FOG:

i want to boot the device in Clonezilla where it automatically set back the right image of the device.

Isn’t this duplicating the same function that FOG does already? Without any coding?

But back on topic.

I know how hooks are supposed to work as well as I understand how the FOS Engine runs. In a normal FOG deployment the FOG server sends messages to the FOS Engine (the customized version of linux that runs on the target computer) via kernel parameters the FOG server writes into the command that starts the FOS engine. There is a special kernel parameter to the FOS engine called type. That type parameter tells the main FOS script what to do on the target computer. See this main script. https://github.com/FOGProject/fos/blob/master/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog

When the FOS engine prints unknown request type Null, is because the type kernel parameter was not set. When you write that hook, I assume that you are creating your own new type parameter. You need to pass that parameter to the FOS engine. So as I see it, you need to program the hook (what the code will actually do) as well as configure a matching parameter to send via the task type edit plugin.

Now onto what I was mentioning before. I have a tutorial on how to add a FOG iPXE menu to boot different live linux environments using FOG. Understand this is unrelated to imaging. https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images
This is all done without any programming. I’m just creating a new iPXE menu that calls up the different linux kernels. While I haven’t had the need, I assume you could pxe boot into clonezilla this way to.

While the general recommendations are to update 1.2.0 to the trunk build to get the latest drivers built into the kernel and support for gpt disks, uefi firmware and windows 10…

You might be able to get it working with 1.2.0 by just updating the kernels to the latest. What version is your kernels on the 1.2.0 installation?

You can get the very latest kernels (understand there is an equal chance that they will/wont work with 1.2.0) by using the following linux commands
sudo wget https://fogproject.org/kernels/bzImage
sudo wget https://fogproject.org/kernels/bzImage32

You should rename the original kernel files in /var/www/html/fog/service/ipxe and then place these downloaded files in that directory.

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

@ITSolutions look at Junkhacker’s post here https://forums.fogproject.org/topic/6463/expose-fog-host-and-image-properties-to-post-install-scripts/7

I’ve had it on my back burner to write a php page that I could call in the post download script to pickup more deploy time info that is currently listed above. There never seems to be enough time to work on it though.

@abos_systemax what type of input do you need from the user? I have a pretty extensive postinstall script. I haven’t tried it in a while but I was able to pause the postinstall script to wait for an IT tech’s input and then write a file based on the user’s input.

@yeet TBH I would not use fog for this. There are better/cheaper solutions out there, specifically Veeam Backup Agent (free). You can have it take nightly backups to where you can do a bare metal restore if the system fails. You can setup a retention period for each backup (i.e. 14 days before rewriting the oldest backup).

The target of your veeam backup can be a nas, san, another CIFS based computer, or a Veeam B&R server. I use the Veeam backup agent at home for my windows and linux computers backing up to a Synology NAS. Works perfect.

@abos_systemax I did have a sample script from my dev box (the one and only I didn’t purge about a week ago).

Here is the basics of the code.
Create a file in /images/postdownloadscripts called fog.question (you can really name it what ever you like). Then paste the content of the follow script into that file.

#!/bin/bash
  . /usr/share/fog/lib/funcs.sh;
  read -p "Enter your room number " rn
  echo "You answered ${rn}. ";

Now edit /images/postdownloadscripts/fog.postdownload

And append this line
. ${postdownpath}fog.question

Now deploy your image. After the image is deployed the installer should stop and ask you for the room number and then continue.

@fry_p Really when it comes to secure boot FOG has 2 options.

1. Pay to get a signing certificate from microsoft and then the fog developers will have to sign the FOG kernel and all of the iPXE boot loaders. This will take someone to run this project and money to pay M$ for the signing certificate. That would force the FOG project into some type of subscription model to continue to support that service.

2. Add your own certificates to the cert store in the uefi firmware. That will require the creating a FOG PKI infrastructure and then updating the certificate store on each computer (once) to match the signing certificate for FOG as well as keep the other certificates so that the microsoft stuff still continues to work.

Myself personally I started looking into option 2 but then found something else shinny to chase and the project got tabled.

@abos_systemax As for the keyboard issue, I can not help you with that other than can you use an external keyboard?

For the system renaming. I don’t use the fog client for that either. In my case we use an unattend.xml file as part of the sysprep process. We update the unattend.xml file in the fog post install scripts with the computer name and other relevant install time settings.

I use the following command in my post install script. The variable $compname is calculated based on the target computer asset tag and install location. In your case the $compname variable would be set based on the question/answer you provided. Depending on where you place the unattend.xml file you need to provide the full path and filename of the unattend.xml file (Reminder: pay attention to the case of the file and path)

sed -i -e "s#<ComputerName>\([^<][^<]*\)</ComputerName>#<ComputerName>$compname</ComputerName>#gi" $PathToUnattendFile

@robertd Since we are talking about a security concern, only believe in what your eyes and experience tells you.

I want you to look at these two links: https://launchpad.net/ubuntu/+source/apache-log4j2

and: https://www.cyberciti.biz/faq/apt-get-list-packages-are-installed-on-ubuntu-linux/

Now if you combine the two into this command: sudo apt list | grep log4j and/or sudo apt list | grep apache You will need to run these from the FOG server linux console. Look through the output and see if any of log4j packages are installed.

Now with that said, FOG programming doesn’t use Java at all. FOG is PHP based. Again don’t listen to a dude on the internet prove it to yourself.

@arnaudrigole said:

@george1421
The 2008 server is the storage node, which is defined directly with its @ip on a fog storage node/group

Ok that explains why things are not working!! I started setting up how to do this with Server 2012, but ran out of time. The root of your issue is that you need to install FTP on the Windows storage node to move the files. This guide should get you started: https://forums.fogproject.org/topic/6941/windows-server-as-fog-storage-node-reboot Understand this is for 2012 but 2008 is very similar. I used powershell for the copy and paste reasons.

@anisgh I would say make your golden image as complete as possible. The only time you need to install applications after imaging (that includes MS Windows) is when the installation of the application creates a unique GUID to identify the system or application. The best example of this is enterprise antivirus. This is where each client would get its own system id to identify itself to the av management software. You would not want to clone this guid to every computer because then you will have many computers with the same GUID.

For linux there is no concept of this as far as I know. So load everything you need into your golden image and then capture and deploy your image and be happy.

@MrSmith912 said in PXE Boot freezing at the BG.png?:

@george1421 you sir are correct, they are catalyst. I will try the dumb switch when i get back to work in the morning.

We are seeing this more often now. Not sure why either. But it seems that the newer realtek nics are having a problem with (we are trying to make a solid connection here):

1. They are not negotiating the link speed properly
2. They are having a compatibility issue with the green ethernet settings 802.3az and the more advanced switches (i.e. catalyst)
3. Some other initialization handshaking that goes on between the nic and the catalyst switch.

We found that putting an unmanaged (dumb) switch between the catalyst and realtek nic breaks this bad behavior. Again we don’t have a solid picture why this has started in the last year or so. It could be the nic or the newer FOS linux 4.x kernels taking advantage of these newer negotiation protocols. The FOG developers simply don’t have enough info yet.