I have the same issue on the Realtek 8168. But this is all under hyper-v. On my old pc, with intel NIC, everything worked fine, but now on my new PC with the Realtek 8168 I am running FOG as a virtual machine and a PXE client on. All on hyper-v. It looks like hyper-v inherits the properties of the host system, even with private networks. When using EFI it all works, just not on a legacy NIC.

@wdawson61 Thanks for the pictures and testing. Great you made that network dump too! Looks like you are right, it is seen as platform=pcbios aka legacy BIOS. I guess this is CSM/BIOS compatibility mode in UEFI. See if you can switch to proper UEFI!

@mwarner You can or leave it at 4.13.6 since that has proven to work with the surface devices. When 1.5.0 stable is eventually released it will contain that or a later kernel anyway.

I guess I need to look into why 1.5.0RC10 is giving us an issue with USB booting.

Sorry I’m a bit confused by your post. Are you saying the hp mini 260 IS working with fog or you have issues with it?

Edit, I just saw the other thread where you have it working.

[mod note] I’m going to nuke this thread since it appears to have been created by mistake. Geo-

[mod node 2] I’m resurrecting this post for a short period of time to ensure the OP is clear why I removed it.

@bloodwar I have looked through the code up and down, forth and back… Just don’t know all about UEFI and have no idea why this goes wrong. I am pretty close to sending a message to the kernel mailinglist. But before that I’d like you to try other kernels first. Please use some older kernels just to see if those can boot on that device. I think the easiest way is to download old kernel binaries here and here, plugin the USB key you made and put the kernel binary on it as EFI/BOOT/BOOTX64.EFI (rename that file - GRUB EFI binary).

Now boot the Lenovo N24 off that USB key and see how far you get. If you see Kernel Panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)) than you are past the issue. If it just sits there for 3 minutes then I’d expect it to be locked. Please try at least 10 kernel binaries of various versions from the links above.

@guruprasad-g Have you tried deploying to different machines (same dell 5480 model)? Please take a picture of the blue screen and post here. Possibly we see something there what would help.

@bloodwar Please lets keep in mind that using a different USB NIC could lead to a different issue. Possibly it’s a good idea to open a complete new thread and just cross link those two. I just want to avoid mixing things up. So lets move the discussion here for now: https://forums.fogproject.org/topic/11201/lenovo-n24-usb-nic-with-asix-ax88772c-chip

@sebastian-roth Yeah, there was the wrong path in it. Thank you very much.
So it’s not a hardware problem.

How did this happen? I installed it twice on the system. The first time I hit Enter when I asked for the database password. But that was wrong. I then uninstalled it and reinstalled it from the front. Maybe something went wrong. In particular, uninstalling was very fast compared to installing.

@geardog I thought you might just want to start from scratch, install a fresh clean windows 7 in UEFI mode. But seems like you could even convert form legacy BIOS to UEFI if you are keen: https://social.technet.microsoft.com/wiki/contents/articles/14286.converting-windows-bios-installation-to-uefi.aspx

@sebastian-roth @george1421

Without your guidance i would have not been able to provide that information to you. Linux is still relatively unknown to me. I know what I am able to google, read in your wiki, or do as you posted here. Everyone’s help was much appreciated.

@christian99x said:

Should we continue? It will take me some time to do a mirror port capture (but I’m definitely okay doing this)

Don’t worry about the mirror port. It’s definitely fine to use ipxe.pxe if it works for you. Some work better (or at all) for different hardware. Just see if you can boot all your hardware using ipxe.pxe. If so, just stick to that. We default to undionly.kpxe because that causes the least issues. But as we see there are pieces of hardware around not liking the UNDI driver stuff.

@Quazz Thanks heaps for mentioning the other binaries. I had thought about this as well but forgot to mention it in my last post.

@msaglioc99 Just bumping this so we don’t loose track of it…

@geardog said in Dell Latitude 7480 - Cannot Find Disk on System:

XPS8920

This is a totally different hardware. Although what you see seems similar it could be something very different causing the issue in your case. Pleas open a new thread and post all your details, like FOG version, UEFI/legacy BIOS.

As well I’d suggest upgrading the firmware on the machine(s).

@george1421 I’m very sorry i made a big mistake i mix the letter A with the number 4 in the mac address you can mark as Resolved.
Thanks again.

@pcayphas said in RTL 8111B - Not Booting PXE:

Only PCs with RLT 8111B are refusing to connect to the fog server.

To take this a bit further and be really able to help you we need a more precise description or best photo/video of what you are running into. There are about ten to 15 different cases I know from the top of my head that would match your description. We need to be clear on what error/hang/issue you see!!

Maybe there is something in this discussion that might help: http://www.edugeek.net/forums/o-s-deployment/39383-pxe-boot-realtek-8111b-c.html

@Lee-Rowlett Any news on this yet?

Well, that url is exactly what I needed!! however I gave up and made a new vm with Fog 1.5, it was able to image the 7040 with no issue… I just didnt want to deal with the partimage vs partclone thing, but it is looking good now.

@imagingmaster21 I need model numbers.

@sebastian-roth

Sweet. The default setting for the loglevel is 4. Taking it down to 3 no longer produces those USB errors. Thank you. The computer does register and I can image but those USB errors were extremely annoying. Seems like this will suppress those messages and works just fine now.

@m144 Thanks for that. OMG, how many new USB devices are there just by plugging into the dock. Yeah the ID 045e:07c6 seems about right. Though this has been added to the kernel (official and our custom build one) source code long ago.

Re-reading what you said before I feel this is a really hard one to nail down. Seems like we have the driver right in the kernel and it does come up with an IP part of the time but not always. Not really sure where to go from here. Hmmmmm