@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?
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.
@Tom-Elliott said in Dell Latitude 3340 with USB-C Ethernet Adapter - bad mac address registered:
posted a different init.xz image file, I don’t know if that file is still available.
I can confirm that the file still exists.
I would have hoped that the later kernels would support mac pass through by now.
@1337darkin My initial reaction is don’t use virtual box, my second thought is don’t use virtual box…
The thing is that vb uses iPXE as its own internal boot loader, and the issue is chaining with FOG’s version of iPXE. The screen shot you show is VB’s version of iPXE running trying to call snponly.efi where its failing. This is an issue with VB and not specifically with FOG.
I think there is a fix for this but I can’t seem to find it at the moment, google-fu is weak today.
On a totally abstract note. You can capture a uefi image with FOG in bios mode. And on the flip side you can capture a bios disk image in uefi mode. BUT to be able to boot that image after image/deployment the target computer’s firmware needs to match the disk image.
@hwa I’m not a parted magic user or have knowledge of. But can you point me to the iso you are using? I probably can convert a grub or syslinux config file into iPXE format.
@llino said in Configure iVentoy as netboot-Option in boot menu:
i’m thinking of adding another virtual Network to the to my fog server so I can run iventoy
Just be aware that FOG was not designed to have 2 imaging network interfaces. So it will be difficult to have fog respond to both subnets independently.
@youzersef I don’t have an immediate answer for you, but I can point you in a direction. The FOG Project has a wiki page on how to setup policies in windows dhcp server. The first section of your code is outlined in the policy. https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence
You might be able to do the user class part too, but I don’t know. Windows dhcp server policies are very similar to what you can do in linux.
@enginbey8108 If you don’t have an unattend.xml file to start with you can always use an online generator to give you an initial configuration file. You can use the one here: https://www.windowsafg.com/win10x86_x64_uefi.html
@youzersef said in add Ventoy to boot menu:
if you want i can post the configuration that i used to configure iventoy as next server after fog server
If this info would help the next guy, I would say yes. That way we can all learn from someone that has already walked the bloody path to victory. That’s what makes opensource and a community lead project work.
@youzersef Understand I’m just making some guesses here because I don’t know ventoy. But if you look at the ventoy document link I provided. There is a section that talks about a drop down list on the configuration page where you need to change the dhcp server mode to ExternalNet.
The second thing is it looks like they are running a customized version of iPXE (same thing fog uses as boot loader) but its qualifying the name and it doesn’t like ipxe.efi as the file name because its not its own app. I think this is why the error is being thrown.
@youzersef OK I find a few things. I still think we can make it work.
ref: https://ipxe.org/settings
To call microsoft wds server
set netX/next-server 192.168.1.2
set netX/filename boot\x86\wdsnbp.com
chain tftp://192.168.1.2/boot/x86/wdsnbp.com
translated
set newserver:ipv4 10.xy.xy.113
set newbootfile iventoy_loader_16000_uefi # I will explain later
set net0/next-server ${newserver}
set net0/filename ${newbootfile}
chain tftp://${newserver}/${newbootfile}
Now to the ${newbootfile} , why did I pick that file name? From this document: https://www.iventoy.com/en/doc_ext_dhcp.html It appears that they can use dnsmasq for auto boot file identification, based on they say how external mode works. What we want is to use “ExternalNet Mode” in this case we will let iPXE decide what boot file to use. And then instruct the client to boot the proper file. So when you use the code from above, you must test with a uefi based computer. Right now I want to see if you can boot into iVentoy. We can work on the next steps after we can verity we can chain into their app.
I think its possible to use this software we just need to find the right path.
There is another ref site that I’m just logging here but I think the above is right since it from the ipxe developers directly.
https://www.rcannings.com/pxe-chain-loading-from-pxelinux-to-ipxe-and-back-again/
@youzersef said in add Ventoy to boot menu:
what do you see in the boot gui is the ip adresse of the dhcp server.
What my confusion is if .1 is the dhcp server, why is iVentoy using that server to download ipxe.efi from? The .1 server should be referenced. If I saw .62 or .113 that might be understandable, but not .1.
Is your dhcp server a soho router? And for FOG are you using dnsmasq to make FOG boot correctly?
Also is this iVentoy app open source where I can see the ISO contents?
@abolajioriola Well this makes no sense at all. Same model and same firmware and same FOS linux kernel they should act the same.
If you have one laptop you know that works and one you know not work we can try to figure out the differences.
It will take some work on your side to get me the info I need. Its not hard but has a few steps.
First start with one or the other, for this discussion lets use the no working keyboard. Take that computer and schedule a deployment task to it, but before you hit the schedule task button, tick the debug checkbox. Now schedule the task (no worries we will not deploy anything at this time). Now pxe boot the computer, you should see several screens of text you need to clear with the enter key. Eventually you will be dropped to the fos linux command prompt.
This next part will make your debugging a bit easier. We will enable you to connect to the FOS Linux (target) computer over the network.
passwd give it a simple password like hello. Since we are discussing the not working keyboard, you may need to use an external keyboard here. It will be interesting to know if you can type on the not working keyboard at this point.ip a sFrom the ssh/putty shell to the target computer key in and copy out the following.
uname -a
lspci -knn
Copy those results out and post in this thread. Next use WinSCP/scp program to remote into the target computer and download the file /var/log/syslog to your computer and rename it to not_working.txt Post the results in this thread.
Now do the same with the other computer (working one) and post the results here. I will review the information and see if I can identify what is or isn’t working between the two.
Now finally you will need to go into the fog server and tasks and purge the two tasks related to these computers.