Best posts made by george1421

Quick fix is to update the FOS Linux kernel to 5.6.8 or later under the FOG Settings->Kernel menu in the web ui.

@smoooo If you are going to use two network adapters (recommended) before you install fog, know the linux name of the nic that will be your imaging network interface. Make sure you have static IP address mapping done on the imaging network interface. When you install FOG it will ask you which interface do you want to use. Make sure you name it correctly. Also FOG gets angry if you change the IP address of the imaging network interface after FOG is installed. So have your network configuration complete before you install FOG.

@Carbonnier-Alexandre But putting together just what I see in the screen shots, I think the target computer is a bios based one and you are sending ipxe.efi to it. Again the pcap will tell us exactly what is going on, but the error screen you showed us looks like a bios pxe boot screen but in dhcp option 67 you have ipxe.efi listed. A uefi boot screen should say something about NBF (network boot file) and not the message about PXE-M0F. At least that is what I think.

If the newer versions of refind > 0.11.0 don’t work, roll back to 0.11.0. This version of refind shipped with FOG for many years. I’m not saying this version works better, but if you upgraded 1.5.4 (which was probably shipped 0.11.0) that may indicate the change.

I’m suspecting the latest version of refind is having an issue initalizing the updated firmware. The FOG Project is at the mercy of the rEFInd project to solve this issue.

@jvenus I’m still looking into this, but looking at the pcap I can see what its doing.

For PXE part that is 100% good and the tftp is OK. iPXE starts up just fine then issues a dhcp. Now if you look at the pcap you see this cycle of discover offer discover offer and so on. What is going on here the discover asks for certain fields from the dhcp server and the fields returned from dhcp are not sufficient so iPXE queries again and the cycle repeats. What’s missing I don’t know yet. I’m getting a side by side setup.

@jvenus https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed

The simple answer is that value is ONLY set when the image is updated by the FOS Linux engine. If you copied over the images from the old FOG server and the then recreated the image definitions that field will be zero. Its a display value and not used in any way related to imaging.

@JRA said in Can't WOL PCs:
It would help if you quoted the questions but we can work with that.

Understand I’m looking at this from a truth table perspective and not judging your responses.

Old one was 1.2.0, new one is 1.5.7

OK that is fine. AFIK the code for WOL has not changed since the 1.2.0 days. If you were running something from the early days (0.29 etc) it probably has.

Have tried those yes, no joy.

Ok if you have tried a different product and still no WOL, then we might rule out FOG as being faulty. I’m not saying it isn’t at fault but you have software from different vendors acting the same way.

Most if not all aren’t on the same subnet/vlan no.

OK WOL uses a directed broadcast. So your network infrastructure can control the WOL ability to work properly. I would suggest that you put a test computer on the same subnet as the FOG server and test to see if WOL works here from a cold boot of the target computer.

Didn’t know that in fact! Tried pulling the power out for a test but still no, nothing will WOL.

OK so windows probably isn’t stepping on WOL in your case.

The key to solving this is to find out where the problem isn’t so you can narrow in on where the problem might be. Its possible in your core router’s ip helper service you have an access list hard coded to the old FOG server’s IP address in an access list, firewall rule, or something. That is why the directed broadcasts of WOL are failing.

Also understand there are at least 2 standards on how WOL works. The utility I mentioned before supports both methods.

From the FOG server you can capture the WOL packets if you install the tcpdump program and run this command. Understand you will need to change the network interface name to match what your fog server’s interface name is (can be found with ip a s command and then pick the right interface). Replace eth0 in this command with your interface name.

sudo tcpdump -i eth0 '(udp and port 7) or (udp and port 9)' -x | tee wol.log

Run the above command and then generate a WOL packet either from FOG or the WakeOnLAN program. To see if its actually generating the WOL magic packet. The output will be saved in the wol.log.

Here is a wiki page on WOL forwarding that may help: https://wiki.fogproject.org/wiki/index.php/WOL_Forwarding

@JRA said in Can't WOL PCs:

(on eth0 as the output of the first command gave me)

As I said you need to change eth0 to match what is installed in your fog server for its network adapter.

If you use the command I provided ip a s you will see an output that looks like this.

In my case ens192 is the right answer. That needs to replace eth0 in the command I gave you.

@JRA How old is this host OS? What OS is this fog server using? That hasn’t been a standard for years.

@JRA OK I just tested in my network, same subnet as fog server the system WOL correctly from a G3 state.

So you now test same subnet can FOG WOL a system that is configured in the firmware to wake up via the network?

@JRA Ok then in the network driver setting (same neighborhood) How about these settings.

Turn off allow computer to disable this device to save power
Turn on allow to wake leave the second one off or only magic packet method will wake it. At this point I don’t know what is the right answer. I don’t use WOL in my environment, and if I do its only for imaging computers in our dev lab.

@DJslimD1k Well its because you changed the permissions on that file. You should have edited it with root user or sudo edited the file. Change the mode back to 755 sudo chmod 755 /etc/my.cnf.d/mysql-server.cnf Then restart mysql server.

MOD Note: merged posts into this tread

@Pyrol said in FOG Kernel update: "Preparing to move to tftp server":

I’ve a problem with pxe boot not finding an interface.

Well this issue may show up in two different places. If you get to the FOG iPXE menu then you are on the right track by upgrading the FOS Linux kernel to 5.6.18 or later.

On point of your issue, if the FOG server doesn’t have create permissions on the fog web site (/var/www/html/fog) this issue might appear. Please do the following on the FOG server and post the results.

cd /var/www/html/fog/service/ipxe
ls -la

Lets see what permissions are set on those files.

Also did you set selinux to permissive? What is the results of this command?

getenforce

@Pyrol Its not clear why the webui update processes is failing. But in the case of your hardware you DO need the 5.6.18 kernel to see the network adapter. Since its a Dell don’t forget to set the disk mode to AHCI mode and not use RAID-ON. The system will function just fine in AHCI mode with no performance loss.

@Pyrol said in FOG Kernel update: "Preparing to move to tftp server":

and the final step was to go into WebGui>fog settings>tftp server
and here changed bzImage to bzImage.64 the same with bzImage32

I would back up to this step. Replace the existing bzImage with the .64 bit one keeping it bzImage and the 32 bit image should be named bzImage32 (watch your case because it is important). Leave everything else FOG defaults. It will save you headaches in the future. Then pxe boot the client once you are on 5.6.18 it will see the network adapter.

Then we can look back to why the update process is not working as it should. What version of FOG are you running?

@cicero ok two things.

The PciConfig handlers is just a spurious warning message. You can safely ignore this warning. If FOS Linux hits a critical warning it will stop booting.

What is more interesting is what I can’t read in the picture. It looks like /images are being redirected somewhere. What is going on with that link? I think I can make out you have the virtual raid adapter md127 is mounted on /raid/fog/images and then you have a symlink mapping /images to that sub directory. NFS doesn’t follow symlinks.

There is a few ways to fix this, but I would have to ask why the logic of /raid/fog/images? A quick way to fix is to mount /dev/md127 over /images (directly) and then rerun the fog installer to fix the reset of the bits.

@Sebastian-Roth said in Skip Bitlocker detection?:

But how?

If you run bitlocker without TPM you have an option to use a usb key with the certificate installed or with a preboot password that is managed by the uefi boot loader. It is surely not as secure at the tpm route, but if you have no option, you have limited choices.

Some countries may mandate to not use tpm protection.

Change bios time with fog NO. FOG can’t step into the bios of the computer. But should the question be, how can I set the target OS timezone on a deployed image?

As for the shutdown on image there is an option when you deploy. Just tick the checkbox and the remote system will power off instead of reboot.