@george1421 Thinking about this a bit more, lets have you run through this tutorial to rebuild iPXE to the latest version. https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe?_=1696626440791
I can’t say it will work (the act of rebuilding) with 1.6 since its been several years since I last installed it. But lets see about rebuilding iPXE and that might get you past that error message.
@jmeyer I would not consider fog 1.6.0-alpha for any type of productive use. While it has been kind of kept up in sync with the 1.5.x series it really hasn’t had much love in about 2 years.
IMO it really needs to get pulled until the developers can spend time with it working out its issues or they can get additional resources to spend time with the version.
@Gcostiou Ok if you solved the problem then its done. Just be aware that you can get fog installer to work through a proxy server if needed. By default the fog installer doesn’t know about the company firewall.
@garrett-stevenson said in Could not download init.xz:
Securly for our webfiltering
Do you have a on-prem proxy server that you need to configure your browsers to use?
@Gcostiou For installation your FOG server needs internet access and to be able to resolve DNS names like www.fogproject.org for the installation to work. Its failing to download the recompiled binaries from the github repo.
@DARUN974 Just be aware that FOG doesn’t create any uefi boot manager entries. Those entries can be added programmatically but the OS does that not FOG.
If by chance you wanted fog to create those entries you would need to create a fog post install script and use the linux bootmanager command to add those entries. The point is they are not automatically created by FOG.
@skyborne98 Lets see if this document will answer your questions: https://docs.fogproject.org/en/latest/management/web/storage-node/
@baovipboy156 said in Golden image problem:
install a fresh window 10 using MDT/WDS
update window, update all application,…etc
sysprep using unattend file
capture image using fog
This is the process we’ve used for years. I think we were at about 12 minutes from bare metal to first login. So it shouldn’t take 30 that’s abnormal.
Here is a copy of my sanitized unattend.xml file: https://forums.fogproject.org/topic/11920/windows-10-1803-sysprep-problem/6
Just glancing through yours it looks complete but I didn’t go over every line,
@Yanni That is typically a setting in the bios to set the boot order. When windows installs, it thinks it knows better and changes the boot order for you to have hard drive first. But I don’t think I seen it with pxe booting first in the order it only pxe boots without the hard drive.
@baovipboy156 said in WDS and Fog with Syslinux - Need Help!:
some how the network card only use 100mbps of 1Gbps,
Its probably best of you open a new thread since the issue it not related to the topic of the thread.
But in general WDS/MDT is a file level imaging solution, where FOG is a block level imaging solution. The file level solutions are more flexible and deal with deployment time decisions. But they are slow(ish). About 45-60 minutes bare metal to fully deployed. Where fog is a block level imaging deployment. Not flexible for deployment time conditions, but deploys super fast (~6GB/min), with a 25GB image taking just over 4 minutes to first OS boot.
Same task different tools, different results. Each tool has its strengths and weaknesses.
@boros said in WDS and Fog with Syslinux - Need Help!:
This is what should go into the Fog custom Menu right?
Yes fog custom menu akin to how the tutorial I linked worked. It goes in the parameters block
Do I need to create NFS shares on the WDS or Fog side?
You don’t need to create nfs shares anywhere. If you have dhcp setup right it will pxe boot to the FOG menu, then from the fog menu you will chain to the custom menu which will load and boot the WDS boot loaders.
Again be aware that the WDS server has a netboot service that you need to stop or you will never get to the FOG iPXE menu. You can do all of this via the FOG web ui. There is no need to hand edit files like with syslinux.
@Yanni That isn’t exactly what I asked for, but it does tell me what I suspected. See the target computer at .10, its trying to tftp the boot file from your firewall and not the fog server. If you set your capture filter (not display filter) to port 67 or port 68 it will only pick up the DORA communications. You want to look at the offer packet, my bet is the firewall is setting its own IP as the boot server. Your picture kind of shows the results of what I’m saying.
If you have a misbehaving soho router, we can fix that by installing dnsmasq on your fog server to override what your dhcp server is telling the client to do.
@boros said in WDS and Fog with Syslinux - Need Help!:
So I would have to remove the syslinux files from WDS?
Well WDS has its own netboot option that uses a proxydhcp server. You will need to stop this service since it overrides options being set by dhcp options 66 and 67.
The idea is that you would boot directly into the fog iPXE menu and from there if selected boot into WDS. The following command should boot from fog into WDS. But be aware I have not tested it only glued the bits together. You would need to change the 192.168… IP address to the IP address of the wds server.
set wdsserver:ipv4 192.168.1.12
set net0/next-server ${wdsserver}
iseq ${platform} efi && set bootfilenam Boot\\x64\\wdsmgfw.efi || set bootfilenam Boot\\x86\\wdsnbp.com
chain tftp://${wdsserver}/${bootfilenam}
@Yanni Well lets see if we can find the problem. I have a good idea, but lets see if we can find it.
First while this isn’t “the” problem it might cause you an issue.
Do you know how to use wireshark? If yes then configure a boot filter of port 67 or port 68 . Have your wireshark computer on the same subnet as the pxe booting computer and start wireshark. Now pxe boot the target computer until you get the tftp error. Stop wireshark. You should have a Discover, Offer, Request, Ack packet DORA. Look in the Offer packet from your dhcp server, in the ethernet header there should be a next-server and then boot-file values. That should be the fog server’s IP address and undionly.kpxe. Now look into the dhcp options, dhcp options 66 and 67 should be set correctly. I have seen firewalls ignore the boot server info and always put the firewall’s IP address in for the boot server. I suspect that is the problem here.
If you don’t have/know wireshark then you can use this tutorial to collect the pcap using the fog server: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue?_=1696275644673 You can then post the pcap to a file share site and either post the link here or DM me using FOG Chat and I will take a look at it.
@kalafina The last line of the apache error log looks interesting. Error dispatching … index.php. That is the home page of the fog server. But why is it having an issue.
When you installed fog there are 3 steps. Install fog using the console on the linux server, go to the web ui and install the database and then go back to the fog server console to complete the last steps in the install. Did you do all 3 steps? If no or not sure rerun the fog installer and it should fix things. There is something abnormal with your current install.
@kalafina OK it looks like you have all of the parts in place. The next thing you should look at is in /var/log directory. Look in the apache2 folder for any error logs that might be helpful to tell why apache isn’t happy, as well as in the php-fpm directory for the error logs there too. Something has to be reporting a problem that not being sent to the browser.
@kier056 What values do you have defined for dhcp option 66 and 67 on your dhcp server?
@kalafina Is this a new install of FOG?
The FOG web site is powered by php. Make sure php is installed as well as a service called php-fpm and its running. Also make sure there are files in /var/www/html/fog directory.
@boros Is this possible to do, probably yes.
There are a few approaches you can do depending on how comfortable you are with syslinux.
Lets get some common terms here.
FOG uses a boot loader called iPXE. Syslinux is al alternate to iPXE. What you can do with syslinux you can do with iPXE. iPXE has two boot loaders depending on the firmware version of the target host. For bios computers the boot loader is undionly.kpxe and for uefi its snponly.efi or ipxe.efi.
So if you still pxe boot with syslinux, you will have to chain load ipxe from your fog server from syslinux.
An alternate is to pxe boot into FOG using ipxe and then call WDS from a custom fog ipxe menu and do away with syslinux since ipxe will be doing that function. I have a tutorial here on how to pxe boot into different OS installers from FOG: https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images
The structure of a syslinux config file is similar to iPXE so its possible to translate the formats and commands between the two different boot loaders.
@jfernandz Will you provide a screenshot of the error? I’m thinking this error is coming from FOS Linux (not the fog server host OS), but not sure what its doing to require the lock file.