@george1421

Now you said that isc-dhcp server worked?? The reason why I ask is that isc-dhcp server and dnsmasq do the same thing. So why would isc-dhcp server issue IP addresses and dnsmasq does not respond?

To be honest, this is beyond me.

Initially, when I configured the FOG server I installed isc-dhcp server, configured pool of addresses and added “next-server” and “filename”. Then I set bootprelay of the switch to point to the FOG server and everything worked (and still works if I go back to this scenario).
Afterwards I realized that our expensive switch supports dhcp and decided to give it a shot (why use separate service for something that already runs on the switch, right?). Since then I’ve encountered this issue i.e. switch supporting only numerical option codes (66, 67 etc). Analyzing the frames turned out that my clients are unable to evaluate those options even though they do exist in the dhcp packets! Having “next-server” and “Boot file name” in the packet body seemed like the only way it works. I managed to confirm this by analyzing frames coming from my working isc-dhcp server.

Now, you can probably see how strange it is.

@huecuva said in Hanging on ipxe initalizing devices.:

Can those iPXE binaries be changed in the webgui?

No because it all depends on the DHCP server you actually use in your network (quite often it’s not on the FOG server itself).

@rubensurtfe-0 As soon as the boot files are sent to the target computer, the FOG server is no longer involved with the target computer. SO this error is with what ever OS is running.

@victor-r Interesting… there must be some other code that is doing that. Rerun the fog installer to put things back.

Just to be sure I’m looking in the right area, you are trying to replicate your images from the FOG server to the windows storage node or are you trying to capture directly to a windows storage node?

@dominique said in Database engine MyISAM - upgrade FOG?:

Any idea when 1.6.0 will be general available?

There is no timeline for this yet. Many people use FOG but very few help working on it. So things are going very slow at the moment. We’ll bring out a last 1.5.x release (1.5.10) to finish up that line and then the next will be a first 1.6 release (months down the road).

If you are keen to get InnoDB earlier you can follow the topic Goerge posted. From my point of view this should be possible in 1.5.x setups as well. But we won’t officially support this and don’t want to push out for a major change in the 1.5.x branch anymore.

@george1421 Ok, I fixed that. I removed my current policy, and created two new policies. I didn’t change any of the Vendor policies. I just made policies for 00007 and 00009 for now.

This is what it looks like now:

Does this look like it should work? I tested it with the Dell 3080, and it still gets the undionly.kpxe file, not the ipxe.efi.

Thanks again!

@george1421

On it. Will report back shortly.

@lakk I have had to work (deal) with them from time to time. I can tell you I did the exact same thing with them (breaking the mirror) by (assuming) the intel raid controller acts like a traditional raid controller. I can tell you it does not, because it exposes both the raid device and the JBOD disks to the OS. The OS needs to be smart enough to know how to manage the array.

I did write a tutorial on how to use FOG with these type of raid adapters here: https://forums.fogproject.org/topic/7882/capture-deploy-to-target-computers-using-intel-rapid-storage-onboard-raid (oh my all the way back in 2016…)

I can tell you another example (possibly of what you are seeing). We have several dell precision rack mount workstations that use these raid controllers for their local disks. Somewhere in 2018-2019 they upgraded the OS from Windows 7 to Windows 10. About 6 months later we got a call that 2 of the workstations had reverted back to windows 7. This wasn’t possible because it was a clean install of windows 10 and not an upgrade from Windows 7. Its just not possible to do what they said it did. We had them reboot the workstation and take a few screen shots. They called back and said that it switched back to windows 10. Thinking they were just crazy we said the next time it happened give us a call. About a month later it did it again. To no make this any longer of an example I’ll cut to the point. We found that the raid-1 mirror was split (akin to split brain) some time before windows 10 was installed. So not knowing the mirror was broken they installed windows 10 and it went onto one disk while the other disk remained at windows 7 install. It appears that the intel raid controller picks at random which disk will be the leader and the other the follower in the mirror (for the intel controller the leader disk has read/write activity, while the follower only has write activity). That is how on one boot it would start up as win10 and the another boot win7.

@tomtom2770 So let me discuss what FOG needs to work in your environment.

The master node is kind of the brains of the FOG system since it houses the fog database.

The storage nodes are disk storage for deploy only. It needs to be in contact with the FOG server 100% of the time for the storage node to remain functional.

So lets say you have 1 sites HQ and SiteA. You have a master node at HQ and a storage node at SiteA. At SiteA you have the dhcp options to point to the local storage node and the needed boot file.

You pxe boot a target computer at SiteA. It downloads the boot file from the local storage node and iPXE starts up. Then iPXE reaches out to the local storage node to download default.ipxe file. That file points to your master node boot.php script which builds the iPXE Menu. If the computer isn’t registered, when you select register it will download FOS Linux (over the wan) from HQ to the target computer. (once the computer is registered and associated with a location, the storage node will be used for all other file transfers).

Now if you have the fog client installed on the target computer it will only talk to the master node to get instructions (install snapin, update inventory, etc). If the target computer get an instruction to install a snapin, that snapin is downloaded from the local storage node.

So the point here is that the HQ fog server is important here and must be at a fully routable location from all remote sites.

If your site to site VPN ever goes down so does FOG imaging. Depending on your goal, number of client computers, and stability of the VPN network, you might want to install a full fog server at each location.

@rogalskij The FOG developers are expecting the Linux kernel developers will take 5.10.x to LTS status. When they do the FOG developers will make 5.10.x the standard kernel in FOG. ref: https://www.kernel.org/

FWIW, there was quite a few new drivers added to 5.9.x series (almost as many as was added to 5.5.x), so 5.10.x LTS can’t come fast enough because FOG will start running into that hardware soon.

@geardog Two things from the tutorial I just want to point out:

Make sure its at least version 2.76 by issuing this command at the fog server’s linux command prompt sudo dnsmasq -v. The version needs to be 2.76 or later.

and as George already mentioned here:

Be sure to replace <fog_server_ip> exactly with the IP address of your fog server. Be aware that <fog_server_ip> appears multiple times in the config file.

@sebastian-roth said in ipxe/boot.php and bzImage running very slow:

@danieln said in ipxe/boot.php and bzImage running very slow:

The only change was that I added one additional storage node.

Storage node being in the same subnet as well?

Correct. I double checked and it is on the same subnet.

@danieln Have you tried imaging that exact same machine from both servers and you only get the “No such file or directory” error on the later one?

And asking again, do you have another notebook - exact same model - that you can deploy to, just to see if you get the same ATA errors?!

@robpomeroy said in Fully automated UEFI-based O/S installation (Debian 10):

But grubx64.efi seems to have some hard-coded files it looks for, so I’m not sure where else to place them.

Also be aware there are different flavors of grub. There is grubx64.efi and grubnetx64.efi depending on the distro where you get them from some distros don’t add networking support to grubx64.efi so it can only reference local storage.

You can pxe boot with grub in the case of grub (grubnetx64.efi) from ubuntu’s repo on your tftp server create a grub directory mkdir -p /tftpboot/grub and place your grub.cfg file in there. That is hard coded into the grub binary as you noted.

@palloquin said in fog client no longer rebooting system to deploy, where to start?:

21/01/2021 11:26 Middleware::Communication URL: http://172.16.1.2/fog/management/index.php?sub=requestClientInfo&mac=00:FF:3E:84:3E:C1|40:A8:F0:61:47:B3&newService&json
21/01/2021 11:26 Middleware::Communication ERROR: Could not contact FOG server
21/01/2021 11:26 Middleware::Communication ERROR: The remote server returned an error: (500) Internal Server Error.

Those are the relevant lines frm the log. Please check the apache and PHP-FPM error logs (see my signature) to find out what is causing the HTTP 500 internal server error.

@rubensurtfe-0 It works once we have the right ISO image and correct web server path.

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

@alesser Not really unfortunately.

The token you see on the screen is stored in the fogserver in a different mechanism. What you see is an encrypted string compared to what is actually stored in the FOG Server.

If you have the original “plain text” value, it should work (even if you don’t see the same key) as it’s still referencing the same “plain text” value.

@julio les snaping son concue pour creer des applications à installer sur des systèmes d’exploitations windows.

@active-pcb I guess the partitions were set to use a fair amount of the disk space for /home when you installed Ubuntu. Run sudo fdisk -l and post output here in the forums.