Posts made by george1421

I found my notes on this. This one is for BIOS mode. I used the nfs protocol instead of tftp. Both will work. You just have to place the files in a different location based on the protocol.

kernel nfs://${fog-ip}:/images/os/mswindows/wimboot gui
initrd nfs://${fog-ip}:/images/os/mswindows/10-1607/bootmgr.exe bootmgr.exe
initrd nfs://${fog-ip}:/images/os/mswindows/10-1607/boot/bcd bcd
initrd nfs://${fog-ip}:/images/os/mswindows/10-1607/boot/fonts/segmono_boot.ttf segmono_boot.ttf
initrd nfs://${fog-ip}:/images/os/mswindows/10-1607/boot/fonts/segoe_slboot.ttf segoe_slboot.ttf
initrd nfs://${fog-ip}:/images/os/mswindows/10-1607/boot/fonts/segoen_slboot.ttf segoen_slboot.ttf
initrd nfs://${fog-ip}:/images/os/mswindows/10-1607/boot/fonts/wgl4_boot.ttf wgl4_boot.ttf
initrd nfs://${fog-ip}:/images/os/mswindows/10-1607/boot/boot.sdi boot.sdi
initrd -n boot.wim nfs://${fog-ip}:/images/os/mswindows/10-1607/sources/BOOT.wim boot.wim
imgstat
boot

I have not tested this, but a quick file change and this should work for UEFI. Also for uefi booting, you must send the ipxe.efi iPXE boot kernel. You can not boot into uefi mode from undionly.kpxe boot kernel.

kernel nfs://${fog-ip}:/images/os/mswindows/wimboot gui
initrd nfs://${fog-ip}:/images/os/mswindows/10-1607/bootx64.efi bootx64.efi
initrd nfs://${fog-ip}:/images/os/mswindows/10-1607/boot/bcd bcd
initrd nfs://${fog-ip}:/images/os/mswindows/10-1607/boot/fonts/segmono_boot.ttf segmono_boot.ttf
initrd nfs://${fog-ip}:/images/os/mswindows/10-1607/boot/fonts/segoe_slboot.ttf segoe_slboot.ttf
initrd nfs://${fog-ip}:/images/os/mswindows/10-1607/boot/fonts/segoen_slboot.ttf segoen_slboot.ttf
initrd nfs://${fog-ip}:/images/os/mswindows/10-1607/boot/fonts/wgl4_boot.ttf wgl4_boot.ttf
initrd nfs://${fog-ip}:/images/os/mswindows/10-1607/boot/boot.sdi boot.sdi
initrd -n boot.wim nfs://${fog-ip}:/images/os/mswindows/10-1607/sources/BOOT.wim boot.wim
imgstat
boot

Just be aware these instructions will NOT boot "Windows 10 ISO via UEFI" so you can install WIN10 as in the OP's question. The only way I found to boot the win10 ISO so you can install Win10 is by using the link I posted previously.

This is untested but should be pretty close.

kernel tftp://${fog-ip}/wimboot gui
initrd -n bootx64.efi   tftp://${fog-ip}/boot/bootx64.efi                 bootx64.efi    
initrd -n bcd           tftp://${fog-ip}/boot/bcd                         bcd
initrd -n boot.sdi      tftp://${fog-ip}/boot/boot.sdi                    boot.sdi
initrd -n segmono_boot.ttf tftp://${fog-ip}/boot/fonts/segmono_boot.ttf   segmono_boot.ttf
initrd -n segoe_slboot.ttf tftp://${fog-ip}/boot/fonts/segoe_slboot.ttf   segoe_slboot.ttf
initrd -n segoen_slboot.ttf tftp://${fog-ip}/boot/fonts/segoen_slboot.ttf segoen_slboot.ttf
initrd -n wgl4_boot.ttf tftp://${fog-ip}/boot/fonts/wgl4_boot.ttf         wgl4_boot.ttf
initrd -n boot.wim      tftp://${fog-ip}/boot/boot.wim                    boot.wim
boot

It relies on the files existing in the /tftpboot/boot directory.

@arnaudrigole I have seen uefi boot for windows winpe before.
This structure is close. But I think you use bootmgr.efi and bootmgfw.efi instead of wimboot. I’m trying to see if I can find the instructions. There are also more initrd lines since some fonts are also needed. I had that all in the post I linked, but removed them when booting that way did not help me install windows.

kernel http://${fog-ip}/fog/boot/wimboot
initrd http://${fog-ip}/w10x64/boot/bcd BCD
initrd http://${fog-ip}/w10x64/boot/boot.sdi boot.sdi
initrd -n boot.wim http://${fog-ip}/w10x64/sources/boot.wim boot.wim

I can give you a few bits of advice here.

1. What you posted above is for bios mode, you do need to send the uefi equivalent files to the target system.
2. Even if you do send the right files and the boot.wim file, that is only the boot.wim for the winpe environment. You won’t be able to access the .sdi (I think) files that contain the win10 image to deploy.

At the moment this is the only way I found to install win10 from a pxe boot. You need to create and send a custom winpe environment via pxe that connects to a network share. From there you can install win10. Its kind of a cheat, but it can work. For full disclosure I have not tested this in uefi mode. So I can’t say for sure if it will fit your situation.

https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images/7

@lof Can you get a clear video of what its doing wrong?

What IP address do you see? Is it something from this server’s past?

FWIW, the .fogsettings file is only updated when the fog installer is used.

Ah, I found it.
https://github.com/FOGProject/fogproject/blob/master/src/ipxe/src/ipxescript

the iPXE kernel has a script built in, the last line of the above link is the answer.

chain tftp://${next-server}/default.ipxe

So the dhcp server (or dnsmasq) is telling the iPXE kernel where to go next. So check your ltsp.conf file to see if there is an old address in there.

@george1421 Instead of me offering to be lazy, here is what you will need.

@Echo Off
start /wait msiexec.exe /i FOGService.msi /quiet USETRAY="0" WEBADDRESS="192.168.1.53"
net start "FogService"

@chris-whiteley If you need the MSI command line switches I can dig them up.

There is a path for you that is pretty close to what you ask. But you will need to use a second tool. Install PDQ Deploy (free) version. Using PDQ Deploy and a domain level account, install the FOG MSI on all 800 computers. PDQ Deploy can deploy to computers based on a list, or OU assignment. The package you will create will install the fog client msi with the proper command switches to instruct the fog client on how to find the FOG server. Probably for this task you will actually create a batch file to package along with the msi file to install the msi file then start the fog service using the sc command. The advantage of PDQ Deploy is that you will get an immediate feed back on the systems where the msi was installed and systems where the msi was missed (like the computer wasn’t on the network at the time of deployment). You can then reschedule a deployment to the failed systems. It really is an excellent tool

Now when the fog client starts reporting into the FOG server, the clients will go into a pending state on the fog server. You will need to approve these clients and then they will become registered in FOG.

I do have to say the paid for versions of PDQ Deploy and PDQ Inventory is well worth the minimal cost of the tools especially if you want to create software compliance rules (something fog does not do).

@dorvak Here is a similar thread that discusses the same issue and the commands needed to disable it: https://forums.fogproject.org/post/102522

Review the posts by @THEMCV they are enlightening.

If bitlocker is enabled, FOG can’t read the ntfs information so it uploads it with RAW mode. Also if bit locker is enabled, when you deploy the image to a second computer it will not boot because the tpm key is different. You must disable bitlocker and unencrypt the drive before imaging to have a happy win10 image. Then after the system has been deployed you can reenable bitlocker and drive encryption.

@jgallo We must be aware of a few things here.

1. The github site always contains the latest release. So (currently) the files contained are for FOG 1.5.0. If you are working on a down level version of FOG then you need to take the route of extracting the inits. You don’t need to repack the inits, because you only need the file you want to tweak. Once you have the file you want to patch, then you may unmount the loop directory and remove the unpacked init.
2. The structure of files may change from release to release. In the case of FOS, it was split out into its own branch. The correct path (as of 1.5.0) to the file in question is: https://github.com/FOGProject/fos/blob/master/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog.man.reg (full disclosure, it took me a bit to find the right path too).
3. The only caution is as newer versions of FOG are released, your patch file may become stale, where you might need to update a newer versions of fog.man.reg as newer versions of FOG are released. The risk is that you might be applying an older version of fog.man.reg over an updated version fog.man.reg breaking FOG without a clue why.

The rest of the instructions by @JGallo are still accurate (at least for 1.5.0). You can still use the post init scripts to “patch” the current FOS image as in the original post.

OK we may need to get the developers to look at this.

Can you provide this additional information.

1. Win10 version (i.e. 1703)
2. Win10 edition (i.e. edu)
3. Windows Location (country/region) setting (i.e. us)
4. Keyboard Language (i.e us)

If you copy the snapin pack to the target computer, unzip it and run the installer command locally does it install correctly? I’m interested in seeing if the issue is with the application (like an install time switch is missing) vs the FOG snapin system.

I have to tell you that 1.2.0 is about 4 years old and is no longer supported by the developers. The latest version of FOG is 1.5.0.

From your error:

Kernel panic - not syncing: VFS: unable to mount root fs on unknown-block(1,0)
Kernel Offset: 0x0 from 0xfffffffff81000000 (recolocation range 0x… …fff)
—[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)

This tells me that the kernel you are using (bzImage) is not the same version as required by the virtual disk (init.xz). In simple terms the kernel (bzImage) can’t connect to the vhd (init.xz). Did you happen to update the kernel for FOG 1.2.0 with the newest kernel intended for a later version of FOG?

I can also tell you we’ve seen this error message with newer installs of FOG (newer than 1.2.0) if the FOG admin uses the ipxe boot file defined in dhcp option 67, of ipxe.0 (or any .0 file) instead of undionly.kpxe.

Lastly this error message “i8042: No controller found”, is only a warning and not an error.

@lof Does undionly.0 already exist?

I can tell you no matter which way I type in the ln command I always get the parameters backwards. So I’m not the best at first time right. The ln command should be ln -s /path/to/sourcefile /path/to/symlink so your example looks right. You might have to use sudo for your OS to create sym links if the destination sym link doesn’t already exist.

@lof Wayne is right, both are in /tftpboot. That is where you need to create the symbolic link between undionly.kpxe and undionly.0 (note the name change from before) as well as ipxe.efi and ipxe.0. Then in your config file for dnsmasq you only include the base names of undionly and ipxe not with the extension. Its a quirk with version 2.75 and older that you have to accept.

Also note the i386 directory is for 32bit efi images. Those systems are not very common any more. Many of the early Apple systems were 32 bit only uefi requiring special boot kernels.

@fox134 So if you are at the screen where you entered ifstat, it would be interesting to know what would happen if you keyed in the following commands, of course localized to your network.

  set net0/ip 192.168.0.100
  set net0/netmask 255.255.255.0
  set net0/gateway 192.168.0.1

And then see if you can ping something on your local network

ping 192.168.0.51

The issue is here, that you had network connectivity to get this far. Why not now. It should be working, ifstat shows the link is up (has link connection) but nothing coming in from the switch.

@wayne-workman

Hey Wayne:

There ARE specific use cases for broken bios/firmware. But even with the USB boot sticks you still need to have dhcp services on your network.

@natlanis IGMP Snooping is only for the switches. This function the switches will listen for igmp (multicast) subscribe messages from the target computer and then send the traffic to a corresponding igmp offer device. This is done to avoid sending the multicast stream to all network ports. With igmp snooping it improves the efficiency of the network by only sending the multicast stream to the computers that request it and not everyone.

So that is half of the issue. The other part is your vlan router is not forwarding igmp messages across the subnets. This is typically off by default. Other vlan routers need a help service much like dhcp needs a helper service to listen and forward broadcast messages across the vlans. The dhcp service is called dhcp-relay or dhcp-helper. For IGMP its typically called igmp-proxy. Without that igmp proxy service your multicast signals from the target computers will not make it to the FOG server.

I did write a tutorial a while ago about using pfsense as the vlan router to forward the igmp messages between the subnets: https://forums.fogproject.org/topic/10117/fog-casting-across-vlans-subnets

I have to ask the question why no dhcp on this network? Is there a technical or regulation requirement for no dhcp? FOG needs dhcp server to send out the needed boot information. That is a requirement.