@janspook said in Could not start download:
Using the default one
Not helpful. Its like me asking you if you like coffee or tea, and you responding “yes”. Just kidding.
Look at the FOG chat bubble, I’ll send you links to the older ipxe boot files.
Rename the existing ones using the linux console commands. The files are in /tftpboot.
Then install these files there. I’m interested in seeing if the older ipxe boot loaders work correctly.
OK lets start out with some basics.
@uwpviolator Ah, sorry. I thought you were talking about my last post.
Well it sucks getting old, I didn’t use dism (after looking at the code) this is what I used to force the drivers in.
REM Inject any missing drivers for hardware discovered during oobe
forfiles /p "C:\Drivers" /s /m *.inf /c "cmd /c pnputil -a @Path"
@janspook I wonder if we can get a hold of ipxe from an earlier build and test that?
What boot file are you using? I still have 1.4.4. in my production environment. I’ll upload what ever iPXE boot loader you are using so you can grab it and test.
@uwpviolator Info?
What I saw was a contradiction between my settings
<component name="Microsoft-Windows-PnpCustomizationsNonWinPE"
and what Tom found in his first link
<component name="Microsoft-Windows-PnpCustomizationsWinPE"
The microsoft document said to use Microsoft-Windows-PnpCustomizationsWinPE which is counter intuitive to Microsoft-Windows-PnpCustomizationsNonWinPE from my guide. I have not had a chance yet to see of this location that Tom found actually works, being monday and all…
@janspook said in Could not start download:
:os.windows10
initrd nfs://10.0.2.15/images/os/windows/WinPE_amd64.iso
chain memdisk iso raw
boot || goto MENU
This looks good.
I wonder if nfs support was removed from iPXE.
@janspook Well that is interesting. All of the bits are in place, it should download. I guess I need 2 more things.
http://<fog_server_ip>/fog/service/ipxe/boot.php?mac=00:00:00:00:00:00 replacing the fog_server_ip with the real IP address. Please post the results in here as text.I’ve been loosely following this thread.
I can tell you a few things.
Routers by default do not forward ip class D (igmp) packets by default. You must specifically allow this on your firewall/router. Even if you have the screening rules in place some routers will not forward igmp messages.
Some routers require a igmp proxy service running. This service will function much like the dhcp-relay/dhcp-helper service. The igmp proxy service will listen on its upstream interface (the interface connected to the same subnet/vlan as the FOG server) and then rebroadcast the igmp stream to any device connected to its listening interfaces. The igmp proxy service will only forward igmp traffic if it has an upstream igmp channel and then a subscriber on its listing interface.
If you have an extended network (multiple routers between the fog server and target computers), you will need this igmp helper service on each router, with the defined upstream interface set towards the subnet where your FOG server is.
The igmp imaging process uses 3 igmp ports. 224.0.0.1 for control, 239.0.0.2 and 224.0.0.252 (I think ??) as the data channel.
@janspook That bit looks like its setup correctly. From the FOG server’s linux console will you post the output of this command:
ls -la /images/os/windows
This should confirm the iso image is located in the proper spot.
Can you provide a screen shot of the iPXE menu from the web ui?
@nexqs Yes those commands are OK.
I was going to have you check your current time and to ensure your timezone was correct and also see if you can ping keyserver.ubuntu.com which seems to be reported as a problem in your log file, but now we shall see how switching to english works. French should work because I know we have folks in France using FOG. I’m pretty sure its in their native language too.
@nexqs Now try to install FOG using the installfog.sh script. My french is a but rusty, but it looks like the offending ondrej/php library was installed.
Just for clarity, FOG is not a backup system (1 for 1). It is an imaging solution ( 1 to many). It may not be the best use case for your goals.
I can suggest if you ARE looking for a backup solution look at Veeam Agent (free). With this software you can backup your computer to a NAS and create a disaster recover boot drive. If your computer fails, you can boot from the boot drive, connect to your NAS and then recover your computer.
What makes Veeam better than FOG, is how it backs up your disks. FOG does a whole disk clone, where Veeam does a file level backup. Meaning that you can recover any individual file from the backup, where with FOG you would have to restore the entire disk just to recover one file. Veeam is really worth a look.
Will FOG run on a Raspberry Pi 2 or 3, yes. I have a FOG-Pi server setup in my home for development work. For a single capture or deploy it works well in a home lab setup.
@zacadams said in Multi-cast with Location plugin enabled:
Our network admins will only let us use multicast when imaging to machines in the building
Just for clarity, how many machines do you typically image at one time?
@tom-elliott said in Multi-cast with Location plugin enabled:
Location plugin will attempt to make the location nodes masters where possible.
In that you are able to multicast from a storage node as long as all clients are in the same location?
@tom-elliott said in Windows 10 driver injection doesn't install during sysprep:
@uwpviolator maybe this can help in general for everybody?
https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/add-device-drivers-to-windows-during-windows-setup
Interesting that one says to use WinPE instead of NonWinPE. That sounds counter intuitive, but if it works…
@uwpviolator I ran into the same issue when I was working on our 1709 image (which was put on hold for the moment). I ended up with a hack to use dism in the setupcomplete.cmd to load in all of the drivers in c:\drivers directory.
@zacadams I’m pretty sure you need a full fog server to have the multicast component.
FWIW, a full fog server can be a “storage node” in a storage group. Meaning you can have 2 full fog servers in the same storage group where once is configured as a master and one as a storage node (in the storage group). Your images will replicate from the master server to the remote fog server. The only issues and manual intervention would be to export the image definitions from the real master server and import them into the remote fog server. Understand this is an unsupported configuration but will work well as long as you don’t have a lot of new images on the master server because you will need to export and import for every new image.
FWIW, only master nodes can use multicast imaging. Unicast imaging can be from a master node -OR- storage node based on the guidance given by the location plugin. It is working by design.
Are the master nodes and storage nodes located at the same site?