Posts made by george1421

@goempie There is a posting on the FOG wiki that discusses this: https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence

As for the differences between undionly.kpxe and ipxe.kpxe. The difference is that undionly,kpxe is smaller and is only has a shim between the iPXE kernel and the network adapter. It relies on some firmware on the network adapter to provide basis undi network services. As long as the network card firmware is well behaved then everything works great in this model. The ipxe.kpxe contains the majority of known or common network drivers right in the kernel. This iPXE kernel is bigger for sure but also include very well behaved network drivers.

Just a comparison between the two kernels.
undionly.kpxe is about 93KB in size
ipxe.kpxe is about 343KB in size.

These days with multi GB workstations this is really a trivial matter, but smaller kernels make faster boots. But in reality find the iPXE kernel that works best for your environment and stick with it.

@wcheung That is one option and it will work (as you have seen). If you only have a handful of systems this may be an option so you don’t have to burn a lot of time trying to resolve this issue. This decision is up to you (time vs ease of use).

@wcheung No, don’t touch the files in that directory. Only look to see the file names with .efi extension, then update your dhcp option 67. If you mess (rename/change) with any of the files in the /tftpboot you will break pxe booting.

OK then, I must have missed when you upgraded to 1.3.0. OK then I’m back on having you build a usb boot for the FOS Engine. We have seen certain firmware not support the handoff between iPXE and the FOS Engine. Both bzImage and init.xz get transferred to the target computer then nothing happens. We have seen this on one firmware where the screen freezes but the FOS Engine continues to work for capturing and deploying images. But I think its still the handoff from iPXE to FOS. To test this we created the FOS USB boot process which uses grub to handoff booting to the FOS Engine. If we can get the FOS engine to boot then we can deal with the usb ethernet adapter. There is a kernel parameter to usb nics that may need to be added, but again the kernel is not booting so the kernel parameter at this point is not important.

@craigj1222 Typically you will update your dhcp server, change dhcp option 67 {boot-file} from undionly.kpxe to ipxe.pxe. Then pxe boot the target computer. Now understand that this change will allow all uefi systems to pxe boot. If you need to boot a legacy (bios) system you will need to change this dhcp option back to undionly.kpxe.

If your dhcp server is based on Windows server 2012 you have an option to have the dhcp server automatically switch between the two boot files based on the target system that is booting.

@dustindizzle11 I agree with Tom. What we’ve seen is that if the building switch has Spanning Tree enabled and the switch is not configured for one of the fast spanning tree modes the FOS engine will boot, wait and give up before spanning tree starts forwarding data. On your building switch you need to check to see if STP is enabled, if it is you need to enable one of the fast spanning tree protocols (port fast, RSTP, fast STP, or what ever your switch mfg calls it).

One quick check to see if it is a spanning tree issue, is to put an dumb (unmanaged) switch between the target computer and the building switch and then pxe boot the target computer. That unmanaged switch will keep the building switch from seeing the target nic wink (momentarily drop the port link) as the target transitions from the iPXE kernel to the FOS Engine kernel.

@wcheung So nothing is executing once iPXE hands off to the FOS Engine kernel. In the /tftpboot directory in the fog server, there are other .efi files you can try. I’m going to suspect they will give you the same results, but it would be worth a try.

The next step I would say is to try to create a FOG USB boot drive. This will skip the pxe boot process (which seems to be working) and load the FOS engine right from the usb flash drive. In this case instead of using iPXE to boot, we will use grub to boot. The instructions are here:https://forums.fogproject.org/topic/7727/building-usb-booting-fos-image

Once you build this usb boot drive, I want you to pick the last option which again debug to drop to a command prompt… Oh wait you are using FOG 1.2.0, that doesn’t support uefi firmware well or NVMe disks at all.

Still go ahead and build this usb flash drive. Its based on FOG 1.3.0, I’m interested to see if you can boot into the debug console and pick up an IP address. None of the other menus will work since your FOG 1.2.0 server is missing the needed backend to make it work. BUT, it will tell you if you will have a better chance with FOG 1.3.0 and this computer.

(as you can see as I think more about 1.2.0) Even of you could get the 1.2.0 FOS Engine to boot with the new kernel, the 1.2.0 inits won’t understand NVMe disk, gpt format, and marginally supports uefi. I really think if you have the resources available, you would be better off spinning up a new FOG 1.3.0-RCx FOG server.

@dustindizzle11 said in i219LM NIC, ASUS Q170M-C Motherboard:

@Tom-Elliott
It is bridged.

What, where did a virtualization layer come into scope? My assumption was the FOG Engine was running directly on the hardware.

@dustindizzle11 Try with just one -n I know one of the command line switches should give the output like I posted. -nn worked on centos 7.

@fsabzaali said in Updated FOG Virtual Machine Available:

Can I please get the download link and instructions?!

Thank you for setting this up.

Unfortunately I feel this offer has been abandoned. Your best bet is to create a vritual machine and install linux (either Centos 7 or Ubuntu 14.04) and then install the trunk version of FOG.

Wayne has some pretty good videos here on installing fog as well as there are links to show how to install linux.
https://wiki.fogproject.org/wiki/index.php?title=Installation

Upgrade to trunk
https://wiki.fogproject.org/wiki/index.php/Upgrade_to_trunk

@dustindizzle11 OK now that you are at the debug console I want you to key in the following command lspci -nn

What I’m looking for is the ethernet controller line. This one is from my fog server.

0b:00.0 Ethernet controller [0200]: VMware VMXNET3 Ethernet Controller [15ad:07b0] (rev 01)

The key is the 8 hex keys “[15ad:07b0]” that will be the nic hardware manufacturer and the device ID. You can also view these values from a running windows system this is the vendor and hardware id in the device manager, but since you have the debug console that is the best way to get that information.

@Joe-Gill If you have issues post back since that document is based on some of my input.

I would go with the new vmdk file. Once that is setup and mapped over the images, you can extend that second vmdk file pretty easy as your needs grow. As long as your images partition is the only thing on that new vmdk file.

@wcheung even when you go into the FOG server and boots the logging to 7 then reboot and try to image again?

@wcheung Captain Obvious: “Well that stopped exactly where you said it would.”

1. There are not other errors after that?
2. Have you confirmed that you have the latest firmware on this computer? We have seen flaky early release firmware from lenovo causing this type of error
3. In the fog settings turn up logging level to 7, that may produce more intelligent error messages.

@wcheung Please take a picture with a mobile phone of the exact spot where it stops. Make sure it is a clear picture so we can pinpoint the exact spot in the process.

@zln1996 Sure no problem. Here is the article, the 2012 section is below the linux section. https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence

@zln1996 OK then. Unfortunately, you will have to manually change between the two iPXE kernels. I just thought we could save you some grief with one of our wiki pages that shows how to set this up for 2012 dhcp server.

@zln1996 Is your dhcp server based on windows 2012?

@zln1996 Lets get a few things straight (not meant as harsh as it sounded).

Your target computer is either in bios (legacy) or uefi mode. The devices are not typically flexible they are either in bios or uefi mode. Once you know the mode of the target computer you need to be sure you send the right iPXE kernel to the target computer.

Typically bios (legacy) computers will boot with undionly.kpxe, and typically uefi systems will boot with ipxe.efi. If your dhcp server is a windows 2012 server you can configure the windows dhcp service to send out the right boot file based on the target computer type.

Once the target computer has the right iPXE kernel it should boot no problem. The next issue you will have to uefi systems (as well as bios sometimes) is the exit from the FOG iPXE menu. This is controlled by the exit mode (either globally or defined on a per host basis). You need to test each exit mode with each hardware if sanboot doesn’t work as a global exit mode. This is all configurable, you just have to understand where to look.

Since you have a Win10 OS, I would think your firmware would be uefi right? If that is the case you will need to adjust the uefi exit mode for that system, possibly to refind if one of the other exit modes don’t work. You may need to configure the refind program a bit more too. But lets first identify what firmware mode this thinkpad is in.

@george1421 I can report (at least for AD LDAP) the plugin works as intended. I’m going to dig a bit deeper to make sure its not just a mistake on my part.

I can say I based it working off a false assumption. I still had the AD user cached based on some of the intermediate code. That is why the login worked every time. There is something wrong in the code. Tom and I worked on it for several hours last night. I see what its doing, but need to focus on why its doing what its doing.