Best posts made by george1421

@tyrel-sonohara The first choice if your router supports it is to use your router to supply pxe boot. If you have a router that is not playing nice, or a soho router, dnsmasq is the quickest way to a working solution. It takes about 10 minutes to setup: https://forums.fogproject.org/topic/12796/installing-dnsmasq-on-your-fog-server

@artemz Ok the thing that jumps out at me is that in the path just before the failed to open stream there is a preceding t that shouldn’t be there. I’m not sure if it is an artifact of the error message or someone accidentally put a t at the beginning of the storage node path in the default definition. t/images is surely an incorrect answer.

The step where it is failing is that the image has been uploaded to the FOG server in /images/dev/<mac address> The FOS Engine connects to the FOG server using FTP and issues a move command from /images/dev/<mac_address> to the protected /images/<image_name> directory. The error is saying its unable to find the /images/dev/<mac_address> directory to move it.

Once you find where that extra t is coming from then you should delete that /images/dev/<mac_address> or just manually move the directory to where FOG would have stored it and named correctly. The upload was complete just the FOS Engine could complete all of the steps. There should be no directories in /images/dev that look like mac address unless you are actively uploading an image. If they exist with no active uploads going on, you can delete just those directories because they are botched uploads and are just taking up space.

@ouédraogo Please update your FOS Linux kernel to version 5.15.x series for both x64 and x32. FOG UI -> FOG Configuration -> Kernel update.

That should address this issue.

@geekyjm said in PXE client not seeing new Fogserver:

How do I tell if the PXE server is running on the Fog server?

If you want to get literal, there is no such thing as a PXE server. PXE is a protocol not a thing.

DHCP tells the client where to look for the boot file. Then the client downloads what its told from a tftp server. That is the pxe process in 20 words or less.

The pcap is important to ensure the client computer is being told to load the right file from the proper computer. If you look in the OFFER packet (that comes from the dhcp server). In the header there will be a {next-server} field. That should be the IP address of the fog server. There should also be a {boot-file} field, that should be ipxe.efi or a uefi system and undionly.kpxe for bios system. That should match dhcp options 66 and 67 respectivly.

@trev-lchs What changed between 1.5.4 and 1.5.8 is that FOG switched from use a blank mysql root password to requiring the fog installer to set a password for the mysql root user because of security concerns. So when you transition from a version earlier than 1.5.8 it asks you to give the mysql root user a password, then it creates a new user ID and grants that user ID full access to the sql server database only. From then on the fog installer uses the fogstorage admin account for db access as well as upgrades leaving the root user and new secure password alone.

You can see the password set for fogstorage in the fog configuration -> fog settings page under STORAGENODE MYSQLUSER I’m going to recommend that you don’t change this password, leave it to the fog installer to do so. This password should match the password set in the .fogsettings file.

If one wanted to update this password. I would start by updating the password in the fog ui (understand this should break FOG right after saving the value), next using the mysql commands to update the fogstorage password in mysql. Then test to make sure you can log into the mysql cli using the new fogstorage password. Then update the .fogsettings file and then finally reboot. If the web ui fails then run the fog installer once more and reboot. If it still fails then we will need to manually update the web ui config file with the proper password. Understand while its possible to update the fogstorage account, there are also some risks in doing so.

@trev-lchs This is an interesting one. Lets try at the first question answering No to that. The error in the install log was saying that php-fpm could not be stopped, that is possible that the installer removed it. Lets try No there and see if it will run through to the end.

@trev-lchs said in Network Boot Error:

The result of all this is the screen shot above.

Do you have more than one dhcp server? Make sure the backup dhcp server has the options set too.

Is your pxe booting computer (that’s not currently working) on the same IP subnet as the fog server, or are they on a different IP subnet? If they are on the same IP subnet we can use the fog server to listen in on the dhcp process to find out what the client computer is being told to do. I think the problem right now is your network infrastructure and not fog, but the network pcap will tell us who is being told what.

Not sure I understand your follow up question, so I’m going to guess what you meant. For FOG you don’t need to change any settings between bios based computers and uefi based computers. The only difference is the iPXE boot loader that is needed to get to the FOG iPXE menu.

@wt_101 This is really a question for the developers, but…

Looking into the code it looks like you can update the database schema to 50 and then change the web ui from 15 to 50 characters in here fog/lib/pages/hostmanagementpage.class.php search for maxlength=“15”

I don’t see any other restrictions. There may be some qualifications when importing hosts via the web ui, but it looks like most of the code just takes hostname as it was entered.

As you are debugging this keep an eye on the php-fpm error log in /var/logs directory. If something unexpected happens in the UI, look there for the details on what happened.

@sourceminer So this gives us about 200GB of real data to move…

This is an interesting (hint: annoying) issue. So I take it there wasn’t any error on the blue partclone screen before it threw this error?

I can’t remember if I asked this, in this thread, but when you were at the command prompt where you check the partclone log file in /var/logs to see if it gives and clues??

With 200GB of data, that is typically larger than fog normally handles. So I wonder if we are running out memory to clone this big disk.

Under FOG WebUI -> FOG Configuration ->FOG Settings hit the expand all button.

Now search for CAPTURERESIZEPCT increase the value from 5 to 10.

Search for KERNEL RAMDISK SIZE set it to 275000 from 256000 (if its less than 256000, let me know). Lets see if this makes any difference.

@jape said in FOG unable to PXE boot beyond the VLAN/subnet that the server is on:

The Fog server is a Ubuntu 18 system it is also the DHCPD server .I have not changed the option 66 or 67.

OK now we have a direction. So can you tell me why you are using the FOG server as a dhcp server? Do you have a campus dhcp server or is FOG on a dedicated imaging network.

The question is not as cheeky as it sounds. There are valid use cases for having FOG be the dhcp server, I just want to make sure you have one of those cases.

@rogalskij Using a windows computer, install the tftp client feature. Turn off the windows firewall then open a command window to see if you can tftp get the file ipxe.efi. I’m only interested if it downloads the file or not.

@lcis said in Trying to access /images on deploy-debug:

For curiosity, why couldn’t I mount $storage ?

While debugging your post install script, use debugPause to put a break point in your code. Put an echo statement in just before the debugPause to say “Stop me here”. So when you are debug executing your deployment, when you get to “Stop me here” press ctrl-C to exit the fog script. Now run the set command and confirm where $storage is pointing to.

Also side note, I always set $variable using ${variable} so the bash interpeter really knows what I want as a variable.

When you hit the ctrl-c that should be the exact state of the machine. The /images directory on the FOS target computer should already be mapped to the FOG server /images directory at this point (during the execution of the postinstallscript)

@ariederer26 If you know what the root user account is mysql (this is different than the root user for linux) use that user id and password. If not there are instructions on the internet to reset the root user’s password for mysql. That should have full rights.

Also in /opt/fog/.fogsettings there should be the user account and password the fog code uses to access the mysql database that account has full read / write access to the fog database too.

@mrilly ok two things that jump out at me

1. You are still using the 4.19.x kernel for some reason.
2. The intel nic 8086:0d4c was first added to the 5.5 version of the linux kernel.

You need to go back and review why the 5.15 versions of the linux kernel are not installed in your fog server.

From the fog server’s linux console you can use file /var/www/html/fog/service/ipxe/bzImage to read the version of the kernel to confirm it got updated correctly.

@user419 How did you turn on https protocol in FOG? It almost appears that ipxe did not get recompiled with the same certificate that apache is using for the web server.

@lpetelik For a bit of clarity I have a few more questions.

1. Is the sql server process crashing (no longer in memory) or is it just not responding to requests.
2. What version of FOG are you running?
3. It sounds like you have a fog master node and multiple storage nodes running on VMs? Is that accurate? How many storage nodes do you have in this configuration?
4. How many target computers are in your environment that have the fog client installed?
5. When inspecting syslog/messages/sql server logs do you see any error messages relating to sql server, like too many connections?
6. What is the fog server host operating system?

Just for clarity in definition updating “the kernel” relates to the FOS Linux kernel [bzImage] that gets transferred to the target computer during imaging. This reference has nothing to do with the FOG server host OS kernel.

It looks like the code that runs on FOS Linux doesn’t use these timeout values.

ref: https://github.com/FOGProject/fos/blob/af9e624a59752e126308afda18bfbd4a398e7b2a/Buildroot/board/FOG/FOS/rootfs_overlay/usr/share/fog/lib/funcs.sh#L769

It looks like its possible to add them with little effort. The next step would be to see if we can trap the timeout so the code could issue a power off command.

Edit: With some crude testing it appears that udp-receive will exit with exit code 0 on a successful reception and 255 on a receive timeout (–start-timeout) so we can trap when it unsuccessfully starts the stream.

@alexamore90 PC specifications in what form?

When the computer is in the iPXE menu before image registration you are restricted to what information is available in iPXE. Registration uses FOS Linux so better quality of information about the PC is accessible there.

@rtarr FOG is designed to have one imaging network.

(I’m going to read between the lines here, if this isn’t how you have it setup then please claify)

All devices on that network must be able to reach the master node during pxe booting to find out where its assigned storage node (master or slave) is located. Replication between the master and storage nodes also happen in the identified imaging network, using the IP addresses defined storage configuration panels. Dual IP addresses for FOG imaging infrastructure is not supported.

With that said there are some things you can do.

Your fog server can function as you mentioned with a management nic and an imaging nic. The only thing the management nic can do is manage your FOG server, it can’t be used for any imaging functions.

I’m suspecting that you have a master node at one location and a storage node at a different location where the defined imaging networks are not connected for some reason. That is why you want to replicate the raw data on a different interface than our imaging network. Can this be done, not with FOG, but it can be done. Simply disable the FOG Replication service then use rsync and cron to schedule to replicate the /images directory between the master node and storage node on a timed basis. rsync also has bandwidth restrictions if you need to slow down the transfer. With rsync, just use the IP address on whatever network you want to send the raw files across.

Just be aware that the storage node must be in contact with the FOG server 100% of the time or imaging won’t happen in the remote location, because the storage node is using the database from the master node to get its instructions.

@sniffski OK that bit looks good.

So since you are comfortable with wireshark that will make the next bit easier. Since the FOG server and target computers are on the same subnet, lets use tcpdump from the FOG server perspective. (or wireshark on the fog server if that is where you are currently doing the capture from). Using wireshark on a witness computer will pick up the broadcast dhcp messages but it won’t the unicast messages. After the dhcp process the target computer reaches out to the fog server (dhcp option 66) and requests the file (dhcp option 67) and then transfers the boot loader (ipxe.efi) to the target computer over tftp. This is done over uicast messaging. So the witness computer won’t see it.

I have a tutorial here how to do this with tcpdump: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

If you want to use wireshark on the fog server then use this capture filter port 67 or port 68 or port 69 or port 4011 Right after the DHCP DORA process it should ask the FOG server twice for the file defined in dhcp option 67, the first will be to check the size of the file the second to request the file.

Also be aware for uefi that safeboot needs to be disabled on the target computer or it won’t boot the nbf (network boot file) if it does transfer it OK.

If you can’t get a solution then post the pcap to a file transfer site and either post the link here or use FOG DM to chat the URL to me and I’ll take a look at it.