Tablet with WINDOWS 10 and USB-LAN SMC 7500 adapter

[Sebastian Roth]

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

[AndrewG78]

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

[Sebastian Roth]

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

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

[AndrewG78]

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

[george1421]

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

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

[george1421]

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

[Sebastian Roth]

@AndrewG78 I just added the refind_ia32.efi binary to dev-branch so it will be part of the next release.

[AndrewG78]

@Sebastian-Roth
Gr8 news. Thx a lot