Posts made by george1421

@rdfeij For the record, what computer hardware do you have?

@luilly23 To follow on with what luilly23 said. If you have the original 7010 from 10 years ago, that was the first version of Dell desktops that supported UEFI mode. BUT if you tried to pxe boot in uefi mode iPXE would hang at initalizing devices because of a bug in the Dell 7010 uefi firmware that was never fixed by dell. In this case you must use bios mode and undionly.kpxe to boot.

If you have the modern version of the Dell 7010 and it says no boot device found… The actual problem depends on where you see the error. I’m going to guess this error is when you first turn on the computer and tries to pxe boot. In this case your dhcp server is not sending an IP address or pxe boot info to the client computer. If this is truely the “new” 7010 then your boot file will be ipxe.efi or snponly.efi. If you put a functioning windows computer on the same subnet as your dhcp server, does it get an IP address? That will tell us if your dhcp server is working. Also with that windows computer verify what device is your dhcp server.

@MonsterKaos There are 3 issues (well really 4 issues) that is probably impacting your deployment.

1. You have really new hardware, but you are running an old version of FOG.
2. Your version of iPXE (the boot loader that provides the FOG Menu is old (this is probably causing the no connection methods.
3. Your version of the FOS Linux kernel (you haven’t got this far yet) is probably too old.
4. You are missing some of the enhancements to the FOS Linux OS that interface with NVMe drives. Just be aware if you have issues deploying to nvme drives you should probably upgrade to FOG version 1.5.10 and then upgrade to the branch version of 1.5.10. This is not a mandatory upgrade unless you have issues deploying your image.

For issues 2, I have instructions on how to compile the latest version of iPXE here: https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe Your fog server will need to have internet access to get the latest source code for iPXE. This should address the no configuration methods.

For issue 3, in the fog ui go to fog configuration-> kernel update. Download the latest kernel 6.x series to get support for the newest hardware.

Lets see where that works for you with deploying images.

@EuroEnglish I’m finding it hard to believe that there is a connection of having win11 on the computer that is causing this behavior. When the fog menus are being displayed, we are running iPXE boot loader. This in a way is an OS by itself. The OS on the target computer is not even known about at this point in the booting process.

The only thing I can think is that the format or disk structure is now allowing iPXE to fully initialize correctly.

Could you make this test for us? If you have 2 computers of the same model (make sure that bit locker is disabled on both systems) and secure boot is disabled.). One with win11 and one with win10. Verify they both behave the same way as you mentioned above.
On the win11 computer remove the hard drive/nvme drive. Boot into the FOG iPXE menu. Does it still have the slow speed?
Move the hard drive from the win10 computer to the win11 computer. Does the system act slow or normal?

@professorb24 said in How to use fog with two different VLANs:

Yes, I can ping the 192.168.54.X network.

This is positive. OK hopefully last question, what is device the dhcp server on the 54.x subnet? Is it the fog server on the 52.x subnet or something else?

@professorb24 from 192.168.52.X can you ping devices on 192.168.54.X. If yes then you have network routing setup.

Once you pass full routing, what is your dhcp server for 192.168.52.X and 192.168.54.X?

@RogerBrownTDL said in PXE TFTP File Not Found:

TFTP_DIRECTORY=“/srv/tftp”

OK then in this directory, is it blank? Different distros have different locations for the boot directory. I thought the fog installer created a standard but maybe not. If its blank, the most often cause is that you did not perform step 3 in the installer. Step 1 is to run the fog installer script, step 2 is to open a web browser to install the database, then in step 3 you return to the fog console and press enter to complete the install. This is the part where the tftpboot files are installed.

@RogerBrownTDL This condition could have several root causes, with some not FOG related.

First look to see if there is content in /tftpboot on the fog server. If that directory is missing or simply empty then you missed a step during installation (high probability)

The boot file option (dhcp option 67) needs to match the type of computer you are booting. For uefi computer it needs to be ipxe.efi or bios computer it needs to be undionly.kpxe.

If you are using a soho router for your dhcp server, many will send their IP address instead of the IP address you configured into the dhcp router. So what device is your dhcp server?

@professorb24 The quick answer is if both vlans are routable back to the fog server then yes.

If they are not, then no.

The FOG server can only support a single imaging interface. FOG is not designed to have multiple imaging interfaces.

@JJ-Fullmer said in Dell Latitude 3340 with USB-C Ethernet Adapter - bad mac address registered:

I am unable to get wol with or without fog on my lenovo laptop with the lenovo branded usb-c ethernet adapter.

Is the computer powering off the network adapter in sleep mode or keeping it active?

I know WOL from anything other than g3 mode and windows is involved (i.e. s1-s4 has some kind of windows os interaction). So the windows OS needs to leave the power on the nic to be able to be woke up from these modes. Windows is a fickle beast.

@Nicolas-Bricet This really sounds like a spanning tree issue vs dot1x authentication (unless your authentication process is taking a really long time to authenticate the port). Make sure the port is configured for port-fast, fast-stp, rstp or whatever your switch manufacturer calls it.

Secondly if TIME is the resolution then this can probably be addressed too.

First of all we have the ability to update the iPXE boot loader from a fog install. This tutorial is intended to solve a different problem but you will need this in your solution: https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe

So at this point you know that you can rebuild iPXE right from your fog server. Now we need to adjust iPXE to wait 30 seconds before requesting an IP address (FWIW, by default spanning tree it take 27 seconds to start forwarding data, so the timing is suspiciously similar).
When iPXE boots up it runs a FOG custom script file that tells iPXE how to configure itself. If you can remember back to the DOS days, this was the autoexec.bat files function. iPXE has a similar script. Within the iPXE source directory the file is call ipxescript (a look on github) https://github.com/FOGProject/fogproject/blob/a4bb1bf39ac53c3cbe623576915fbc3b5c80a00f/src/ipxe/src-efi/ipxescript#L1 This is the script that runs inside iPXE to configure the network.

To take this concept one step more, the FOG developers have already created a version of the iPXE that has a 10 second boot delay (remember you need a 30 second delay). An example of this 10 second delay startup is here: https://github.com/FOGProject/fogproject/blob/a4bb1bf39ac53c3cbe623576915fbc3b5c80a00f/src/ipxe/src-efi/ipxescript10sec#L3 All you need to do is either update that 10 to a 30 or copy that line over to the ipxescript main script and change it to 30. Once that is done recompile ipxe using the instructions above.

The FOG delivered 10second delay versions of iPXE are located in the /tftpboot/10seconds directory. So you have two paths to get this done, but I would surely look into spanning tree first to make sure port fast is enabled and make the above second way unnecessary.

@plegrand said in upgrade Debian 11 to 12:

127.0.0.1:9000

This is the communication port that apache talks to php-fpm (PHP Execution Engine). For some reason during the update php-fpm was not updated or failed to restart correctly.

Well done getting this resolved on your end.

@pcnr said in Deployment questions (language, skip configuration):

I’m not using the unattend.xml, I probably missed that part following the Fog documentation, I’ll give it a try!

Just be aware this is a MS Windows feature, not a fog specific feature. The unattend.xml file is the standard way to pre answer all of those questions that the OOBE/WinSetup program asks.

As for the second question you also do that by the unattend.xml file.

The fog client can do only the basics of give the computer a name and connect it to the domain. You really need the unattend.xml file to set keyboards, languages, and location specific information.

With that said you can dynamically adjust the unattend.xml file using a FOG post install script with run time settings. I have a code snippet here of a FOG post install script that will update the unattend.xml file with run time settings: https://forums.fogproject.org/topic/7740/the-magical-mystical-fog-post-download-script/15?_=1718638396511 And then in part 3 of that article I set location specific values based on the deployment IP address. This is a complex subject if you are not currently using an unattend.xml script. I just wanted to show you what is possible when you get to that point.

@Envy said in Help Required: Debugging PXE Boot Error on Mixed-Environment Network:

Problem: Some of our UEFI computers fail to obtain an IP address during PXE boot attempts, while others appear to continue but finally clock out with a “No configuration methods succeeded” error.

First since you have a mix environment I would start with setting up your dhcp server to send both bios and uefi boot files: https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence#Using_Windows_Server_2012_.28R1_and_later.29_DHCP_Policy

Second the no configuration methods succeeded and not getting an IP address sounds a lot like you have the default spanning tree configured. Where you should be running one of the fast spanning tree protocols like port-fast fast-stp, rstp, mstp, or what ever your switch mfg calls it. A quick test is to put one of those cheap 5 port unmanaged network switches between the pxe booting computer and the enterprise switch. If that fixes the problem then talk to your network admins to enable one of the fast stp protocols on all network ports where you have clients that need to pxe boot. Understand this is an infrastructure issue and not specifically a fog issue.

Also make sure you have the latest version of FOG installed or at least recompile ipxe to the latest version: https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe

But I think I would work on the first two issues I mentioned first. Your network troubles really sound like the second issue I mentioned.

@pcnr You need to use a windows unattend.xml file for what you want to do. This is a windows specific function and not related to FOG.

Here is a post by @Florent that describes the format of the unattend.xml file. In it you can set the natural language and other local settings.

When I was working for a multi national company we had one golden image that we deployed across the world. I had some FOG post install scripts that would dynamically update the unattend.xml script based on what country we were deploying the standardized image in. So it is possible to do.

This may be hard to understand but what I would do is deploy the US English version of Windows. That way all of the file paths are consistent across your deployments. This will help you with scripting because the file paths will be the same no matter where the image is deployed. Then to localize the windows install use windows language packs to set the language as well as the localized keyboard via the unattend.xml.

If you use the unattend.xml 100% I would say you don’t need to install the FOG client on the target computers. The unattend.xml file can rename the computer, connect it to the domain as well as install programs. In our deployments we didn’t use the fog client at all. If you are uninstalling the fog client post deployment then you are not using any of the management functions of FOG. So why install it?

@renewedharry

I’m sure some of these parameters are not relevant as I don’t really know what I’m doing,

It looks like you are doing very well.

I can add a little context as in the kernel parameter loads the linux kernel. The initrd commands load these image files onto a virtual hard drive created by iPXE so the kernel can locate them. The .img files would actually be mapped as hard drives to the kernel. The kernel would know how to connect to them and use them.

As for the imgargs these are flags for the kernel as it boots. The different flags tell the startup scripts in the kernel how to react dynamically to the external environment. The alternative would be to build the flags into the kernel, but then you would need to recompile the kernel every time you wanted to make a change. Hint: kernel args are the way to go.

I don’t see much room for improvements with this design. You are currently using http to transfer the boot files. Once the kernel starts up then iPXE is out of the picture. I’m going to suspect most of the slowness is because most of the files are the pmodules directory. iPXE should load bzImage, initrd.img, fu.img and m.img very quickly. Where most of your time is probably once bzImage starts to boot. Then you are at the mercy of what Parted Magic does.

Parted Magic version from May 2023

Please see this article posted by @renewedharry

https://forums.fogproject.org/topic/17498/successfully-booting-parted-magic

@Fog_Newb Have you tried to take a current 6.x fos kernel with a current init and put them on the usb stick and boot? Maybe the current kernel work out of the box. To get the 4.19 version of the kernel to boot I had to patch it with the T2 patches they had at the time to make imaging work with the T2 chip enabled.

@pbriec From the FOG web ui -> FOG Configuration -> Kernel update. It should tell you the current version and what is available. Download both the x64 and x32 bit version for the latest version of the FOS Linux kernel.

@mashina Its been a while since I worked with multicast, but for the switches, you may need to enable igmp snooping on each switch for the vlan where you are going to send multicast packets through. The ports are dynamic because each multicast stream use their own ports on the same class D address.

All of the devices meet at a well known (rendezvous) address and then jump to the assigned data channel address.

For multicasting its more of a art than a science. I would start trying to multicast to one system on the same switch as the fog server. Confirm that it works there first. That will ensure that everything is configured correctly on the FOG side (FOG should come preconfigured so it should work out of the box).

If your fog server has more than 1 nic card, you will need to create a static route to tell your FOG server which network interface to use to send multicast data streams.