Dell Latitude E5470
Intel Ethernet Connection I219-LM
Intel Boot Agent PXE Base Code
Kernel bzImage Version 4.8.11
Kernel bzImage32 Version 4.8.11
Date Tested 12-01-2016
Multiple Partition Image - Single Disk (Not Resizable)
@melvinpaz I’m a little concerned that it appears the ethernet controller isn’t supported with the newer kernel. But from the disk information you supplied I can guess that if you continue using 1.2.0 you will have issues there once the nic controller issue has been resolved too.
I would spin up a new FOG server using fog 1.3.0RCx to test to see if you get better hardware support with 1.3.0 before you upgrade your production server. Also FOG 1.3.0 will give us a few more debugging tools than 1.2.0.
If you want to continue to test with 1.2.0, I would recommend that you create a debug capture (from the host configuration advanced menu, if I remember correctly). The debug capture/deploy will allow you to interact with the customized linux OS on the target computer. Once you get to the command line prompt then we can key in lspce -nn to give us a list of hardware that the FOS engine (linux OS that runs on the target computer) sees. We are looking for the ethernet adapter and something that looks like this
EDIT 2: Not sure why the edit from my main post vanished. Let me put that here again.
I took a video of the newest message. From reading the blurry video, this is what I can read before the fog text logo comes up.
mmc0: Unknown controller version (3). You may experience problems.
usb 1-5: device descriptor read\64, error -71
EXT4-fs (read): couldn’t mount as ext3 due to feature incompatibles
Starting logging: OK
Populating /dev using udev: udev: error creating spell? fd: Function not implemented
EDIT 3: Took bzImage files and init files from a test fog machine I was messing with. 1.3.0 FOG on there. Copied the to the FOG 1.2.0 server.
The compatibility test comes back with disk and network passing.
Trying to register a host and I get:
Unable to register host: Invalid MAC Address (/bin/fog.man.reg)
@george1421 Like I mentioned above, the Lenovo ThinkPad 13 works perfectly with the same BIOS setup. No need for the USB solution that the Yoga 260 requires for UEFI/Legacy dual booting. I fully believe the problem is entirely with the firmware on the Yoga.
Both work better now than they did 4 months ago with the BIOS version available then.
We have received 3 type of Acer computer this year X2640g, X4640G and N4640G.
Both X are working fine with undionly.kkpxe but N isn’t.
N is only working with ipxe.pxe.
This tells me that the ‘N’ system is a uefi system and the ‘X’ systems are bios (legacy) systems. You must use the right iPXE kernel with the proper firmware or it won’t work.
As for the error above. It appears that the undionly kernel can see the network adapter, but not communicate on the network. I too suspect that this is a spanning tree issue. The problem is that spanning tree takes 27 second to begin forwarding traffic. The 10 second delay kernel is not sufficient to bridge this gap. Its best to enable one of the fast spanning tree protocols on this switch port. OR as a test, place a dumb switch between this target computer and the building switch. This dumb computer will keep the building switch port in the forwarding state while the target computer boots. If inserting the dumb (unmanaged switch) between the building switch and the target computer works, then you do have a spanning tree issue.
@egregers For a single drive there is no advantage. But I can say with my fleet of computers they are all dells and all are in the raid-on mode with a single drive. Its not clear why you are having this issue. But again I don’t have a T5810 to confirm or deny with. As always do you have the latest firmware installed on that T5810?
I’m going to update this thread because the only thing worse than finding no solution to your problem on Google is finding a problem listed without a solution.
These machines can in with 8gb of RAM. Some came in with 4 2gb sticks of memory and some came with 1 4gb and 2 2gb sticks. The machines without the 4gb stick work perfectly. They will image just fine. If I image them and then add the 4gb stick back in, they blue screen. So Tom was correct, it was a RAM issue. The 4gb stick of RAM is causing the issue. Thanks for all the help!
@dustindizzle11 Sorry for my late reply. There is a side way you could go with this now that you know how to modify the init.xz image. Grep yourself a copy of the current script and exchange the one you posted with this new one. See if you can make it work with this. Just an idea for a quick dirty fix.
Try different hdd exit types. Look up the host in Host Management, and on it’s general page you’ll see two drop downs towards the bottom for hdd exit types, one is BIOS the other is UEFI. so the mode that the computer is operating in determines which of these settings will apply. I would first recommend trying Grub, then if that doesn’t work just try one at a time - do a full reboot between each try.