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

Thanks for the reply Sebastian and sorry for the super long delay.

I am observing this behavior when using “ipxe.pxe” – I have not used any other one binary (not since I switched it to a production server a couple months ago).

Also, to clarify, the transfer rate is good once the transfer begins, it is only when it is “configuring net0” that it seems to be a slow link. However, I assume it is some hardware dependent issue as I just tried a random computer model and saw it was configuring at the expected 1Gb link speed.

So I guess the tl;dr is that this isn’t really a problem.

@Sebastian-Roth The latest build worked. I’ll try and put this in a new thread later today.

@Sebastian-Roth Just for reference: I could never make that work correctly on 2008. I may have missed something or two, but I messed with trying to get it to work for a day or so and gave up. Maybe someone else better than me can get it working.

@Quazz @george1421
Thank you both for your answers, appreciate it. I started with the easy solution suggested by Quazz, and it fixed it!
Now running trunk 6677 and the registration just works fine!
Thanks a lot.
Next time I have a problem, I’ll update first, then post on the forum 🙂

@Sebastian-Roth Doing my best. 😉