Current instructions for creating a bootable USB drive for imaging via FOG?

[catselbow]

Over the years, several people have posted instructions for creating bootable USB fog image installation/capture disks. For example:

https://forums.fogproject.org/topic/7727/building-usb-booting-fos-image/3?sort=oldest_to_newest&lang=en-US&page=1

and

https://wiki.fogproject.org/wiki/index.php?title=USB_Bootable_Media

Unfortunately, none of these methods seem to work now, at least for the current Dell Optiplex computer I’m testing with.

Does anybody out there have updated instructions that are known to work with recent computers?

[george1421]

@catselbow Those instructions are still valid and should work.

What part are you having an issue with? making the usb drive, or getting your computer to boot from it?

If its booting from it, do you get to the grub boot menu with the options or won’t the computer simply boot (after you turn secure boot off)?

[catselbow]

@george1421
After fiddling around with several different arrangements I finally found that the following filesystem layout works:

.
└── EFI
    └── BOOT
        └── BOOTX64.EFI

with nothing else on the drive, and where all names seem to be case-sensitive (I couldn’t get it to work with bootx64.efi or BOOTX64.efi).

The documentation at the 2nd link above says that after booting I should be prompted for the IP address of the FOG server. That doesn’t happen for me. Instead, ipxe tries to connect to the server from which I copied ipxe.efi (which is on the other side of a firewall) and fails.

From subsequent ipxe command line I can use “chain”, etc., commands to talk to the server on a different, non-firewall-blocked address.

[george1421]

@catselbow said in Current instructions for creating a bootable USB drive for imaging via FOG?:

with nothing else on the drive, and where all names seem to be case-sensitive (I couldn’t get it to work with bootx64.efi or BOOTX64.efi).

In the easy way link I did mention that I did not test if case is important. I think its dependant on the uefi firmware. But you did find a working pattern so that’s good.

The documentation at the 2nd link above says that after booting I should be prompted for the IP address of the FOG server.

The ipxe.efi is non fog server specific. The fog delivered ipxe version has been modified from the developers configuration because it includes an ipxe script built in. Think of it as what autoexec.bat is to DO, default.ipxe is to iPXE. The script is here: https://github.com/FOGProject/fogproject/blob/master/src/ipxe/src-efi/ipxescript You see from the script that it locates the FOG server from the dhcp query. From either dhcp option 66 or the next-server field. That is how it finds the fog server to load the default.ipxe file from the FOG server to continue the boot.

That doesn’t happen for me. Instead, ipxe tries to connect to the server from which I copied ipxe.efi (which is on the other side of a firewall) and fails.

The only way for iPXE to try to find the server where ipxe came from is that your dhcp server on this isolated subnet is filling out dhcp option 66 or the bootp next-server field. And because iPXE is getting this direction its not asking for the boot server.

Either not give the target computer the dhcp option 66 value or give it the right answer.

So you might ask how can I really tell what the target computer is being told to do? A: Use a witness computer (3rd computer not part of the pxe booting process) with wireshark loaded. You can either use a capture filter of port 67 or port 68 or port 4011 or a display filter of bootp. In a normal dhcp process there should be at least 4 packets DISCOVER (from the client) OFFER (from one or more dhcp server), REQUEST (from client), ACK/NACK (from server). Look at the OFFER packet. In the ethernet header there will be the bootp fields of {next-server} and {boot-file}, and dhcp options 66 (ip address of FOG server) dhcp option 67 (file to boot). Either these need to be blank so iPXE will prompt, or correctly populated for your isolated network.

[catselbow]

@george1421
Thanks, that’s very helpful. I’ll do some debugging and see what I can find.