@dtkeith002 said in Acer Aspire A515-55 Connection Timed Out:

Does FOG offer the ability to listen on multiple interfaces / ips at the same time? I haven’t dug into the config files to see. If so I can try a direct bridge to the server VM and bypass the network completely.

Don’t think it’s worth going down that route. Testing on the same switch as the server should be enough to rule out most of the network related stuff.

From the picture we see that it seems to be able to fully download the kernel (bzImage) file but times out on the initrd (init.xz). I would setup a mirror port on the switch and capture traffic on both ends - client port (using a notebook with Wireshark on the mirror port) and directly on the FOG server (e.g. using tcpdump). Use capture filters to restrict traffic to a particular MAC address (ether host aa:bb:cc:11:22:33). Please upload the PCAPs to a file share and post links here.

If that doesn’t give us enough insights we might compile debug enabled iPXE binaries to analyze the TCP traffic - though this will a tough job!

Have you tried using ipxe.efi yet?

For these new hardware you need to use the 5.6.18 kernel found under the kernels update menu in the FOG Configuration or you can upgrade by hand using the kernel link https://fogproject.org/kernels/ I would always use an official kernel instead of any one off link you might find.

@acsand0199 If you have issues post back and I’ll see if I can give you a direction to look in.

@MikeBC I agree. In our imaging lab we are only using wd15 docks the wd19 even after the dock firmware upgrade were just to unreliable reporting to the firmware as pxe compliant. So in the end we moved the wd19 docks to the user’s desk and acquired their wd15 docks for the imaging labs.

This also worked for me, but with a Dynabook A40 laptop.

Thank you.

@jps While you can go with just updating kernel and init files with some manual adjustments in the config I am wondering if a proper upgrade to 1.5.9 would be the better choice in your case. We fixed hunderds of bugs since then.

Why so you still use such an old version?

@Sebastian-Roth To my memory we replaced kernels (both 32 & 64 bit), init’s/bzimage (expanded to more and more files etc during troubleshooting to try to find the culprit) none helped other than upgrading to 1.5.8. I assume it’s something Dell specific with some weird OEM magic that messes up something somehow somewhere… 😉

Thanks, @george1421. I haven’t worked out the DHCP problem yet, though - I just need to walk away from it for a while. I’m stumped.

@george1421 That was it! I figured it was a setting but couldn’t find it. Thanks!

@FuriousGamer065 First let me say I’m asking because I don’t know.

Does NVMe disks work in bios mode?

For SANBOOT you have to remember that is a bios only boot loader (built into iPXE). It references disks by their bios ordinal position.

For example with FOG it issues this command when you pick SANBOOT. sanboot --no-describe --drive 0x80 In bios syntax drive 0x80 is the first hard drive 0x81 is the second hard drive and so on. Since you have 3 drives 0x82 is the last bios referenced drive. Its possible because of the bios order 0x80 may not be your NVMe drive but a sata drive (I don’t know) but that will explain why SANBOOT is not working for you.

So you might ask how can well tell. Good question…

I think what I would do is create 2 new iPXE menus for testing.

The concept is based in this tutorial: https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images

But we are going to make a twist on this.

Make two new iPXE menus:
Menu Item: os.Sanboot.D2
Description: Sanboot Drive 2
Parameters:
sanboot --no-describe --drive 0x81 || goto MENU
Menu Show with: All Hosts

Menu Item: os.Sanboot.D3
Description: Sanboot Drive 3
Parameters:
sanboot --no-describe --drive 0x82 || goto MENU
Menu Show with: All Hosts

Now boot into the iPXE menu and see if either of the new sanboot menus work. It will be interesting to know if one of the alternate menus work correctly.

@george1421

Awesome!

BTW, little off-topic do you know why I had issues initially to upload on forum?
Was due to the fact fresh user account and low reputation?

Now I tested seems fine.

@BrentC Beyond George’s good advice you could also start thinking about moving your setup towards UEFI. I am not saying this will work no problem but it’s worth a try.

Change your firmware to UEFI and set the DHCP to hand out ipxe.efi file for UEFI platforms and see If you get to the FOG menu.

@ABCD What does this have to do with FOG?

@george1421 So now it finaly Works ! I am so Thankfull 🙂
I am now running some Deploys and Captures as a Test but so far it has the 5.6.18 Kernel and gets no Nic errors.

Just as an fyi the -o in your Command should be a Captial -O otherwise it creats just a .txt file and runs in an Format error at pxe boot.

But Again Thank you for the Support 🙂

Windows 10 captured from other host same model with fog and manual also windows 10 with bootable USB

@Don-Winters said in Dell Latitude 5510 PXE Boot:

Everything should be set to the standard setting in Fog

I think we are not talking about the same thing here. Let me just restate a few things.

PXE booting relies on certain settings in DHCP. If those settings are configured your target computers can find the fog server. If your dhcp server is managed by an outside entity then they may have made the settings for you. If the dhcp server is based on windows 2008 then, 2008 is not capable of dynamic pxe booting in that the boot file (dhcp option 67) is either undionly.kpxe for bios computers or uefi.pxe for uefi computers. If what you are telling me is the case, you can only boot one type of computer (bios or uefi) in your environment. This is totally OK and a workable solution. There ARE a few things we could do differently to make your life a bit easier but we need to focus on your specific issue.

Its good that the fog server and the pxe booting computer is on the same subnet, that will help debugging what is going wrong a bit easier. I have a tutorial that will capture a pcap (packet capture) of the pxe booting process with this computer. We will use the FOG server to capture this information. Here is the tutorial: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

Grab the pcap of the pxe booting process and then upload the pcap to a file share (google drive, dropbox, etc) site and IM me the link. The filters in the tutorial will only allow the capture the minimum information needed to diagnose the issue. It will not capture all data on your network (considering you are state department regulated). If its not possible to upload this file then if you have wireshark available I can tell you what to look for, it would be much faster if I did it, but we can work either way.

@george1421 You have a great point. I discussed it with the boss, and we went the path of no client on the laptops. It is a relatively small number right now that need a somewhat quick turnaround. I figure we can bang out renaming and joining manually for these. Perhaps I will investigate other methods if there is a future order or it is the direction we end up going. Thanks!

@Single said in Kernel Panic:

A nickle (may be helpful)

I don’t think that one fits here since we are not doing nfs at this time. What we really need to see is the actual error that happened just before the stack dump that we see on the screen. Possibly if you can get a slow mode video of the kernel booting process we can see what the actual error message is. I’m not sure what we can do about it because its in the linux kernel but it might give us an idea where to look.

Mod Note: I forked your topic off from the hardware working with FOG because your situation needs a bit more explaining.

The newest hardware does not work with the FOS Linux kernels shipped with FOG 1.5.8. The issue is the linux kernel developers are no longer back porting the newest drivers to the Linux 4.19.x series of linux kernels. They are only writing new drivers for 5.x series of linux kernels. (if you want to equate this to the windows world, hardware manufacturers are no longer creating drivers for Windows 7, but now they only release drivers for Windows 10). The linux developers are doing the same, leaving the older ones behind and only writing for the new OS.

Because of this the FOG developers have released 5.6.18 version of the FOG Linux kernel. Understand this kernel has NOT been widely tested with FOG at this time. The deverlopers released this as an option for those FOG admins that have very new hardware that is not supported by linux 4.19.x. Since FOG 1.5.9 is on the edge of final release, 1.5.9 will continue to ship with linux 4.19.x with the option of the FOG admin to upgrade to 5.6.18. Once more people test this new kernel and it proves to be stable then the 5.x line of linux will become default for FOG.

I know its a lot of words to explain, yes I see 5.6.18 addressed your problem, well done.

@frit As I mentioned previously this is not a FOG Imaging issue. You are using FOG in a way it wasn’t designed. That is OK because FOG is an opensource project you can use it in any way you can imagine. The FOG developers do have limited resources to provide support beyond the scope of FOG imaging.

With that said, I feel you are going about netbooting in the wrong direction. Right away I see two issues with your setup.

using memdisk will restrict you to only being able to boot in bios mode. memdisk doeesn’t support uefi booting. If you use memdisk you need to have enough ram to hold the iso image and boot from it.

I have a tutorial on how to use FOG as a netboot server (again not as the FOG developers has designed) here: https://forums.fogproject.org/topic/10944/using-fog-to-pxe-boot-into-your-favorite-installer-images

While I haven’t worked with manjaro its based on Arch linux (which also I haven’t tried to netboot) but you should be able to follow the ubuntu workflow to get it to netboot. There is a tutorial on getting windows pe to netboot and that does work.