@hector-santiago Just be aware the FOG web UI default user is named fog and has nothing to do with the Linux service account fogproject. The later should not be messed with - therefore the message you see when you try to login to the server console using that account.

By the way, which version of FOG do you use?

@hector-santiago Don’t you know the root password of the machine?

@pep On first sight this sounds like this is a last minute bug introduced when trying to fix a location snapin issue (commit b33e4d9).

Will work on fixing that in dev-branch soon!

I edit, it’s not downloading the snapin because the “http” is missing in the link. I assume it’s due to the variable $protocol that I modified on line 169

Too bad, probably because there is no default set on upgraded installs. ARGH

@ajm2358 said in How to delete a MAC address from a Host:

essentially I want to remove a pending Mac(s) from our host that deploys our image from the Fog server without deleting or removing that host or primary Mac.

Now that I think about it again, can’t you just click the check mark symbol on the right of that MAC address to approve it and make it appear in the list of secondary MACs for this host and then there should be a button to delete that MAC straight away.

If that doesn’t work you need to connect to the FOG server database and take a look at the hostMAC table. You should find the MAC(s) mentioned and can delete those rows.

Make sure you have a backup of the whole DB before messing with it and also I suggest you pay attention when deleting rows to match not just the MAC address field but also the host ID to make sure it’s the right entry you are going to delete.

@brakcounty Didn’t find the time to test on my side yet. Will do in the next days and let you know.

@dyacishyn Too bad. Hope you have a recent backup of the database and the images.

Marking as solved as we know what was causing the described issue.

@Tom-Elliott said in FOG kernels and inits moving to github:

Majority of the time the Inits are built one off for some specific need. No where near the frequency of the kernels needing to be updated.

I don’t think that’s true. We do bug fixes and add features to the inits way more often than once a year (when at least the buildroot update is to be done). Take a look at the last dozen or so fos repo commits.

@DC09 said in HP EliteBook 840 G9 - Cannot deploy image:

I will check on any available BIOS updates and if we have any MAC passthrough settings in the BIOS.

Did you check the BIOS settings?

@AlexPDX I suggest updating to the latest release 1.5.10 or manually update your kernel.

In the other hand I think @george1421 is totally right about the AHCI mode thing.

@brian-mainake Which version of FOG do you run? Are all the nodes on the same version?

@Wayne-Workman I think I did that back then already but forgot to mention it in the forums. See https://github.com/FOGProject/fos/releases

The releases named like “Latest from xx.yy.zzzz” are developer versions, the latest always used by the dev-branch and working-1.6 installer. If you install a version like 1.5.10 or 1.5.9 it uses the specific tagged release version named “FOG 1.x.y kernels and inits”.

Within the FOG web UI you see all those kernels and can manually switch to whichever you like.

Good you are bringing this up again because it’s still only the kernels you can change through the FOG web UI kernel updater. Would it be good to add the same feature for the FOS inits I am wondering??

@Sebastian-Roth said in ipxe boot slow after changing to HTTPS:

If the first test is instant but the second one is delayed we seem to have an iPXE issue - on the one hand I have never seen this on my HTTPS setups but also this is the most likely outcome from my perspective.

So this is what we are at right now, right?? And you tested this on different machines, VMs as well as hardware.

I will try to replicate the issue. If I can’t we should schedule for a debug session together some time next week.

@dyacishyn The end of the log file is just garbage. Any idea what went wrong? Maybe the disk is running out of space?

@ggoff1976 The whole PXE boot process consists of several stages with differnent software running. First iPXE and the Linux kernel later on. With some USB ethernet adapters the different stages see different MAC addresses. Please read about MAC pass-through on the web and see if that is of any help to you.

@ajm2358 You can delete entries from the DB manually though I am not sure this is what you ask.

Can you explain in more detail which host this MAC is associated to and why you want to remove it?

@brakcounty said in ipxe boot slow after changing to HTTPS:

wget: not an http or ftp url: https://fogserverip/fog/service/ipxe/bzImage

I have to admit that I have not tried it myself yet but I’d be pretty amazed if the wget binary we ship is not able to handle the HTTPS protocol. Anyhow, can you try curl -v -k https://fogserverip/fog/service/ipxe/bzImage instead?

kernel bzImage took about 3-4 seconds on hyper-v, 10 seconds on xcp, then returned with

Is this slower or faster than you see when PXE booting into a task?

I pm’d you a pcap

The first TCP SYN send by the client to open the connection should be answered by a SYN,ACK by the server but in the PCAP we see a simple ACK which wireshark tells us is “ACKed unseen segment” - like a packet from a different connection (but on the same ports!). This is very unusual! Then the client re-sends the initial SYN packet and gets a proper SYN,ACK back, returns an ACK to properly finish the TCP three way handshake.

Beside this strange behavior I wonder where the delay would happen. The first 9-10 seconds take for the DHCP DORA. The TCP handshake starts at 9.88 and goes straight into the SSL session setup. Between “Server Key Exchange, Server Hello Done” and “Client Key Exchange” there is a 2.5 second delay (caused by the client waiting) which I don’t find normal. Though I can imagine this is due to crypto algorithm calculations. The rest of the TCP communication looks to be fast.

@Trev-lchs said:

Would you know how easy is it to copy over the settings from the old fog server to the new one bearing in mind that they will be the same version. Or is better just to start again? I have lots of settings and groups etc etc.

Take a backup of the database (mysqldump) as well as all everything you find in /images and /opt/fog and you are good to go. With that in hand you can get FOG up and ready for production again in no time.

Actually you can already start the fresh install on a different IP address. Check to see if everything works. Then on migration day re-sync the files to the new server, ex/import the latest state of the DB, shutdown the old server, change the IP (find instructions on this in the docs or forums) of the new server to the one the old had and reboot.

@brakcounty said:

I was saying that the delay is exacerbated on VMs, especially slow (the slowest in fact) on XCP-NG guests. VirtualBox is better, physical is fastest.

Although I am not sure this is important I would say we better keep that information afloat in the back of our minds.

Ran from a console, instant. Still working on getting an accurate pcap.

Ok, we need to get back to that point then.

1. Please schedule a debug (capture or deploy) task for any machine you see this issue on. Start it up and hit ENTER twice to get to the shell.
   Then run wget --no-check-certificate https://fogserverip/fog/service/ipxe/bzImage and let us know if this is starting instantly or delayed.
2. In the FOG web UI go to FOG Configuration -> iPXE New Menu Entry and enter the following information:
   Menu Item: fog.ipxeshell
   Description: iPXE shell
   Parameters: shell || goto MENU
   Boot Options: leave empty
   Default Item: unchecked
   Hot Key Enabled: unchecked
   Hot Key to use: leave empty
   Menu Show with: Registered Hosts
   Now boot up a machine/VM having the issue, select the iPXE shell and run command kernel bzImage and once again let us know if this is starting instantly or delayed.

Outcomes:

• If both those show the delay symptom we are surely talking about a very crude network issue that is only seen in FOS/iPXE but not when the OS is booted - very unlikely. But if that’s the case you need to look into packet capturing as suggested before!!
• If the first test is instant but the second one is delayed we seem to have an iPXE issue - on the one hand I have never seen this on my HTTPS setups but also this is the most likely outcome from my perspective.
• If the first one is delayed but the second one gets an instant response - kind of impossible - then I have no idea and we need to re-think the whole case.
• And finally, if both tests yield in an instant response I would be puzzled as well. Then we’d need to dig into the differences between manual test and the normal PXE booting sequence.

@karim This is a known issue with the latest version and can savely be ignored for now: https://github.com/FOGProject/fogproject/issues/555

Mod’s note: Topic moved to bug reports.

@TheBuff said in PXE Boot help - Noob:

https://community.spiceworks.com/how_to/373-fog-server-install-free-opensource-ghost
Its a bit of an old guide …

Old? I’d actually call it antique.

I pxe boot them and they get an IP but nothing past that point.

Can you be more specific on what exactly you see on screen when this fails? Please take a picture and post here.

As well we need to know more about your DHCP setup. Sounds like you have an existing DHCP in your network and told the FOG installer to not setup DHCP service for you - which is fine.

So do you use Windows Server DHCP, infoblox, SOHO home router DHCP??

If you cannot add the DHCP options needed for PXE booting (66, 67) then you might look into using dnsmasq: https://forums.fogproject.org/topic/12796/installing-dnsmasq-on-your-fog-server