Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

unable to start driver: [25] incompatible version #14

Closed
ggrellqd opened this issue Sep 27, 2018 · 8 comments
Closed

unable to start driver: [25] incompatible version #14

ggrellqd opened this issue Sep 27, 2018 · 8 comments
Assignees

Comments

@ggrellqd
Copy link

Dear Mr Batard,
I am using your UEFI:NTFS to supply a bootable USB stick with a custom Ubuntu image > 4GB on an NTFS partition to my workgroup.
The last image that I created using Rufus 2.18 and modifying it afterwards to add the necessary grub modules to the boot stick, as discussed here issue

I am now forced to switch to an all linux workflow, so using rufus is not an option anymore.
Instead, I have mimicked the rufus workflow by creating a stick with a large ntfs and a small fat32 partition, and extracted the UEFI:NTFS image supplied at /res/uefi onto the fat32 partition, while having the Ubuntu image on the NTFS partition.

Now, this stick will boot on an ordinary desktop PC, but won't boot on an Apple iMac mid 2010. This is in contrast to the stick created with rufus 2.18, which would boot on all machines, regardless of being Apple manufactured or conventional UEFI capable desktops.

The error message on the iMac is:

git2

Do you have a clue what changes might have caused this issue?

For the time being I will try to use the UEFI:NTFS image that was shipped with rufus 2.18.

Best wishes, Gilbert Grell

@pbatard
Copy link
Owner

pbatard commented Sep 27, 2018

Thanks for the report. Unfortunately I don't have an iMac to test with, and that [25] Incompatible Version message when starting the driver is not something I've ever saw before.

The best guess I have is that somehow the latest NTFS driver is calling on a more modern version of UEFI services that the custom Mac EFI firmware cannot provide.

According to the UEFI specs, EFI_INCOMPATIBLE_VERSION (code 25) technically means that:

The function encountered an internal version that was incompatible with a version requested by the caller.

In layman's term it means that, just as with Operating Systems, different incompatible versions of the same library may exist (when, for instance, a newer version of the library adds a feature that wasn't available with the oldf one), and, depending on the features your application wants to use, it may not be able to make do with the older version of the library, if that's all the EFI firmware provides.

Now, considering that we seem to be seeing a somewhat related problem in pbatard/rufus#1213 that appears to have something to do with switching the compiler from Clang to EDK2 (N.B. I am simplifying a bit here) with the latest versions of UEFI:NTFS, I am starting to suspect that maybe the EDK2 has some defaults that assume that the EFI firmware you use is relatively up to date, and will request some of the newest UEFI features, which older firmwares such as the one from Apple may not be able to provide, hence the error (since Apple does its own thing, and tends to disregard EDK2 compatibility).

As such, one test I would really like you to conduct would be to try replacing your EFI\Rufus\ntfs_x64.efi driver from the UEFI:NTFS partition with one of the ntfs_x64_gcc.efi or ntfs_x64_msvc.efi from https://rufus.akeo.ie/testing/ (preferably the _msvc one. Of course, you should remove the extra _#### part so that the name is ntfs_x64.efi) to see how it goes. Both these drivers are compiled from the latest EfiFs source (our source for the NTFS driver), but use gnu-efi rather than EDK2 to interface with the lower UEFI layers, and I believe gnu-efi may offer greater compatibility with the Mac EFI firmware.

If you confirm this, then I suppose that I'll use gnu-efi based drivers in the next version of UEFI:NTFS, since it seems to solve both issues, if I can't manage to identify what, in the EDK2, appears to create these incompatibilities with "older" firmwares.

@pbatard pbatard self-assigned this Sep 27, 2018
@pbatard
Copy link
Owner

pbatard commented Sep 30, 2018

@ggrellqd, any chance you can run the test I highlighted above?

Without your help, it is next to impossible to troubleshoot this issue, or validate that a potential workaround is suitable, and I will have no choice but to close it. I hope you can appreciate that Rufus is really a one man operation with limited resources so, unlike what you may expect from a Microsoft, IBM, Intel or Google, even if you point to a specific combination of hardware that you know doesn't work, you shouldn't assert that we have means to get our hands on it...

As such, it is crucial that you remain involved in the troubleshooting process, and perform the tests requested (which we'll do our best to guide you through and make as light as possible), as we don't really have any other means to progress on this issue if you don't.

@ggrellqd
Copy link
Author

@pbatard , thank you for the comments,
I just had no time to respond yet, but I will conduct the tests that your requested here:

As such, one test I would really like you to conduct would be to try replacing your EFI\Rufus\ntfs_x64.efi driver from the UEFI:NTFS partition with one of the ntfs_x64_gcc.efi or ntfs_x64_msvc.efi from https://rufus.akeo.ie/testing/ (preferably the _msvc one. Of course, you should remove the extra _#### part so that the name is ntfs_x64.efi) to see how it goes. Both these drivers are compiled from the latest EfiFs source (our source for the NTFS driver), but use gnu-efi rather than EDK2 to interface with the lower UEFI layers, and I believe gnu-efi may offer greater compatibility with the Mac EFI firmware.

I am aware that this is a one man show and I am very well familiar with the consequences of that. I appreciate your work and do not intend to put pressure on you.

Have a nice day!
Gilbert Grell

@pbatard
Copy link
Owner

pbatard commented Oct 20, 2018

Still waiting for that test. Unless you can provide an update in the next few days, I will have no choice but to close this issue.

@pbatard
Copy link
Owner

pbatard commented Nov 25, 2018

No test → Closing.

@pbatard pbatard closed this as completed Nov 25, 2018
@Sporesirius
Copy link

Hey, I'd test that.
I have an iMac9.1 here and when I run UEFI:NTFS I get the same error as mentioned above.
The link https://rufus.akeo.ie/testing/ is dead.

btw. I think Macs (especially the old) have a 1.1 UEFI.

Kind regards,
Sporesirius

@pbatard
Copy link
Owner

pbatard commented Apr 12, 2019

Hey, I'd test that.

This is no longer needed, as the latest UEFI:NTFS embedded in Rufus uses the gnu-efi MSVC version, which is the one that was up for testing. Obviously, if I put some files up for testing, and they don't get tested, I will remove them after a few months.

btw. I think Macs (especially the old) have a 1.1 UEFI.

I don't think it's the UEFI version (I believe I tested on PCs with old UEFI firmwares too), but it's most likely a case of Apple deciding to do their own thing and removing elements that would ensure wider UEFI compatibility.

If I ever have gain access to a Mac and have time to spare (both of these hypotheses being very unlikely in the short to medium term), I may take a look and see what the story is. But otherwise, I'm afraid I have no plan to look into this further.

Still, I'll take a patch, if another developer, with time on their hand and access to an 'older' Mac wants to take the time to investigate and send a fix.

@RustedShader
Copy link

RustedShader commented Feb 17, 2021

Hey, I'd test that.

This is no longer needed, as the latest UEFI:NTFS embedded in Rufus uses the gnu-efi MSVC version, which is the one that was up for testing. Obviously, if I put some files up for testing, and they don't get tested, I will remove them after a few months.

btw. I think Macs (especially the old) have a 1.1 UEFI.

I don't think it's the UEFI version (I believe I tested on PCs with old UEFI firmwares too), but it's most likely a case of Apple deciding to do their own thing and removing elements that would ensure wider UEFI compatibility.

If I ever have gain access to a Mac and have time to spare (both of these hypotheses being very unlikely in the short to medium term), I may take a look and see what the story is. But otherwise, I'm afraid I have no plan to look into this further.

Still, I'll take a patch, if another developer, with time on their hand and access to an 'older' Mac wants to take the time to investigate and send a fix.

so basicly i am stuck with linux now or there is fix out ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants