Posts made by george1421

@olivierl This is a built in user ID and password that you created inside FOG and not one connected via the LDAP plugin?

Beyond that you can create a zero touch deployment with fog (by scheduling a deployment task) and also by using post download scripts if needed as well as setting the target image up for unattended deployment. That part is not difficult if you know what you are doing.

In my environment I have a single client image that is deployed to 12 different hardware platforms. This is all done with zero touch methodology.

There is an alternative to pxe booting but its not zero touch.

But I can make a recommendation if your current (not FOG) menu is using syslinux as its pxe environment. That is if you know ahead of time what computers you are interested in with the zero touch deployment, you can setup a… forward chain (not the right word) configuration in the pxelinux.cfg directory. This would be a simple chain command to load the pxe boot loader for FOG (iPXE). You do this by creating a menu program the name of the mac address of your booting computer. There is a sequence it that will look for the mac addresses too, but the easiest is just create a file in the pxelinux.cfg with the mac address of one of these computers, put the forward chain (not the right words) command in there and the target will chain to what ever is in this file. If the syslinux boot loader doesn’t find a file that matches the mac address of the target and there are no other options then it will load the default file (this is where most people build there pxe boot menus).

@pencils Is it possible to upload the file to a google doc and post the link here. We really need to see where the file name is missing.

Since you are using dnsmasq this should be sending the file name. I looked back through this thread and I did not see if you posted the dnsmasq config file. Would you post that here in a code block too?

@Sebastian-Roth That in a way is what is already happending in my network. From some silly reason my internet router is sending the next server as it self (as seen in the pcap in my dnsmasq uefi thread). But in this situation the pxe booting client understands this, complains about getting two next server replies and does the right thing anyway. That is why I suggested trying a different client to test this, but his second client did the same things.

@mkstreet I think we are at the point of diminishing returns. I don’t think we (from the FOG Project) are going to be able to help you solve this remotely. You NEED to have a network engineer involved with this to get the problem esolved. There is something going on in your environment that needs expert hands and tools for your network. The components are setup correctly for FOG there is some external force that is keeping this from working correctly.

@mkstreet said in PXE-E78 Cannot locate boot server:

10.0.253.23

I’m not seeing anything different from the 10.0.253.23 system. The conversation stops after the ACK from the 172.1.1.1 dhcp server.

What I don’t understand is why does it not continue and contact the proxyDHCP port? You have already confirmed that the iptables or firewalld firewall is not blocking port access. We have done a side by side comparison of your dnsmasq config file to mine.

The only variable we haven’t ruled out is a bad/fault pxe client (firmware/bios). What device is your pxe boot client? Is the firmware up to date on it? Do you have a different brand/model of device you could use? Assuming your FOG server is setup correctly now we have to start looking outside of the FOG server for the issue.

You did mention that you moved this FOG server from an isolated network to this new network. What device was supplying the DHCP services for that isolated network?

This is your pxe boot process on the top and one from my FOG-Pi server. The only difference here is my client is asking for a uefi file and your is asking for the bios (legacy file). You will see again in yours the transactions stop at line 5 In the bottom image you will see once the client gets the ACK back from the dhcp server it turns around again and connects to the dhcpProxy port on port #4011 and downloads the file name to get, then the client ( at .16) requests the file via tftp from the FOG server. This is what suppose to happen.

I’ll restate again, it should be working.

I want you to learn what I’m seeing (not that I really know what I’m looking at). If you install wireshark on your computer you can review these pcap files.

Below is the communication that is going on as viewed by your FOG server. In line 1 you see the client send a discover packet (basically hello I’m here I need network info). Then you see in step 2, two devices reply with an offer (here’s your network info). In step 3 you see the client again say “great this is a list of additional stuff I need”. In step 4 your main dhcp server says “ok here is the additional stuff you requested”, note here the dnsmasq box did not reply because it couldn’t add anything to what I already sent. Now here is where the process falls down. When the client gets the ACK back what it should do is contact the dhcpProxy on port 4011 and request the file name to download then reach out to the tftp server (listed in the next server field) and download the boot loader file (undionly.kpxe). That is what is suppose to happen. Now let me show you a side by side of what a proper exchange should look like.

@smazzola Is this the first uefi system you are attempting to image?

What value do you have in your dhcp system for dhcp option 67 {boot-file}?

Well a couple of things jump out at me in this post.

1. Yes secure boot needs to be disabled otherwise the FOS Engine (the custom linux operating system that captures and deployed images will not be able to run). This is a given.
2. For UEFI systems you must send the uefi iPXE menu kernel to the target computer. So for uefi systems you must send ipxe.efi and for bios (legacy) systems you must send undionly.kpxe to the target computer. Otherwise the FOG iPXE menu will never start. If you have a windows 2012 dhcp server then you can have this file name change happen automatically for you.
3. How are you prepairing this computer for cloning? Are you syspreping it or just shutting it down, and then uploading your golden image or are you running sysprep to get this system ready for cloning?

Lets start with those questions.

@pencils If debugging tools or process is needed. Then this is how I would go about it.

1. From a windows computer with the tftp client installed, attempt to grab undionly.kpxe from your fog server if you can do that then move on to step 2
2. Since you are using dnsmasq to supplement your dhcp server settings ensure you FOG (dnsmasq) server, booting target computer, and preferrably your dhcp server are all on the same subnet (for this test). Install tcpdump on your fog server. Key in the following command sudo tcpdump -w output.pcap port 67 or port 68 or port 69 or port 4011 This will tell tcpdump to only caputer dhcp, tftp, and dhcpProxy traffic and record it in output.pcap. Now pxe boot your target computer until you get the error. Once that is done review the pcap file with wireshark. If you can’t see anything wrong then upload the pcap to this thread and we will take a look at it. The pcap will tell us the truth of what is actually going on the wire. (just to be clear, I’m not saying you are not telling the truth, its just we need to see exactly what is going on with the communications)

I’m still of the opinion that the install is botched and possibly you need to run the installer again. Make sure (since you are using ubuntu) that you change the downloaded package’s /bin dir and run sudo ./installfog.sh using the su command. You also need to ensure that your FOG server has direct internet access. If you have a proxy server between FOG and the internet you will have to make a few changes for that. But directories not being where they should is a solid indication that the installer failed to work properly. But again that is only my opinion here. You may be able to back into a working system, but the question is how much time will and effort it take?

@Tom-Elliott I agree here. The OP is operating at a level of interaction not common with most fog installs. Pencils did something happen with the original FOG install on Ubuntu?

I did create a tutorial for dnsmasq on Cento 7. The config file and instructions are still relevant for other flavors of linux too. You might want to review this document: https://forums.fogproject.org/topic/6376/install-dnsmasq-on-centos-7

Personally I would create the link to the .0 files and not just copy the files statically to the .0 files. The link will work if / when you upgrade, where the static copy files won’t.

@Sebastian-Roth said in PXE-E78 Cannot locate boot server:

@mkstreet you seem to still have the FOG server configured via DHCP!

I was just thinking about this on the drive in this morning. This fog server was on an isolated network so it was the dhcp server then. I was wondering if the OP remember to stop the isc dhcp server when he setup dnsmasq?? This might cause this exact issue since dnsmasq would not be able to bind to the udp ports since they are already in use. But I also considered that dnsmasq should complain about not being able to bind to the ports either so I kind of pushed that idea to the back on possible causes. As I stated before this configuration should be working. Dnsmasq is not that hard to setup.

@Dalton-Childers While I can’t answer anything about the command Tom posted I will give you a hint. If in the FOS command shell, you give root a password with passwd you can connect to the FOS linux via ssh (putty or what ever). That will allow you to do screen grabs and what not instead of having to take pictures with a mobile.

Now that I look at that picture again, are you deploying linux to the EVO 850 or Windows? That looks suspiciously like a windows disk structure.

@george1421 Last and final comment. Just for grins, I move the original Raspian Jessie version of dnsmasq (v2.72) back in place and restarted dnsmasq. With 2.72 running and the same configuration as before the Dell 6230 failed to pxe boot in UEFI mode, but would boot in bios (legacy) mode. So if you are going to use dnsmasq AND require pxe booting uefi systems you must upgrade dnsmasq to 2.76 or it will fail.

@george1421 I was finally able to update that 6230 from firmware A11 to A15. Without changing my FOG-Pi / dnsmasq setup the 6230 now pxe boots in uefi mode (whoot!!). The kernel stayed at initializing devices for about 15 seconds, I started to panic after 8, I figured it was hung and reach for my FOG GRUB usb boot drive. When I turned around the 6230 was sitting at the FOG iPXE Menu. I timed it again and it was bout 15 seconds to init the devices and display the FOG iOXE menu. I was able to quick register the system and everything worked fine.

Below is my final dnsmasq configuration for dual booting bios (legacy) and uefi systems on dnsmasq version 2.76

# Don't function as a DNS server:
port=0

# Log lots of extra information about DHCP transactions.
log-dhcp

# Set the root directory for files available via FTP.
tftp-root=/tftpboot

# PXE menu.  The first part is the text displayed to the user.  The second is the timeout, in seconds.
pxe-prompt="Booting FOG Client", 1

# The known types are x86PC, PC98, IA64_EFI, Alpha, Arc_x86,
# Intel_Lean_Client, IA32_EFI, BC_EFI, Xscale_EFI, ARM_EFI and X86-64_EFI
# This option is first and will be the default if there is no input from the user.
# PXEClient:Arch:00000
 pxe-service=X86PC, "Boot BIOS PXE", undionly.kpxe
# PXEClient:Arch:00007
 pxe-service=BC_EFI, "Boot UEFI PXE-BC", snp.efi
# PXEClient:Arch:00009
 pxe-service=X86-64_EFI, "Boot UEFI PXE-64", snp.efi

dhcp-range=192.168.112.24,proxy

According to the change log for dnsmasq there are issues with certain uefi firmware for displaying the dnsmasq boot menu so for uefi firmware dnsmasq will just pick the first matching service entry that matches the arch type, as long as there is only one and only matching service. You will not see this menu displayed for uefi firmware, where for bios you will see the menu entry for 1 second.

I did note in the iPXE bootloader that it did say duplicate next server values presented (or something like that). And that is in line with what we were seeing in the earlier pcap where both dnsmasq and the soho router were sending conflicting next-server values.

Here is the pcap of my last and working test. Note: I see I left the snp.efi kernel configured in dnsmasq too!!.

0_1475719888587_output.pcap

@Dalton-Childers To Tom’s point about " go into a debug and get output of fdisk -l "

What he was recommending is on the system you just imaged. Schedule a new image right away, BUT on the scheduled task page enable the checkbox for debug deploy. Then pxe boot the target computer. This will tell the FOS Engine to boot on the target computer, display a bunch of text and after a few presses of the enter key drop you to a command prompt on the target system. This is the command shell for the FOS Engine (the linux OS that captures and deploys images on target devices). Obviously this OS can see the 850 EVO. Then run the fdisk -l command and post the output here.

BTW: I don’t think kernel 3.18 will work with the new initz. You will probably get a kernel panic when your try to pxe boot it. But that is only a guess, and I’m a bad guesser.