Posts made by george1421

@Sozen OK so you are using a 380, that is good in a way because you use fog 1.2.0 and that version doesn’t support the latest hardware (like Dell 7040 or P3510). So we can rule out target system issues. You really should update to 1.3.0-RCx to get better hardware support but I understand that may be out of your control.

We we need to identify is will a unicast up capture / deploy work correctly or is this a multicast issue?

When you capture this dell 380 do you select single disk resizable (resizable may not be an option on 1.2.0) or just single disk not resizeable?

Can you capture from one o380 and deploy to another o380 of the same hardware style?

On your destination computer is your hard disk the (exact) same size or larger? I have seen issues with 1.2.0 where someone captures from a 80GB seagate disk and tries to restore to a 80GB WD disk where if the destination disk is even 10bytes smaller than the source imaging will fail if single disk nonresizeable is selected.

When I was on 1.2.0 I would create our golden image on a virtual machine with a 40GB hard drive, this way I was sure the image would fit on any destination computer we would have. Then we would expand the disk once it was on the target computer to the size of the physical disk.

@dureal99d Your welcome. I’m glad in the end it was just a simple reboot that finally resolved the issue.

We had a hour or so chat session to work through this issue pulling apart the dhcp/pxe booting process frame by frame.

@Sebastian-Roth That what I was seeing. The issue is in the kernel (??). The OP pulled this information from the running FOS kernel.

02:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 15)

That realtek nic should be supported. The only thing I can think is that the device id [10ec:8168] is not in the hardware list, but I suspect that is not the case since 10ec:8168 IS the device name too. Could this be another slow start interface?

Take a look here: https://forums.fogproject.org/topic/8726/advanced-dnsmasq-techniques

There is nothing else in that dhcp option that is unique other than the arch. The undi 003 016 just defines the version number of undi the client is using. If you want something unique per client look at dhcp option 97 of the dhcp request.

@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

@dureal99d I see where things went wrong. I didn’t tell you the whole story.

You need to add these lines into your config file. I left the dhcp-no-override in there to give you a reference where to place the lines.

# Disable re-use of the DHCP servername and filename fields as extra
# option space. That's to avoid confusing some old or broken DHCP clients.
dhcp-no-override

# 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

These lines are matching the vendor lines that sets the flags used in the pxe-service section. There is nothing to tell which vendor section line to fire so you are getting the default of… undionly.kpxe.

My initial reaction is that you don’t have the sata driver for the P 650 G1 in your reference image.

Second reaction is what type of disk is in the 650 G1 (is it a NVMe type disk)? If so you will need to include the OS kbs that add support to NVMe disks. This is outside of what hardware drivers are needed for that model.

@dureal99d pcap?

@Sozen No sorry what computer are you using that you want to capture?

AND did you perform the fog compatibility test from the iPXE boot menu?

Also what host are you attempting to uploade. (Mfg and model). FOG 1.2.0 stable is a bit old.

@RobTitian16 I only mentioned the script and its intended function because it would do what you needed to re-ip a host. But I agree with Wayne maybe a simpler one time run script would be in order, because sometimes you DO have to renumber a FOG server after its been setup.

@RobTitian16 @Wayne-Workman has a script for fog servers with a dynamic IP address (i.e. assigned by dhcp) that would probably help here. That way you can be sure you get all of the places changed. Changing the fog server IP address after setup is a bit of a pain to do manually.

@dureal99d Could I ask you to install tcpdump on your FOG server then run the following command to capture a new pcap file? The other one contains other internal communications that I don’t should see plus it confuses me to dig out what is going on.

sudo tcpdump -w output.pcap port 67 or port 68 or port 69 or port 4011

This will filter out all requests except dhcp, tftp, and dhcpProxy. UEFI boot the target computer and lets see where that gub boot is coming.

In addition to below, on your FOG server please key in showmount -e 127.0.0.1 that will show what is exported (shared via nfs) on your FOG server.

@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.

@pencils I attempted but they wanted me to provide my google login to access them. You should make the public read only for a short time. I will not provide my credentials to look at them.

@zingaro said in AHCI boot iso problems:

I have problems with only winpe.iso ( standard winpe win7 and winpe 8 32 and 64 bit )

Where did you get this ISOs from? Did you include any drivers in the WinPE images? To me this sounds like a lack of drivers for the ahci mode. I can say that the WinPE 3.0 and 4.0 should natively support ACHI mode unless you have abnormal hardware. Either way you should include / inject the proper drivers for your hardware into the WIM file with DISM.

@zingaro said in AHCI boot iso problems:

I finish two tests with two different PC Intel E3826 and J1900

AFAIK, these are processors (CPU chips) not computers. What computers are you having problems with?

@DZKeeper said in Routing and installation problem:

Something changed my option router setting back to 192.168.2.1 instead of 192.168.22.99

I can see/understand the fog installer “could” do this if you told FOG to configure the dhcp server for you. Running the installer would have (possibly) reset the routing options.

Since we messed with iptables, (which only would impact in memory configuration). Please reboot your FOG server to restore IP tables and clear any dynamic changes that we made. Then test again to make sure everything is back to normal. Then you can call it resolved.