@SteveB689 OK so this is just research then. Fair enough.

I’m sorry you had so much frustration setting up FOG. I know it is a complex environment especially for those coming from a purely MS Windows background. Hopefully you found the support you needed in the FOG forums.

On a positive note it sounds like Arrowhead-IT has personal experience with this hardware so you have someone that already went down the path you are on.

@the_great_heed I’m using the trunk version, not 1.2.0, so I’m not sure. This will become our production FOG server since we are adding another 600-700 G2 SFFs.

I agree with Wayne that 0.32 is fairly old and so is the linux kernel for that. What version number of the kernel do you have installed?

For the Win10 you will need to ensure your master (reference) image uses a MBR style disk. GPT is not supported on that old version of FOG. Don’t get me wrong FOG 0.32 will work here as long as you take precautions and have supported hardware/linux kernel. You could “try” to slide in the latest version of the FOG kernel that is 4.5.3. If I remember correctly 0.32 only supported a 32 bit linux kernel so you will need bzImage32 and then rename it to bzImage to be compliant with your inits. DON’T upgrade the to the latest inits because that for sure will break your boot.

You can get the latest 32 bit kernel here, just be sure to rename your original kernel and then rename this one to match your original kernel.
sudo wget https://fogproject.org/kernels/bzImage32

I do have to say the best path (but not the easiest) for you on this endeavor would be to spin up a new FOG server running the trunk version of fog 1.2.0. You will have better success with new hardware, uefi systems, gpt disks, and native win10 support.

@ga1985 Welcome to the forums. This is definitely kind of an unusual FOG question but I am happy to try and find out if we can help you.

Do I get you right there? You are trying to PXE boot and image this network device? As this seems to be kind of a black box device I guess it will be quite hard to find out the drivers we need in the kernel to PXE boot this device. Are you able to boot any kind of live linux (USB key or CDROM) on it? If yes, then give us the full output of lspci -nn and lsblk!

I am unable to get through the registration process.

Any error message you see? Please post a picture here!

@arnaudrigole That’s one way, albeit incredibly labor intensive.

Since you have a 2008 server, maybe you give a shot at setting a vendor class filter in it? There are some screenshots in the below article from 2008 to help you along your way, but I’ve not been successful yet. That’s not to say it can’t be done, it’s just saying it hasn’t been done yet. I was working on a community member’s production 2008 DHCP server and messed with it for a while but no luck. I’m not entirely sure his environment was even setup correctly…

If you are successful, we will be wanting screen-shots and steps for the Wiki.

@george1421 @Sebastian-Roth You can mark this as solved. Since this was a loaner unit from Lenovo, they locked down the bios so I could not fully disable the security chip. Once I changed the bios I was able to disable the chip and image the laptop 🙂

Thanks for you help

I figured it out, I updated to the latest trunk with this guide: https://wiki.fogproject.org/wiki/index.php?title=Upgrade_to_trunk

Now the Problem is solved, also new NICs are able to mount properly!

You guys are great 🙂

@Pascal-Gazaille Does this mean all the symptoms of not being able to deploy to the new disks disappeared?? Scratching my head… Will mark this solved for now anyway.

@jlaporta said in Thinkpad X260:

@george1421 I have 2 fog servers and on my second one which is connected to the same network the kernel information is loading. They are both on the same version also. Is there a problem I can correct on the server that isn’t showing kernel information?

If I remember correctly this might be caused by screwed FTP login data. Please read through this and do some tests.

@george1421 okej ill check that out. Thanks!

Cross linking similar thread where ipxe.pxe solved the issue with the realtek nic.
https://forums.fogproject.org/topic/7241/dhcp-failed-on-hp-prodesk-400-g2

@george1421 said in Toshiba Tecra A-40:

I also see there are references to NBP file name (which tells me uefi mode).

That’s exactly what I thought, too.

@Tom-Elliott said in Which Multcast switch i need:

@ch3i I think asking the networking guys (as well) would also be a good idea.

Exactly…

I don’t know how you make 32 clients work with a 24 port switch.

The switch doesn’t even matter so much. Different amounts of money will get you different performance - but we only know of 1 switch on the entire market that doesn’t work with FOG currently, and it’s a Cisco small business switch.

@Wayne-Workman said:

I then booted into FOS using the on board NIC to see how the adapter is recognized. FOS sees it fine.

Just to make sure the kernel is really happy with it, can you please try DHCP or setting a static IP (ifconfig ethX 10.x.y.z netmask 255.255.x.y up) on that USB NIC when you have FOS up and send pings?

Guess I struck out on this one.

Sounds a bit like it.

At first I thought Tom is right about the NIC chip behind USB being a different story. But reading up on good old John Willis again I think USB should not play a major roll:

because the USB NIC is connected through a USB host controller, that USB host controller must also have a BIOS device driver and the USB host controller must be started before the USB NIC can be started
USB host controllers are internal and fixed, they do not change, they are built into the notebook, so only one device driver needs to be included in the BIOS for the USB host controller built into the notebook

Would be great to test all those machines with one or two different USB NICs. Not sure which one to recommend?! Do you have other adapters?

@josh-martin Are you able to load that URL (…/boot.php) with your browser?? What do you get? Please post the full output here in a code box.

@Wayne-Workman I forgot to set rule option 66 to the server ip and it totally works. You’re the best! Thank you for all you do!

@Omanimous Without knowing the exact details. A 128GB disk (ssd or hdd) from two different manufacturers are usually different sized down to the byte level. So in theory if your source disk is one byte larger than your destination disk a non-resize FOG image will fail.

I can say for my reference image (which I deploy to all hosts), I create on a VM with a 40GB hard drive. That way I’m assured it will deploy to all hardware on my campus. For win10 I use a 60GB reference image.

With FOG 1.2.0 I used non-resizable and then let windows expand the disk. With the 1.2.0 trunk build FOG expands the disk now. I still use a 40GB reference image for Win7. So I always go smaller to larger when the image is deployed.

@Sebastian-Roth I’ve not heard a thing from that building’s techs about this issue. If they try to get this model working with FOG in the future, I’m sure they will Google search it and find this thread, wouldn’t that be humorous?

I’m working with one of them tomorrow, I’ll ask about it.

@Wayne-Workman said:

I’m convinced this is a network issue.

+1 from me!

@Sebastian-Roth

I tried imaging and it works! Thanks for all of the work you guys do!