Best posts made by george1421

what device is providing your dhcp or proxydhcp services?

@zacadams Would you mind uploading the pcap to a google/dropbox drive and IM me the link. I’d like to look at a bit more than a pict of the file.

But just off the top, I would expect that splat ( * ) at the end of the file name to be trouble.

[Edit] Also watch the firmware on those 7010’s I had one with A16 yesterday that couldn’t pxe boot in uefi mode until I updated to A25.

@sebastian-roth There seems to be an issue with php-fpm and apache on Centos 6.9. For now the quick fix is to disable the link between php-fpm and apache to return php control back to apache. ref: https://forums.fogproject.org/topic/11722/problem-during-upgrade-from-1-5-0-to-1-5-2/18

Can you post the entire boot.php output?

If I had to guess, when you created the menu entry you did not enter anything in the description field? If not that is your issue (it would show up in the complete ipxe boot menu as missing).

The web gui text label needs to be changed from description to menu title or something to make it a bit more obvious that its required.

When I created the entries new, I did put in a description and saved them, the saved entry did not keep the description field, thus it was empty and the menu items were in the PXE boot menu, but blank under everything else (invisible).

@Developers you might want to take a peek at the code to confirm that on an edit of a fog ipxe menu that the updates are being saved back to the database.

In your case its right to actually move off FOG 1.5.0 to 1.5.2 to eliminate the high CPU usage. BUT if you are still on 1.5.0 and its kind of working for you, please wait until 1.5.3 is released (in the next few days) there are some annoying issues with 1.5.2 that are already addressed in 1.5.3 (dev). The developers said that 1.5.3 should drop very soon.

@snaggel The issue is that you are trying to pxe boot a uefi system (type BC/0007) but your dhcp servers are telling the client to boot with undionly.kpxe (a bios [legacy] boot loader). That simply isn’t going to work. You need to update your dhcp servers to be dynamic in the handing out of boot file names or only boot one kind of hardware.

ref: https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence#Using_Windows_Server_2012_.28R1_and_later.29_DHCP_Policy

Well I see what the issue is, but I’m not sure how to fix it (hint: the splat ( * ) indicates what’s wrong). It seems to be a DHCP server problem.

I was working with @zacadams over chat this afternoon and he shared a pcap from the point of view of the pxe client. Here is the relevant part of the pcap.

Note in option 67 the boot file name is ipxe.efi and the length is 8. Sweet that looks right. But if you look at the hex code associated with the entry You see it starts out with 0x69 which is the ascii letter i. If you look immeiatly to the left of that letter I you see 0x08, meaning the name is 8 characters log. All good. If you look to the end of the name after .efi you see a splat character, well damn. If you continue on the next hex code is 0x04, 0x81, 0x78. Now look at the source file from the from the original pcap.

Notice that the hex codes associated with that file name is pretty close to the troubled dhcp packet.

Just for a contrasting opinion. Here is what a proper dhcp packet looks like

Note the boot file name here is undionly.kpxe. If you look at the hex code you see that to the left of the ascii u there is 0x0f ==15. But the key here is look at the hex code next to the e in kpxe. 0x00 is the end of string character. That hex code is missing from the broken dhcp offer. In the broken dhcp offer its a splat ( * ) so the pxe booting client thinks the rests of the text is part of the file name until it finds the first 0x00 hex code.

@sebastian-roth I looked at the shared pcap with a fresh set of eyes this AM and that is consistent throughout the dhcp server responses. It correctly sets the string length but doesn’t terminate the string with 0x00. While it complies with the letter of the IEEE document, it doesn’t follow common practices. I did check a few other pcaps I had laying around and all responses from those random dhcp servers had the string length and 0x00 in the hex code. It appears this Infoblox dhcp server is doing something a bit different. The OP may need to get with Infoblox and show them what he is seeing.

@david-gage Well this pcap isn’t telling me what I need to know. You executed the steps perfectly, so its not what you did. It looks like your dhcp server is sending out responses using unicast messages which can’t be captured using tcp dump. This is the second pcap today that had this strange behavior.

If you look at the pcap you uploaded. You will see only the pxe booting client’s side of the conversation. You see a Discovery and a Request packet. What is missing is the response from the dhcp server of Offer and ACK. The Offer packet is what we are really interested in. In that packet it tells the pxe booting client what boot file to download.

I know the dhcp process is working because the client is sending out a Request packet, because that is in response to an Offer from a dhcp server.

Does your network team have the ability to mirror the pxe booting clients network port to the port where your FOG server is or setup a computer with wireshark and mirror to that port. Port mirroring is a function of the network switch. On a mirrored port all data is echoed to the receiving port. This way you can monitor both normal broadcasts as well as unicast messages.

@nuit SELINUX needs to be disabled for FOG to function correctly. Please check /etc/selinux/config and ensure that its set to permissive. The setenforce command will only work until your FOG server is rebooted then the value of selinux will return if you don’t update the selinux config file.

@raymond-bell said in Backing up database failed!:

@sebastian-roth Please close the ticket. I got it going.

Please explain what you did for others sake.

@snaggel OK if the dumb switch masked your issue, then you need to contact your networking group to have them check to see if spanning-tree is enabled on the building switch, and then to adjust spanning tree settings to ensure that one of the fast spanning-tree protocols are enabled.

If you created a sym link (or even better mounted the new disk over /images, then you shouldn’t need to change anything. The mount should be transparent to fog. Understand this tutorial may be a bit more than you need since I’m moving all dynamic files off the root partition including the images and snapins. The general outline should give you an idea
The basic steps are outlined here: https://forums.fogproject.org/topic/11048/moving-fog-s-images-files-off-the-root-partition-2017-edition

You can use a dns name and create a split horizion dns where you make fogserv.domain.com at each school point locally to the local fog server.

The issue is as Wayne said, Once the client touches a fog server it becomes tattooed to that fog server. Now if you know that ahead of time you can synchronize (i.e. copy the ssl certificate from your master FOG servers to the other remote fog servers) then have the clients reach out via dns name. If you have any clients that have touched one of the older non master fog server, you will have to reinstall the fog client on the target computer.

The latest parted magic iso image I can find (free) is 2013. So I looked through that iso and based on what I see I have an observation.

The error message mentions unable to mount the squashed file system file.

1. I don’t see where you are transferring that file system via iPXE?
2. I do see that file on the iso in /pmagic/pmodules directory.

I would be interested in reviewing the following files from the 2018 iso image.

1. /boot/syslinux/syslinux.cfg
2. /boot/pxelinux/sample_pxelinux.cfg

Lastly are you trying to iPXE boot this image on a uefi or bios based image?

@vince-villarreal said in Change group ID number?:

Query OK, 0 rows affected
Records: 0 Duplicates: 0 Warnings: 0
ERROR: No query specified

This message is expected based on your query (it ran OK). You didn’t update or select any rows from the database. You altered a table descriptor.

@buercky ok I see something (and its not dead people…)

For the above system you have 2 dhcp servers responding with offers.
89.0.0.92 which is giving a next server of 98.0.192.40 with a boot file of undionly.kpxe (you might want to update your dhcp server since you have Undionly.kpxe define and not all lower case undionly.kpxe)

Then you have the troubling one: 98.0.192.75 (which appears to be a dell computer) is also responding with a next server of itself with no boot file name, but it does have dhcp option 60 set indicating its a proxy dhcp server (where your error message on port 4011 is coming from).

To fix shoot 98.0.192.75 and pxe booting will start working better. Understand this is not a FOG problem but a networking infrastructure issue.

Are these windows 10 clients? If so Win 10 has a “feature” to enable dynamic mac addresses. This is done for security ( ?? ) reasons. The pending macs view are for fog client detected mac address. Where the fog client reports in to the fog server the mac addresses it detects on its network interfaces. I use a Linux Mint computer at the moment so I can’t direct you to the exact location of this switch in the Win10 gui, but it should be around the network settings.

@jflippen The last I knew the entire content of the /image/drivers directory is replicated. I do have to say we don’t change drivers much and something may have change since all of the drivers are on all storage nodes at the moment. I’ll have to confirm it still works as I thought.

both the image as well as the snapin replicator should use the lftp command defined in this file fog/lib/service/fogservice.class.php

Double checking I don’t see any other instance of lftp.