ok then, I think we’ll need one of the @Developers to look into the code to see if it is honoring the “Host Primary Disk” field when launching the partclone.

@ecicerkofski When you login to the web gui, look at the cloud there should be numbers on or around the cloud. I would upgrade to the latest build 1.3.0-rc8 to ensure that your surface pro works. In the other thread the OP was able to image the surface pro.

I think I would still go down the live boot path. Just get ubuntu 15 desktop iso and burn it to CD. Then boot from the CD, there is an option to try it first (or something like that). I would be interested to know what a production kernel reports. But /dev/nvme0 would be a sane name for that hard drive.

@Jay-Bosworth

OK I have a few questions:

1. Is the target system an apple device?
2. Is 10.60.82.15 your fog server?
3. What is 192.168.101.2 and why is it sending a dhcp nak (dhcp rejection)
4. Did the target get 10.60.16.119?
   crud, that one was an iPhone.

I see another one that is a HP device with a mac address of 00:1b:78:a4:a0:6c
But that one looks like a dhcp renewal. What is interesting is that I seen dhcp ACK from 10.20.88.37 and NAKs from 10.60.82.170, 192.168.101.2 and 10.20.0.101

This tells me you have multiple dhcp servers attempting to respond to a dhcp request?

@Arrowhead-IT Hey, just wanted to let you know this is all great information. The more details the devs have the better solution they can come up with. Its impossible to have every bit of hardware in the test lab that exists in the wild. So it is key to get support from the user community to help build a better mousetrap.

@Jay-Bosworth Its been nuts here this am so it took me a while to grab the screenshot.

Capture requirements.

1. Target computer, wireshark computer, and DHCP server need to be on the same subnet to capture broadcast based traffic. If any of these are on a different subnet then you will need to setup wireshark on a mirrored port to the target computer.
2. If your FOG server is on the same subnet as the target computer and dhcp server you can use tcpdump on your FOG server to capture the pcap file. (hint: wireshark is not needed).
3. Start your pcap capture device. for your FOG server using tcpdump you can use the following command: tcpdump -w issue.pcap -i eth0 port 67 or port 68 or port 69 or with wireshark select Capture->Options then select the proper network adapter and key the following into the capture filter port 67 or port 68
   
4. Press the start button.
5. PXE boot the target computer to the error
6. Stop the wireshark/tcpdump capture.
7. Analyze the pcap file.

Lets start with the basics.

What version of FOG are you using? (I’ll assume 1.2.0)

Are you running a trunk version? (if you look at the management page, there is a cloud in the upper left corner. There are numbers on the cloud, what are they?)

Is this a new FOG install or have you been using this successfully for a while?

Do you have any other client computers (older than the 3020) that do register correctly?

BTW: There is another thread in this forum with almost the same exact issue. But lets start with the basics first.

The developers just commented in another thread that 4.7.1 has been re-engineered to support FOG 1.2.0 for those that can’t migrate to 1.3.0 right now. You won’t get support for Win10, gpt disk format, NVMe disks, or the 1000s of improvements in 1.3.0 over 1.2.0, but you will get the latest sata and nic support with 4.7.1

You can access these kernels here:
https://fogproject.org/kernels/bzImage
https://fogproject.org/kernels/bzImage32

They go into the /var/www/html/fog/service/ipxe directory.

Lets get a little more info here

What version of fog are you using 1.2.0 stable or a trunk release (i.e. pre 1.3.0)?
Is this device in efi or bios mode? (I’m going to guess bios)
What version of the FOG (Fog OS) kernels are you using?
I can’t find a reference for a lenovo B700 on their web site, what is the real part number?

@t1pt0p the problem is that stp IS enabled. You need to enable a fast stp protocol. The quick test is to put an unmanaged switch between your building switch and the target computer.

If you have stp turned on, then look for port fast, fast stp, or rstp and turn it on on the target computer port.

According to google that motherboard has an Intel I219-LM network adapter on board.

You will need newer kernels than 3.19 to make that one work.

Any reason why you can’t upgrade that 1.2.0 install to the trunk release (i.e. 1.3.0 beta)? That release has the latest kernels including that intel driver.

https://wiki.fogproject.org/wiki/index.php/Upgrade_to_trunk

Just to be clear FOG does not magically talk to target computers. There is a complex dance of technologies that work together to make a FOG capture/deployment a success.

Once your fog server is setup you need to modify your dhcp server to provide the FOG information to your target computers. This is typically done by setting dhcp options 66 {next-server} to the IP address of the fog server (which should be a static IP address) and dhcp option 67 {boot-file} to undionly.kpxe for bios (legacy) target computers and ipxe.efi for uefi based target computers.Once dhcp is setup then you pxe (network) boot the target computer. If everything goes well you should see the FOG iPXE boot menu. At the iPXE boot menu you select register device and register the target computer with FOG. After that you can go into the fog web gui and find the device you just registered and schedule a capture task for your mother or golden image. Then pxe (network) boot your golden image computer once more and then FOG should automatically start to capture the hard drive setting.

I skipped over a few steps but that is the general outline of what needs to be done.

I know I’m reading fast here, But I’m seeing a conflict in your post (a few times).

Is this Toshiba in UEFI mode or LEGACY (BIOS) mode. It appears that it is in uefi mode but you are sending it undionly.kpxe (which is a bios boot kernel).

I also see there are references to NBP file name (which tells me uefi mode). If it is uefi mode then you should use the ipxe.efi boot kernel. (the kpxe ones are for BIOS mode).

@sbenson The easiest way may not be the direct way. The easiest way is to deploy your clonezilla image to a target computer then immediately pxe boot that system and capture it with fog. This will be the quickest and surest way to ensure the files are in the correct format.

With these realtek drivers, they are a bit of a pain. With that said the first thing I would like you to do is to upgrade that 1.2.0 install to the trunk version (i.e. pre 1.3.0) The trunk version supports newer hardware as well as uefi firmware, gpt disks, and windows 10. The first two are marginally supported in 1.2.0 stable.
https://wiki.fogproject.org/wiki/index.php/Upgrade_to_trunk <edit> If you have the other hardware booting with 1.2.0 there my not be an urgent need to upgrade to the trunk version. Maybe I would make this 3rd on the list of things to do </edit>

Once you upgrade to the trunk version and you still have issues (I’ll guess yes), then it would be helpful if you posted a picture of the exact error. My guess it will be in the iPXE kernel where it can’t pick up an IP address. If this is the case insert a mini/unmanaged switch between the booting device and the building switch. See if you can boot then.

Some things you need to check on the laptop. Find out if its booting in uefi mode or bios mode. That will dictate which iPXE boot kernel you will need.

If pxe booting you can start with the undionly.kxpe boot image (for bios mode). Others have had success with the realtek nics and the ipxe.pxe boot image.

@dureal99d I started another thread where I’ve been documenting my travels with dnsmasq and uefi here: https://forums.fogproject.org/topic/8677/dnsmasq-bios-and-uefi

My config is pretty close. I can pxe boot a uefi system. Right now its hanging on the iPXE kernel initializing devices… But I did have to compile the latest dnsmasq program because the one for my distribution did not work even with the updated config file.

Looking at your config file I would have to say you need to update this line:
dhcp-boot=tag:efi-x86_64,ipxe.efi

to this:
dhcp-boot=tag:efi-x86_64,ipxe.efi,,192.168.1.109

Just like you did for the bios undionly line.

@arnaudrigole Thank you for providing the picture, that tells me something important and then I’ll read between the lines to fill in the rest.

You have a Lenovo and you had to use a supported usb ethernet adapter to boot. And I also see the word NBP, that kind of tells me you are booting the yoga in uefi mode. If this is the case you are sending a bios iPXE boot file to this client, which will of course cause the yoga to fail to boot. The proper uefi boot kernel is ipxe.efi. Change your dhcp option 67 to ipxe.efi and this yoga should boot into the fog menu.

Also make sure that the secure boot is off, that will be the next error you could run into.

[housekeeping] moving this thread to the hardware section since its not a windows issue (not there yet) [/houskeeping]

@Sebastian-Roth I agree, after looking at a dhcp booting process all weekend I can read the pcap like code from the matrix.

The requesting system is in BIOS mode so undionly is the proper boot kernel for it. I see the target requested the file size for undionly.0 from the tftp server at 192.168.1.133 with no second response from the fog server or no request for undionly.0 to be downloaded from the tftp server. This tells me the tftp server responded with “file not found” for undionly.0.

@arnaudrigole If your dhcp server is a windows 2012 server you can add a filter to send the uefi boot file to uefi device and the bios boot file to bios devices automatically. That way you don’t need to manage two different scopes. Unfortunately this filter is not available for windows 2008 dhcp server.

@dureal99d Let me have another shot at it. I just realized something I left out. Update your config file and insert these lines. I left the vendor class ones in so you knew where the add the following dhcp-boot lines. You’ll see where we pick back up with your config file with the dhcp-boot=undionly…

# inspect the vendor class string and match the text to set the tag
dhcp-vendorclass=BIOS,PXEClient:Arch:00000
dhcp-vendorclass=IA32_UEFI,PXEClient:Arch:00006
dhcp-vendorclass=BC_UEFI,PXEClient:Arch:00007
dhcp-vendorclass=X86-64_EFI,PXEClient:Arch:00009

# The default boot filename, Server name, Server Ip Address
dhcp-boot=undionly.kpxe,,192.168.1.109

# Set the boot file name based on the matching tag from the vendor class (above)
dhcp-boot=net:IA32_UEFI,i386-efi/ipxe.efi,,192.168.1.109
dhcp-boot=net:BC_UEFI,ipxe.efi,,192.168.1.109
dhcp-boot=net:X86-64_EFI,ipxe.efi,,192.168.1.109