@awellis I have some sad news for you. I setup a clean 1.5.0 fog environment and multicasting works “as described on the tin”.
Is your fog server in a virutal environment?
@awellis I have some sad news for you. I setup a clean 1.5.0 fog environment and multicasting works “as described on the tin”.
Is your fog server in a virutal environment?
With a quick teamviewer session this issue has been resolved. The issue was just the sequence of install and ensuring eth0 was up before installing FOG.
There is currently a bug in 1.5.0 that is causing this. The problem has been (will be) fixed in 1.5.1. Is this a show stopper for you? FOG 1.5.1 is expected to be released in the next week or so.
@bigsease30 Yeah what you have is wrong. It should look like this:
@gnavarrete I’m only here to provide options. Do what is the best for you and your company. I agree with moving off 14.04 since its past EOL anyway.
@gnavarrete I think you have posted the best path forward. Create a second FOG server, copy the images over and export and import the image meta data and hosts. https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG
as for the dnsmasq, the link I provided before has a working ltsp.conf file. I’ll repost it here. Just don’t forget to change the <fog_server_ip>
to the fog server real IP address.
# Don't function as a DNS server:
port=0
# Log lots of extra information about DHCP transactions.
log-dhcp
# Set the root directory for files available via FTP.
tftp-root=/tftpboot
# The boot filename, Server name, Server Ip Address
dhcp-boot=undionly.kpxe,,<fog_server_IP>
# Disable re-use of the DHCP servername and filename fields as extra
# option space. That's to avoid confusing some old or broken DHCP clients.
dhcp-no-override
# inspect the vendor class string and match the text to set the tag
dhcp-vendorclass=BIOS,PXEClient:Arch:00000
dhcp-vendorclass=UEFI32,PXEClient:Arch:00006
dhcp-vendorclass=UEFI,PXEClient:Arch:00007
dhcp-vendorclass=UEFI64,PXEClient:Arch:00009
# Set the boot file name based on the matching tag from the vendor class (above)
dhcp-boot=net:UEFI32,i386-efi/ipxe.efi,,<fog_server_IP>
dhcp-boot=net:UEFI,ipxe.efi,,<fog_server_IP>
dhcp-boot=net:UEFI64,ipxe.efi,,<fog_server_IP>
# PXE menu. The first part is the text displayed to the user. The second is the timeout, in seconds.
pxe-prompt="Booting FOG Client", 1
# The known types are x86PC, PC98, IA64_EFI, Alpha, Arc_x86,
# Intel_Lean_Client, IA32_EFI, BC_EFI, Xscale_EFI and X86-64_EFI
# This option is first and will be the default if there is no input from the user.
pxe-service=X86PC, "Boot to FOG", undionly.kpxe
pxe-service=X86-64_EFI, "Boot to FOG UEFI", ipxe.efi
pxe-service=BC_EFI, "Boot to FOG UEFI PXE-BC", ipxe.efi
dhcp-range=<fog_server_ip>,proxy
@towndrunk well I can see two paths for you.
You need to configure the FOS engine to look for raid cards. Remember that FOS is “intended” to be a workstation imaging tool (one to many). Its not “intended” to be a backup tool. You can go this route, with a bit of debugging get it to work. FOS (the customized linux os that caputres and deploys images) does understand and support raid cards as long as if the hardware isn’t so new where there are not linux kernel drivers for the hardware, and you enable the raid function.
Use a third party product like Veeam Backup Agent (free) to make backups of systems. This would create a DR backup as well as on going incremental backups. Its a really nice tool.
If you want to go down the FOG route then you have a little debugging to do. I can guide you down that path to see if its even possible.
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.
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.