Thks , so yes it was not booting in the correct format so i added the extra uefi file names to pfsnese and it works flawless now. Thks guys

@fairoozfarhan The gui route is the recommended method.

If that doesn’t work you can manually download the kernels from here https://github.com/FOGProject/fos/releases and then bzImage and bzImage32 (watch your case because it is significant) to the path I provided earlier. Use the file command to ensure the kernel is correct.

@george1421 We just ran the engine update. Thanks for those links. We’ll watch it for a bit to see how it looks. The GUI is a bit slow at the moment, hoping that clears up.

On a side note, while working with this issue, we ran .installfog and during the install it picked a new STORAGENODE MYSQLPASS password that had a closing bracket in it. It broke the node’s connections to the master even with the password updated in all the spots it should be. Once we created a new SQL password (on a whim to test, without special characters) and updated it in .fogsettings, reran the .installfog file, the nodes started talking to the master again.

I think we are in much better shape. We need to fix our node password issue and start imaging again to know for sure.

@rtarr said in 2 NIC Host: Set 1 NIC to Remote Management/Replication and 2 NIC to Imaging:

I am using two NICs because I want all the imaging to happen on a segregated network and any repo updates or image replication to happen over the LAN NIC. This prevents imaging from happening over our firewall tunnels.

Having a second nic and dedicated imaging network may not be necessary to avoid imaging over the vpn tunnel.

(connect both master node and storage node to your business network)

At the remote site set dhcp options 66 to local storage node IP address and dhcp option 67 to ipxe.efi. -OR- use either dhcp profiles or dnsmasq running on the remote storage node to point to the remote storage node for pxe booting. This will keep from downloading the ipxe boot loader over the vpn tunnel.

At HQ again setup dhcp option 66 to master node ip address and dhcp option 67 to ipxe.efi. On the master node installed the Location plugin. Create your two different locations and assign the storage nodes to those locations.

Now assign the target computers to the proper location, either via the web ui or when you do a full registration.

So at this point you have a local and remote location defined. You have the master node assigned to the local location, the remote storage node to the remote location. You now have the target computers assigned to the proper location.

So now you pxe boot a computer at the remote location. I will pull ipxe.efi from the storage node. The target computer will then make a http call to the master node to find out where its storage node is located. Then if the storage node is local to the pxe booting computer it will image all at the remote site. There will be small update http calls to the master node to let the FOG server where it is in the imaging process.

The only thing you can’t do in this setup is multicast imaging, that can only happen from the master node in any storage group.

@junkhacker

Thanks for your response. I admit I am inexperienced with linux configurations.

Do you have a suggestion on the best way to deploy fog as a VM, with a physical freenas system (with a NFS share)?

Sorry for the ignorance on my part.

Nevermind. For whatever reason my host module settings were all deselected. No idea why. I am using persistent groups and these are set in that group.

@Sebastian-Roth
Hmm… Maybe “some other forums” has right… Maybe somehow Virtualbox software blocks the tftp processes while PXE booting…

I change VM software to Windows Hyper-V and i don’t have problem with tftp timeout anymore…

@sebastian-roth I just noticed .177 was out and updated. No errors at all during the update process.

@sebastian-roth I figured it was something like that. The good news is FOG is working for me under 22.04.1

@sebastian-roth @george1421

Thanks the updated kernels fixed it
it now PXE boots and gets into fog and can upload and download images perfectly!

@george1421 Thank You for beeing so fast 🙂
I’ll try that in my Lab-Environment.
Fortunately, I have a little time until the pool has to be online.
But than it has to be bulletproof 🙂

I am also not used to rEFInd yet, but so far i like it.
I think I even found something to look for HD-Labels.
With SSD in UEFI this may hopefully work with several PCs

But further Ideas are welcome 👍

Are you using the location plugin? If not, that could explain a lot, as FOG will image from whatever storage node with open slots rather than a specific one in the same location as the host.

@stealthlegend Ok I will look into this further. But to your point, I do see how this can be beneficial for bulk imaging.

Thank you!

@Xinzo Just a quick note for your understanding. The links you posted in your initial topic post are both about changing the keyboard layout once the Linux kernel (FOS) loads. But entering username/password on a quick deploy is when iPXE is still loaded (before FOS).

I added keyboard layout setting to the latest dev-branch version of FOG just now. So please update to the latest version (1.5.9.174 or later) and make sure you have the set KEYMAP in FOG Configuration -> FOG Settings -> General Settings (e.g. to fr or de).

Be aware that iPXE only comes with simple localized keymap support. For example some special characters (e.g. §) and German Umlauts do not work. It’s not the full set of latin1 keymaps that the Linux kernel actually supports. But most special characters work and YZ are not swapped out like on the US layout. So I hope it’s still helping you when typing username and password on quick deploy.

I can’t properly test this on UEFI machines as I only have a VirtualBox test environment at hand and PXE booting doesn’t work here in UEFI mode. There were rumors about keymap being an issue on UEFI system in the iPXE forums. No idea if that is still the case.

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!

@anwoke8204 said in Fog taking forever to boot to the network:

tftp 10.4.47.15 ipxe.efi c:\users\kstevens

Hopefully you just missed the action command when you posted the command.

The command should be
tftp 10.4.47.15 get ipxe.efi c:\users\kstevens and it should place the file ipxe.efi in the directory path you provided. It concerns me that the destination file name did not match the source name. The transfer should be very quick like about 2-3 seconds from the time you hit enter on that get command.

What are ping times to this fog server 10.4.47.15 from this same windows test computer?

What are ping time if you use this command ping -4 -l 1300 -n 4 10.4.47.15 This command says use ipv4 set the payload size to 1300 and ping 4 times to the host. I’m specifically using a payload size larger that the default ping size to see if we are hitting a mtu issue that wouldn’t be visible with a 64 byte ping size.

@lcis said in Attempting to check in...... failed:

I’m sorry for the inconvenience…

Not at all an issue. I just thought I let you know. You can’t count on things to be fixed in working-1.6 because no one is maintaining this branch as of now.

Thanks for testing the quick fix and reporting back. I will look into properly fixing this issue in the working-1.6 branch some time this week because I remember we had this issue mentioned in the forums a couple of times and now we know what’s causing it.

@ariederer26 said in How to move DB and images to different server:

Do I have to execute it as Ubuntu root user? Or myself the only user on the system?

In general any Linux/Ubuntu user is able to run mysqldump. But there is a chance you can run mysqldump and not have to provide DB credentials if Run as root.

@george1421 That’s what’s done it, the kernel version I’m using at this subsite is older than the one at the main server.

Main server has been brought up to date but for some reason, I never considered all 37 sites would also need to have bzimage/32 updating as well.

Well, that solves it. Even if it was my own stupidity haha! Thanks mate!