Tablet with WINDOWS 10 and USB-LAN SMC 7500 adapter



  • I have some not standard tablet(WINDOWS 10).
    It supports both USB and PXE.
    I have docking station with USB -LAN SMC 7500, but it is recognized as network card in BIOS and I can select it to boot through the PXE.
    It even connects to FOG server, but then I got EFI PXe boot error.
    I was trying a few different efi kernels, and even downloaded
    http://ww1.microchip.com/downloads/en//softwarelibrary/obj-lan95xx-uefi/lan95xx_7500_uefi_driver_0.10.zip
    to test SmscUsbNetDriver.efi

    logs:
    I put dots(…) in the places whre MAC address was shown
    "
    Aug 20 10:55:28 localhost dnsmasq-dhcp[9463]: 2705516733 available DHCP subnet: 172.18.147.206/255.255.255.0
    Aug 20 10:55:28 localhost dnsmasq-dhcp[9463]: 2705516733 vendor class: PXEClient:Arch:00006:UNDI:003001
    Aug 20 10:55:28 localhost dnsmasq-dhcp[9463]: 2705516733 PXE(ens160) 70… proxy
    Aug 20 10:55:28 localhost dnsmasq-dhcp[9463]: 2705516733 tags: UEFI32, ens160
    Aug 20 10:55:28 localhost dnsmasq-dhcp[9463]: 2705516733 bootfile name: i386-efi/ipxe.efi
    Aug 20 10:55:28 localhost dnsmasq-dhcp[9463]: 2705516733 next server: 172.18.147.206
    Aug 20 10:55:28 localhost dnsmasq-dhcp[9463]: 2705516733 broadcast response
    Aug 20 10:55:28 localhost dnsmasq-dhcp[9463]: 2705516733 sent size: 1 option: 53 message-type 2
    Aug 20 10:55:28 localhost dnsmasq-dhcp[9463]: 2705516733 sent size: 4 option: 54 server-identifier 172.18.147.206
    Aug 20 10:55:28 localhost dnsmasq-dhcp[9463]: 2705516733 sent size: 9 option: 60 vendor-class 50:58:45:43:6c:69:65:6e:74
    Aug 20 10:55:28 localhost dnsmasq-dhcp[9463]: 2705516733 sent size: 17 option: 97 client-machine-id 00…
    Aug 20 10:55:31 localhost dnsmasq-dhcp[9463]: 2705516733 available DHCP subnet: 172.18.147.206/255.255.255.0
    Aug 20 10:55:31 localhost dnsmasq-dhcp[9463]: 2705516733 vendor class: PXEClient:Arch:00006:UNDI:003001
    Aug 20 10:55:31 localhost dnsmasq-dhcp[9463]: 109533102 available DHCP subnet: 172.18.147.206/255.255.255.0
    Aug 20 10:55:31 localhost dnsmasq-dhcp[9463]: 109533102 vendor class: PXEClient:Arch:00006:UNDI:003001
    Aug 20 10:55:31 localhost dnsmasq-dhcp[9463]: 109533102 PXE(ens160) 70… proxy
    Aug 20 10:55:31 localhost dnsmasq-dhcp[9463]: 109533102 tags: UEFI32, ens160
    Aug 20 10:55:31 localhost dnsmasq-dhcp[9463]: 109533102 bootfile name: i386-efi/ipxe.efi
    Aug 20 10:55:31 localhost dnsmasq-dhcp[9463]: 109533102 next server: 172.18.147.206
    Aug 20 10:55:31 localhost dnsmasq-dhcp[9463]: 109533102 sent size: 1 option: 53 message-type 5
    Aug 20 10:55:31 localhost dnsmasq-dhcp[9463]: 109533102 sent size: 4 option: 54 server-identifier 172.18.147.206
    Aug 20 10:55:31 localhost dnsmasq-dhcp[9463]: 109533102 sent size: 9 option: 60 vendor-class 50:58:45:43:6c:69:65:6e:74
    Aug 20 10:55:31 localhost dnsmasq-dhcp[9463]: 109533102 sent size: 17 option: 97 client-machine-id 00…
    Aug 20 10:55:31 localhost dnsmasq-dhcp[9463]: 109533102 sent size: 25 option: 43 vendor-encap 06…
    "
    First screen: I have to make a short movie to catch this. It is displayed for about 0.5s in top left corner
    0_1534853053882_3bb8f259-b722-48d4-8141-bb8164e197b3-image.png
    This short message is displayed on the center of the screen.
    I just blurred my MAC address
    0_1534853066656_0f2e072d-2a7c-404d-8a9c-dba93592e99e-image.png


  • Moderator

    @Sebastian-Roth said in Tablet with WINDOWS 10 and USB-LAN SMC 7500 adapter:

    • I would rename 64 bit refind back to it’s original name refind_x64.efi - any suggestions why this would harm anything?

    Well I see this as 2 schools of thought (sorry no answer from me).

    1. We should keep the naming convention in line with how the developers of the other FOSS code designed it. That way we have a consistent naming convention across all FOSS applications. You as a developer won’t need to remember to rename bits from other projects every time there is an upgrade.
    2. FOG does currently have a (kind of) naming standard already with bzImage and bzImage32. You could extend that to refind.efi, refind32.efi, refindARM.efi. This renaming could be done via bash scripts so it was consistent on every build.

    Q: Since ARM is supported should we also have a refind for ARM processors?

    • Should we have separate configurations for 32 bit and 64 bit?

    Is there any architecture differences for the configuration file? If not keep the single configuration file. With that said, I see both 32 bit and ARM as exceptions rather than a constant. There may be great value in having architecture specific configuration files because of these exceptions.

    • Right now I select the binary automatically using iPXE buildarch. Or should we make this two options for users to select from? On the one hand it might confuse people but on the other hand we have seen 64 CPU that were pinned to 32 bit causing issues.

    Are you thinking about adding a new exit mode (SANBOOT, rEFInd, GRUB, etc) Like rEFInd32 and rEFIndARM? If so I think the default rEFInd should have the logic that uses buildarch to pick the right refind automatically (like it does for bzImage) then the FOG admin can override with a different exit mode, akin how they can define the bzImage32 kernel if needed.

    • Which rEFInd version are we on at the moment?

    I think what was shipping was 0.11.3 but some bugs were found in it so we had recommended FOG admins to roll back to 0.11.0.

    • I removed the ARM boot stuff as we didn’t have the correct binaries in the repo anyway. grub4dos does not even exist for ARM I think. Sure we can add back rEFInd for ARM but I wonder if we ever had users with ARM clients?! @Tom-Elliott what do you think?

    ARM was added by a forum member. I did a quick search and found ARM discussions here:

    https://forums.fogproject.org/topic/11490/what-is-the-status-of-aarch64-support-for-fog

    Possibly he/she could provide some insight on any difficulties that were experienced with FOG and ARM systems.


  • Developer

    @AndrewG78 @george1421 I started adding the refind 32 bit stuff but then saw that I have a couple of open questions hanging. So I just opened a new feature branch for that and pushed the first proposal of code changes - see here. This way we can discuss things and I can make further adjustments before actually merging this back into dev-branch.

    • I would rename 64 bit refind back to it’s original name refind_x64.efi - any suggestions why this would harm anything?
    • Should we have separate configurations for 32 bit and 64 bit?
    • Right now I select the binary automatically using iPXE buildarch. Or should we make this two options for users to select from? On the one hand it might confuse people but on the other hand we have seen 64 CPU that were pinned to 32 bit causing issues.
    • Which rEFInd version are we on at the moment?
    • I removed the ARM boot stuff as we didn’t have the correct binaries in the repo anyway. grub4dos does not even exist for ARM I think. Sure we can add back rEFInd for ARM but I wonder if we ever had users with ARM clients?! @Tom-Elliott what do you think?

  • Moderator

    @AndrewG78 said in Tablet with WINDOWS 10 and USB-LAN SMC 7500 adapter:

    Are there any news regarding refind_ia32.efi?

    @Sebastian-Roth if refind_ai32.efi is included (I think it should be), then the ipxe menu will need to be reworked a bit to take that into account. Right now everything calls refind.efi. I think a simple test using the arch parameter could redirect the call to refind_ai32.efi vs refind.efi. I had it worked out a bit ago, but that fell off the table too.



  • @Sebastian-Roth
    Are there any news regarding refind_ia32.efi? Will this 32 bit version of refind be included in the FOG installer ?


  • Developer

    @AndrewG78 Checksum was added to the code in dev-branch and will be part of a next release to come.


  • Developer

    @AndrewG78 said in Tablet with WINDOWS 10 and USB-LAN SMC 7500 adapter:

    So, I suspect that the installer only checks if the files exist, but does not check if the checksums match.

    So far we don’t do hash sum checking for the binaries archive. I will add that soon as we have that for other binaries being downloaded already and shouldn’t take much effort to add.



  • @Sebastian-Roth
    OK, I have re-downloaded 1.5.5 binaries and have NO errors, so my conclusion was wrong- new 32bit init and kernel are OK.
    So, the question in my mind is, how did it happen?
    I try to recreate events from the memory.
    During first installation I had an error, saying that Installer is not able to unzip binary files. I found that the zip had wrong size, so I removed it by hand and started the installation again and it was succeeded this time.
    So, I suspect that the installer only checks if the files exist, but does not check if the checksums match.
    I know it is to much works with md5sum, so I think all files should be overwritten(except configs) every time I run the installer.
    What do you think?


  • Developer

    @george1421 @AndrewG78 Yeah nice idea. Let’s see if we can figure out what is causing the hang. Unfortunately you can only use 1.5.4 init with 1.5.5 kernel but not the other way round (just tested). So please try that and also the suggested re-download of kernel and init. Please let us know the results.


  • Moderator

    @Sebastian-Roth Is there anything in the latest (1.5.5) inits that require the latest kernel? The idea is if redownloading the current inits don’t work, the try to roll back just the kernel to the 1.5.4 release. That way we could tell if its the inits or the kernel at fault here? From the picture it doesn’t appear that the kernel is even starting to run.


  • Developer

    @AndrewG78 said in Tablet with WINDOWS 10 and USB-LAN SMC 7500 adapter:

    Unfortunately version 1.5.5 has some issue /bug with 32bit version of init and kernel files.

    Hmmm, that’s interesting. Good you had the idea to test the 32 bit versions from 1.5.4. But are you sure it’s the binaries or could it be this specific hardware you have? I am asking because I have just tested 32 bit (virtual machine) and it boots fine for me, no hang.

    Sure we have changed a couple of things in the kernel and init from 1.5.4 to 1.5.5 but I am not aware of anything that would cause an issue for 32 bit systems.

    Can you please try re-downloading the latest 32 bit init and kernel and see if those are working? Those are identical to the ones you get in binaries1.5.5.zip. I just checked the md5sums.

    e6e447d01b986c339570dd39bac5ad7c  bzImage32
    b1bd16a6c268589d214bafb5a4e51178  init_32.xz
    

    If you have the same ones and they still fail I would ask you to test on another 32 bit client hardware.



  • @george1421
    Hi George,
    Puzzle is solved now :)
    Unfortunately version 1.5.5 has some issue /bug with 32bit version of init and kernel files.
    I have manually downloaded binaries1.5.4.zip and overwrote bzImage32 and init_32.xz in the ipxe folder and all is working fine!!!
    Could anyone check it and confirm my words?



  • @george1421
    Hi, I have another puzzle to solve :(
    I had to run FOG server on another hardware. I obviously ran nmtui-edit and updateIP.sh community script.
    And this time I have in logs
    in.tftpd[12096] Error code 8. User aborted the transfer
    in.tftpd[12097] Client 192.168.1.18 finished i386-efi/ipxe.efi

    and Tablet freezes on this screen
    0_1543661320911_e0c62fb2-137b-4ee7-a8d6-567b9408f649-image.png



  • @george1421
    It works now.
    Im not sure what was that.
    I have updated centos through the yum update
    Then it did not even load fog interface on 192.168.1.1/fog but on localhost/fog only.
    So I have installed FOG again like an update, it has finished with an error “DB backup failed”
    But, surprisingly all works correctly now.
    Thx again for your time,
    I think something was not up to date in the system, but why did it work with regular laptop but didn’t with the tablet? Strange a bit.


  • Moderator

    @AndrewG78 This device is being detected as a 32 bit uefi system. So its being told to load ipxe from the i386-efi directory.

    I would start out on the FOG server and ensure that ipxe.efi exists in `/tftpboot/i386-efi directory. the error message says it requested the file but the responded file size is 0.

    Can we also assume that 192.168.1.1 is the IP address of your fog server?



  • @george1421
    Hi.
    I have new FOG server with the newest 1.5.5 version(centos 7 ), but this time acting as a DHCP server(no dnsmasq anymore).
    It works fine with regular laptop, but again on this Tablet I got strange tftp behavior.
    I have checked tftp from windows machine and this file could be downloaded with no issues.
    But on the tablet I got:
    0_1543594734030_2e12da0a-a999-4444-bb60-c45eb661ab97-image.png

    There is nothing in the /var/log/messages



  • @george1421
    OK that was clear to me. Just wanted to see if FOG can benefit somehow through this tough work with my tablet :)


  • Moderator

    @AndrewG78 I need to talk to the developers about this. I feel yes since fog supports both 32 bit and 64 bit environments, that refind 32 bit needs to be included.

    BUT I’m afraid it will not help you since your system is a 64 bit imposter, in that the CPU is reporting its 64 bits, but the hardware manufacturer has locked it in 32 bit mode. I looked through smbios to see if there was a system board setting that would report the data width so we could see if FOG can classify the system better. But there wasn’t anything I could see in smbios that reported we could key off of. I did see using dmidecode that the Processor section says its 64-bit capable (on my VM), but I don’t know if that would work correctly on your non-standard hardware.



  • @george1421
    Thanks for your support here. Yes we can close it.
    Im just curious, what about refind in 32 and 64 bit ? Will this be supported in the next FOG release out of the box?


  • Moderator

    @AndrewG78 said in Tablet with WINDOWS 10 and USB-LAN SMC 7500 adapter:

    It’s 32bit version.

    Ah that explains a bit. These did some electronic trickery to make a 64 bit processor think its a 32 bit one.

    So you have a workaround for this system now? Can we close this issue because there is not much FOG can do with scripting around this?


 

423
Online

5.4k
Users

12.6k
Topics

118.9k
Posts