UEFI - Lenovo MIIX 320 and USB Ethernet

[ale.com]

@george1421 I tried with dev-branch:
Running Version 1.5.0-RC-9
SVN Revision: 6080
ipxe 9720f (or 7156, with ipxe7156.efi) it gets stuck after
“init.xz… ok”

after switching to working I’ve:
Running Version 65
SVN Revision: 6079
ipxe version now is 1b67a, but it still get stuck after init.xz.
“Features” available are not the same as the 356f version. the new ipxe lacks FTP and NFS (TFTP is still there, and bzimage/init.xz are read, so I don’t think it’s an issue).

I tried to update kernel, but I still have “Type: 2, File: /var/www/html/fog/lib/fog/fogftp.class.php, Line: 707, Message: ftp_put(): Could not create file., Host: 192.168.168.91, Username: fog”

I’m installing a new Ubuntu server. In the meantime, any suggestion to troubleshoot this one will be appreciated.

[george1421]

@ale-com said in UEFI - Lenovo MIIX 320 and USB Ethernet:

I tried to update kernel, but I still have “Type: 2, File: /var/www/html/fog/lib/fog/fogftp.class.php, Line: 707, Message: ftp_put(): Could not create file., Host: 192.168.168.91, Username: fog”

The kernel update refers to FOS (the linux OS that is contained in bzImage and the inits), while in theory it could be this I don’t think its getting that far the issue still appears to be in iPXE side or the firmware on the device. I think @Sebastian-Roth had a custom ipxe.efi that sent out debug messages he was testing with another fog admin. Maybe when he has time he can add his wisdom to this thread.

This issue has nothing to do with the host OS (99% sure) or FOS (51% sure) but we should focus on iPXE or target hardware firmware. I do have another solution where we have use usb booting into FOS if everything else fails. I would really like us to understand why its failing and get it resolved. I think others will have the same issue as you in the future.

[Sebastian Roth]

@ale-com said:

it gets stuck after
“init.xz… ok”

We have this happening with pretty much every kind of “newish” tablet/gadget/even some laptops. It’s always got to do with iPXE not being able to hand over to the linux kernel. The reasons for that are different though. One time we had a faulty HP UEFI hardware causing this. On the other hand we’ve also seen this happening as a result of UEFI timer code in the iPXE playing up. And it could be other things as well. We cannot tell until we dig into this. The reason I explain this is that I need to ask you if you are keen enough to go through the debugging process with me? Can take two weeks or four weeks or just a few days sending messages forth and back (try this, yeah shows this on the screen, picture, then try this, yeah… and so on). I am more than happy to do this again and again but I want to ask you if you wanna go there too. There is no point in starting this time consuming work if it stops right in the middle of nowhere because you had to give all the devices to users or have no time to test and send pictures anymore because your boss tells you to work on something else.

Read through this to get an idea of the endeavor: https://forums.fogproject.org/topic/6525/pxe-boot-hp-x2-210-hybrid-tablet-windows-10-pro

So if you’re ready, let’s start by trying different iPXE binaries. Usually this doesn’t help but hey, let’s give it a go anyway. Use snp.efi, snponly.efi, intel.efi, realtek.efi, whichever EFI binary you find in /tftpboot really.

And the other thing is when you get to the iPXE shell and it errors out, key in imgstat just to make sure the binaries are recognized by iPXE. Post a picture.

[Sebastian Roth]

@ale-com bump…

[ale.com]

Hi.
It takes me some time to negotiate with management (and I suppose that in the meantime we should already solved the issue).
Unfortunately, they’re not allowing me to keep one device for all the time needed.
This morning they confirmed me that another path will be followed.

For your info (maybe it could be useful for others) I tried many efi binary, with those results (after updating to trunk):
i386-7156-efi dhcp failed
intel7156.efi dhcp failed
intel.efi dhcp failed
ipxe7156.efi stops after init.xz
ipxe.efi stops after init.xz
realtek.efi dhcp failed
snp.efi stops after init.xz
snponly7156.efi stops after init.xz

ipxe.efi is the only one that, before updating to trunk, allowed me to access the “iPXE prompt” (ipxe7156.efi didn’t)

[Sebastian Roth]

@ale-com said in UEFI - Lenovo MIIX 320 and USB Ethernet:

This morning they confirmed me that another path will be followed.

Thanks for your update. What do you mean by that?

[ale.com]

@sebastian-roth they’re using Windows Deployment Services

[imagingmaster21]

@ale-com Did you try disabling the Security Chip? Also is there a virtualization option in the BIOS settings? You can try to enable that also and it may work. Do you have the argument set in your FOG Config to allow USB NIC?

[Sebastian Roth]

@ale-com It’s really sad to hear that you have to go WDS. All the best to you and hope it is all working out.

[ale.com]

@sebastian-roth don’t worry, it’s an exception. I’m managing many fog servers and it’s great (and still my first choice).

@imagingmaster21 security chip disabled, usb nic allowed in host config, it’s atom: I don’t think it has virtualization support.

Unfortunately, I don’t have any device available to make further tests.