Testers

@rotoi Are you still running fog 1.3.3? More specifically you updated the kernel to something more modern, but have you touched the init.xz file? FOG 1.3.3 doesn’t (shouldn’t fully) support NVMe drives. The NVMe protocol wasn’t created until much later than FOG 1.3.3. Its akin to trying to install Windows 95 on an 11th gen laptop. It would kind of work, but not really well.

@lcsmd I see it has you have 2 different issues at the moment.

1. The mac address is changing between iPXE and FOS Linux.
2. The image transfer stalling out loading bzImage (FOS Linux kernel).

You are able to get iPXE to boot so your chromebook has an i86 compatible processor in it (in the era of ARM you always have to ask).

Lets tackle the mac address thing first since hopefully that is the easiest. We have seen this in the past where the firmware bios has an option switch for “mac address pass through” This is where the laptop doesn’t have a physical network adapter, but contains a mac address for the physical adapter. The idea is that the built in mac address would overwrite what is in the USB dongle making the device have a unique mac address even if you are using a single dongle for all of your device. This is great and exactly what we would want in an ideal world. FOS Linux’s driver understands this pass through uefi request and honors it.

The problem comes in at the iPXE level, its drivers are not as advanced as linux so it only sees the mac address of the dongle and not the pass through address built into the tablet.

@jonhwood360 said in Feature Request for FOG 1.6.X - Add image integrity verification check:

Exactly, although I’d like to have the option for the algorithm used for the hash be user defined. I know some people may want Sha512, where as for some MD5 is sufficient for this purpose. A default of sha256 probably would be good as its more than the minimum (md5) but not as intense as 512.

I think the cryptographic method is a bit irrelevant in regards to its “bit” complexity. What is important that we can create a hash (fingerprint) of each file as fast as we can to keep up with the imaging process. We are not actually looking to encrypt the image file, but just get a fingerprint of it so we can tell if it has been changed. If we use md5, the linux OS has an external command called md5sum and shasum. These would be preferred instead of the FOG developers having to create their own hashing code. shasum does have a command line switch to set the cryptographic algorithm. So IF sha was selected as the fingerprint protocol then it would be possible to create a FOG setting to pick the algorithm (speaking ignorant of the code required to do such). The linux shasum code supports these methods: 1 (default), 224, 256, 384, 512. The only gotcha I can see is that FOS Linux (the OS used to capture and deploy images) needs to have support for the shasum command. I know it has md5sum, but not sure about shasum.

@tom-elliott There was another request along the same lines where the OP wanted to create a md5 hash of each of the captured image files so he could track if the files were corrupted.

I was able to find the thread here: https://forums.fogproject.org/topic/15133/md5-after-image-capture

@b_man There is an option to power off the machine after every execution of FOS Linux (registration, capture, deploy) but its global and not specific to just registration.

But from my standpoint you have your workflow off a bit. If you are making a golden image computer, you should register that computer with FOG BEFORE you build your golden image. That way everything is setup in FOG. Then you sysprep the machine and have sysprep power off the computer. Schedule a capture in fog then pxe boot the target computer and capture the image.

@faboulous said in Preseeded (unattended) netboot UEFI Debian installation:

do machines need a large amount of ram booting this way?

Realize that Rob is addressing the debian installer and not the ubuntu installer. For ubuntu it uses the iso image that gets transferred over to the target computer. Your target computer needs to have enough ram to hold the entire iso image and enough ram for the OS (linux) and virtual drive (initrd.gz). In this setup the iso image is not unpacked but executed as a virtual dvd image in memory.

If you look at the instructions here for the Debian 10.7 installer https://forums.fogproject.org/post/140720 that uses the disk on the FOG server to hold the files from the ISO image. So the only ram requirements is for the linux kernel and the initrd.gz file. In this setup less than 1GB is all that is needed to run the installer.

@cf20corvuss Well lets think about this for a minute.

The screen shot you provided looks like the fog ipxe boot loader. If it is we can then make a few assumptions. My hesitation ATM is that some hypervisor’s use iPXE as their pxe boot rom (Virtual box being one). If we work under the assumption that the screen shot shows the FOG iPXE boot loader we know this.

1. The target computer can speak to the FOG server. We know then because the iPXE boot loader was sent by the FOG server and received by the PXE booting computer.
2. The target computer is getting a dhcp address from some place AND that dhcp information told the client where to get the iPXE boot loader from. So we know that dhcp is working.
3. We know that iPXE has the proper driver for the network card in the pxe booting computer because iPXE sees the mac address of the network adapter.

Where we typically see this is with the network configuration where Spanning Tree is enabled but one of the fast spanning tree protocols are not used. Standard spanning tree will listen for a loop back interface for the first 27 seconds a link is active then start forwarding data. With imaging when the PXE ROM hands off control to iPXE, iPXE will reset the network interface causing the link to drop briefly as iPXE boots. Well this link briefly dropping causes the spanning tree counter to reset. So when the target computer is trying to get an IP address again, spanning tree is still listening for a loop back. By the time standard spanning tree starts forwarding data again, iPXE and FOG have already given up.

You can test this in a physical world by putting a dumb unmanaged switch between the building network and the pxe booting computer. This unmanaged switch will keep the building switch from seeing the brief link drop. Most cheap switches do not support spanning tree. So its all good there.

Now NAT and imaging do not go together with FOG. Everything needs to be bridged with real addresses for FOG imaging to work.

@jonhwood360 said in Issue with EFI through PFSense Firewall:

so one thing I keep seeing in the packet capture which is weird, is that the router option (3) is set to 10.255.252.1 which is the gateway that the fog server uses, but is not the gateway for the external network. .

Well lets think about this for a minute. When I looked at the packet capture I did notice the lease times were different too.

Looking at the config file you provided both the lease times and route address are set correctly. Why are we seeing a difference in the packet captures from the configuration. Its almost like we have a different dhcp server for bios than uefi. Or two instances running with different config files on the FOG server.

@jonhwood360 Do you have the option to use a mirrored network port on the external network? This would give us the best fidelity to the network exchange. On a witness port we can only see the broadcast (dhcp) side of the conversation. We miss all of the unicast traffic. There has to be something different in the exchange between a bios and uefi modes on the same computer. The same exact protocols are used so the firewall shouldn’t be blocking. While this mostlikely is not the case here, we have seen a smaller MTU than 1468 cause tftp issues. Smaller MTUs than 1468 cause the tftp packet to fragment and the receiving computer will reject the file transfer. But one would think if that was the case bios and uefi would be the same.

@jonhwood360 But I assume it still doesn’t boot.

So without the config file alterations you don’t get the screen about filesize 0 bytes, but with the alterations you get that error. Just thinking about it a bit more I think we are on the right direction, maybe just not the right path.

Did you get a workstation pcap of the process where you received the 0 bytes filesize? I’m interested to know if dhcp options 66 and 67 were being set, where it was actually kind of working. If they were there with those settings and the settings were the key for uefi dhcp booting then we just need to work on why the settings were wrong. I didn’t get a chance last night to test this in my home lab where I have a ubuntu server to understand why the settings stopped isc-dhcp from booting. But I’ll look at it tonight if we can’t get it sorted out. The commands I gave you were from the isc-dhcp config file.