Jump to content
30960 posts in this topic

Recommended Posts

13 minutes ago, vector sigma said:

Don't forget we have 'drivers64' too for duet. Just 'drivers' will not be a solution.

 

Well, yeah, I didn't forget that. :) Buuut...my point is: is there a need to specify "64" when we don't have any 32-bit drivers anyway? 

 

In other words, I'm thinking, since both sets of drivers (drivers64 and drivers64UEFI) are both 64-bit, to remove the "64" part from the name, which would leave us with these two names:

    "drivers" for Duet.

    "driversUEFI" (or "UEFIdrivers", as you wish) for UEFI.

 

The only point I was trying to make, si not to specify "64" anymore in the folder name, if all the drivers inside that folder are 64-bit anyway. There are no 32-bit drivers. So...no need to differentiate between them anymore.

Edited by arsradu
27 minutes ago, vector sigma said:

I'll fix it somehow. Actually I'm adding a preinstall script to do that, but only now I realaze that get overwritten by the "MarkChoice" script that is a preinstall script as well..

Probably caused by what I've already told you just above. Let see..

I need a try... I'll try very soon :)

 

yep, it would make sense for those two issues to be related. So...fixing one might fix the other, as well.

Also, no rush. :) Take your time.

6 minutes ago, arsradu said:

 

Well, yeah, I didn't forget that. :) Buuut...my point is: is there a need to specify "64" when we don't have any 32-bit drivers anyway? 

 

In other words, I'm thinking, since both sets of drivers (drivers64 and drivers64UEFI) are both 64-bit, to remove the "64" part from the name, which would leave us with these two names:

    "drivers" for Duet.

    "driversUEFI" (or "UEFIdrivers", as you wish) for UEFI.

 

The only point I was trying to make, si not to specify "64" anymore in the folder name, if all the drivers inside that folder are 64-bit anyway. There are no 32-bit drivers. So...no need to differentiate between them anymore.

If Slice wants.. for me is ok but only one problem. While renaming drivers makes no difference running them, a problem of retro compatibility exist with old directory. This is not a problem if you in the case will use the installer where surely we will perform a rename action, but in case a user will copy drivers manually a risk of boot failure will happen if you are unaware of the change.

2 minutes ago, arsradu said:

Also, no rush. :) Take your time.

tomorrow, no time today since my son want to eat pizza and patatine for dinner at a specific place chosen by him... I've to obey Lol!

  • Like 2
1 hour ago, arsradu said:

"drivers" for Duet.

    "driversUEFI" (or "UEFIdrivers", as you wish) for UEFI.

By watching the code I've just realized that we can easily implement this with retro compatibility:

 

static VOID ScanDriverDir(IN CHAR16 *Path, OUT EFI_HANDLE **DriversToConnect, OUT UINTN *DriversToConnectNum)

to a function that return true if at least one driver is loaded

static BOOLEAN ScanDriverDir(IN CHAR16 *Path, OUT EFI_HANDLE **DriversToConnect, OUT UINTN *DriversToConnectNum)

where if no drivers is found at 'driversUEFI'... just fall back to 'drivers64UEFI':

 

if (!ScanDriverDir(L"\\EFI\\CLOVER\\driversUEFI", &DriversToConnect, &DriversToConnectNum)) {
  ScanDriverDir(L"\\EFI\\CLOVER\\drivers64UEFI", &DriversToConnect, &DriversToConnectNum);
}

:)  ... see you

Edited by vector sigma
typo
  • Like 1
11 hours ago, vector sigma said:

If Slice wants.. for me is ok but only one problem. While renaming drivers makes no difference running them, a problem of retro compatibility exist with old directory. This is not a problem if you in the case will use the installer where surely we will perform a rename action, but in case a user will copy drivers manually a risk of boot failure will happen if you are unaware of the change.

tomorrow, no time today since my son want to eat pizza and patatine for dinner at a specific place chosen by him... I've to obey Lol!

 

Yep! :) I agree. And you do have a point with those old directories.

 

However, in my opinion, sometimes, moving forward means getting rid of old stuff from your past, so you can make room for new, exciting things waiting for you in the future.

 

In this example, if the user adds those folders back AFTER the fact, that would be kinda problematic indeed. But I think we need to address that issue...rather than keeping old things that are no longer necessary, just for such cases. I'm not sure it's worth it. I don't see many users actually doing this.

 

Also, while there are a few ways we could fix this edge case (such as checking folder structure upon boot and dynamically choosing the right folder) I think it might be easier to simply notify the user about the change (pop-up, message...something). Important thing is to communicate it easily, right within the installer. Since some of them (probably most of them) don't access our sourceforge page to check the changelog, I think the best way would be to include these important announcements right within the installer itself.

 

Something like this:

"please, note that, starting with release xxxx the folder structure for drivers folder has been updated to drivers and driversUEFI respectively. If you're using external folders, please, make sure you update the names accordingly before booting".

 

Also...here's an idea. And it could be a stupid idea. :)) But...instead of looking for a fixed folder structure and causing issues when that folder structure changes, why not try to do it dynamically, and focus on what really matters, which are the actual drivers inside those folders, rather than the folders themselves?

 

I'm thinking...probably, maybe...why not...something similar to what MacOS is doing with Spotlight search. You don't need to know a certain file's location to find it. You just search for it. And while searching in the entire Clover folder might not be really efficient, though I guess we could shorten the search time by indexing the files in a file, so we know where is each file located for each specific user, probably an easier approach would be to look for folders starting with "drivers*".

This way, no matter if you're still using the "old name" or the new names, and even if you ignored the message above that said to update your folder names, you'll still be able to boot, since the focus won't be on the folder structure, but on the actual drivers.

 

So, basically, instead of looking for a folder and a fixed folder structure, (which is kind of a "hardcoded" way of doing things in my opinion, and not really the best approach on the long term, as we can see), look directly for the drivers. Cause those are the ones which will be executed on boot. Those are the important part.

 

Anyway, I wrote so much! :)) I'm sorry about it... :D 

 

I'll let you guys decide what would be the best course of action in this case. I only wanted to share my point of view, and a few ideas. If you guys find any of that useful, then it would be my pleasure to see it in action. If not, let's discuss it further until we find the best possible solution.

Edited by arsradu
  • Like 1
On 7/5/2019 at 8:01 PM, arsradu said:

"drivers" for Duet.

    "driversUEFI" (or "UEFIdrivers", as you wish) for UEFI.

Done, old or new should make no difference. The installer take care of the migration.

 

On 7/6/2019 at 5:44 AM, Slice said:

We should keep retro compatibility.

 

One more wish. Can we include the command

sudo mount -uw /

into install script for Catalina compatibility?

done

 

Also I reorganized all the drivers in the installer and I hope you like it. Also vboxhfs and hfsplus are now auto excluding them self. Please test it on a USB pen drive and let me know. Unfortunately I'm in rush and I've to go... so any commit is postponed at tomorrow... sorry but I've just finish the job with some tests but no other time.

 

 

 

Edited by vector sigma
package removed. Changes committed to r4983
  • Like 2
17 minutes ago, vector sigma said:

Done, old or new should make no difference. The installer take care of the migration.

 

done

 

Also I reorganized all the drivers in the installer and I hope you like it. Also vboxhfs and hfsplus are now auto excluding them self. Please test it on a USB pen drive and let me know. Unfortunately I'm in rush and I've to go... so any commit is postponed at tomorrow... sorry but I've just finish the job with some tests but no other time.

 

 

Clover_v2.4k_r4979.zip

 

That...is beautiful. That's pretty much what I had in mind. Well done.

 

Will test it out and let you know. Also, no worries. And no rush. We've got plenty of time. :) 

 

Edited by arsradu
On 7/4/2019 at 8:17 PM, vector sigma said:

Hi @Slice and all, I need testers for the attached package that has a new abilities:

 

  1. MemoryFix group where OsxAptioFix3Drv.efi, OsxAptioFixDrv.efi and OsxLowMemFixDrv.efi now reside. Only one driver is selectable. A preinstall script, if any of them is selected, will remove any drivers named *memoryfix*, *aptiofix* or *memfix*, i.e. each old memory fix drivers will be deleted. Nothing will happen if you use AptioMemoryFix.efi and you selected none of them but mind that the package will record if you previously selected one of them..
  2. The package during the installation now rename drivers by removing the -64 suffix, i.e., DataHubDxe-64.efi will be DataHubDxe.efi.
  3. I have a commit ready where ebuild.sh now no longer uses the -64 suffix, no downloadable drivers (bye bye --ext-pre, --ext-co etc.), only one used by Clover and where I've completely eradicated each sign of 32 bit.

Please guys test and report back, thanks! Later I'll post the changes...

Clover_v2.4k_r4979.pkg.zip

 

 

whit this new version I have no lucky ... see this error...   

I made a mistake? ... I have installed the new version as before.
 

IMG_2430.JPG

Edited by corint1
18 hours ago, vector sigma said:

Done, old or new should make no difference. The installer take care of the migration.

 

done

 

Also I reorganized all the drivers in the installer and I hope you like it. Also vboxhfs and hfsplus are now auto excluding them self. Please test it on a USB pen drive and let me know. Unfortunately I'm in rush and I've to go... so any commit is postponed at tomorrow... sorry but I've just finish the job with some tests but no other time.

 

 

Clover_v2.4k_r4979.zip

 

 

Hi Vector!

 

There seem to be some weird differences between SSD installation and USB installation. In the sense that, for USB installation, some of the bugs below do not occur. Not sure why...

 

For example, for USB installation, bug #1 (aside form the typo, which occurs no matter what), does not occur.

 

So...here's what I managed to find so far with this build:

 

1. (occurs only when installing on SSD)

 

Previously installed Recommended drivers are not kept selected when reinstalling/upgrading the app (same issue we had with Memory Fixes, only that one is now fixed). Probably the same MarkChoice issue as before.

 

Reinstall on the SSD:

 

1889271097_Screenshot2019-07-07at12_56_50.thumb.png.42aabe63769ba4990f73d86e9461e180.png

 

 

Reinstall on the USB:

 

1020086629_Screenshot2019-07-07at12_56_15.thumb.png.e634c41b305d22421efecf5d191095b3.png

 

Typo (for both SSD & USB): it should be "recommended" not "reccomended". 

 

2. (occurs for both SSD and USB)

 

Themes recommendation: Themes section is displayed above UEFI Drivers section in the old installer. Now it's displayed as the last one in the list. Not a big issue, but I would suggest keeping Themes above PrefPane. That would make more sense to me...

 

3. (occurs for both SSD and USB)

 

FSInject not checked by default on first install, although it is one of the mandatory drivers. And it is kept on reinstall. Just not added by default.

 

Extras:

 

4. Do we ship with HFSPlus (for as far as I know it's not supposed to be included), or is this just for testing?

 

5. No FakeSMC.kext included with this build...? I think it should be included starting with version 4961.

 

4 hours ago, Download-Fritz said:

Use AptioMemoryFix, not AptioFix

 

I;m not rename any file... my file is AptioMemoryFix nop AptipMemoryFix ... something is wrong with code .... please check image .. I just install what I'm downloaded from link . 

Edited by corint1
On 7/6/2019 at 2:57 AM, vector sigma said:

When I'll fix a stupid problem, for you will be easy:

don't install any of OsxAptioFix3Drv.efi or OsxAptioFixDrv.efi or OsxLowMemFixDrv.efi and your driver will never be touched. 

 

Is clear that if you install them instead, your driver will be deleted (or to saying better is moved to the backup directory) because is conflictual.

 

right. there is no problem. thank you so much vector.

hope add this command

sudo mount -uw /

sudo killall Finder

I have an odd question. I've been trying to make a USB booter of Clover and on several different USB flash drives, Clover has not created an EFI partition even though I have selected Install on ESP on several, but not all the drives. I have reformatted more than once and in more than one format to try wipe out any weirdness.

 

Has anyone else encountered this?

23 minutes ago, pkdesign said:

I have an odd question. I've been trying to make a USB booter of Clover and on several different USB flash drives, Clover has not created an EFI partition even though I have selected Install on ESP on several, but not all the drives. I have reformatted more than once and in more than one format to try wipe out any weirdness.

 

Has anyone else encountered this?

 

Hi

Clover don't create EFI partition, only copy files. You're to choose: install for UEFI  and Install in ESP for your usb drive (GPT/ macOS journalized)

22 hours ago, corint1 said:

 

I;m not rename any file... my file is AptioMemoryFix nop AptipMemoryFix ... something is wrong with code .... please check image .. I just install what I'm downloaded from link . 

Yes, this is misprint in Clover. I will correct it soon.

But it is not influence on the error. You should choose other MemoryFix driver.

Hi Clover Team

 

macOS Catalina introduce Read Only. There is a problem with actual Clover Package, solved by Terminal command or else. But there is also a issue with EFI-Backup Folder: content can't be delete for same reason (read only)

 

I hope for a new commit for those two issues. Please.

Capture d’écran 2019-07-08 à 15.26.59.png

  • Like 1
On 7/7/2019 at 11:14 AM, Matgen84 said:

 

Hi

Clover don't create EFI partition, only copy files. You're to choose: install for UEFI  and Install in ESP for your usb drive (GPT/ macOS journalized)

That is what I always thought. So I am guessing this is some sort of macOS weirdness? (see attached)

Terminal Saved Output.txt

On 7/7/2019 at 12:13 PM, arsradu said:

There seem to be some weird differences between SSD installation and USB installation. In the sense that, for USB installation, some of the bugs below do not occur. Not sure why...

 

For example, for USB installation, bug #1 (aside form the typo, which occurs no matter what), does not occur.

 

So...here's what I managed to find so far with this build:

 

1. (occurs only when installing on SSD)

Fixed. 

 

On 7/7/2019 at 12:13 PM, arsradu said:

Typo (for both SSD & USB): it should be "recommended" not "reccomended". 

Fixed.

 

On 7/7/2019 at 12:13 PM, arsradu said:

FSInject not checked by default on first install, although it is one of the mandatory drivers. And it is kept on reinstall. Just not added by default.

Fixed.

 

On 7/7/2019 at 12:13 PM, arsradu said:

4. Do we ship with HFSPlus (for as far as I know it's not supposed to be included), or is this just for testing?

Just for my tests.

 

On 7/7/2019 at 12:13 PM, arsradu said:

5. No FakeSMC.kext included with this build...? I think it should be included starting with version 4961.

Never included in the pkg, it's there for a long time just for the iso image. Slice just update it.

 

On 7/7/2019 at 1:02 PM, Sherlocks said:

hope add this command

sudo mount -uw /

sudo killall Finder

Already there and working. But no 'killall Finder' it is really unpleasant

 

On 7/8/2019 at 3:27 PM, Matgen84 said:

macOS Catalina introduce Read Only. There is a problem with actual Clover Package, solved by Terminal command or else. But there is also a issue with EFI-Backup Folder: content can't be delete for same reason (read only)

Latest pkg can! But you have to ignore the message that says "Installer has detected a read only file system..bla bla.." because what you see is a message from Installer.app located at:

/System/Library/CoreServices/Installer.app

and the message you see is just because he don't know that our preinstall script is going to check the file system and make it rw if isn't:

if [ "${DEST_VOL}" == "/" ]; then
  # Check if the root file system is writable. In 10.15+ isn't
  if [ ! -w / ]; then mount -uw / ; fi
fi

tested and working!

 

On 7/5/2019 at 8:01 PM, arsradu said:

"drivers" for Duet.

    "driversUEFI" (or "UEFIdrivers", as you wish) for UEFI.

I've changed idea at last:

drivers64 -> BiosDrivers
drivers64UEFI -> UEFIDrivers

probably you have to manually delete "drivers" and "driversUEFI" from the old test package. 

 

On 7/7/2019 at 7:50 AM, corint1 said:

whit this new version I have no lucky ... see this error...   

I made a mistake? ... I have installed the new version as before.

OsxAptioFix3 was working until Mojave for me, but just few minutes ago I tested it in Catalina and it fail. Need a fix  (@Slice)

 

 

 

Edited by vector sigma
attachment removed as Clover is under development
1 hour ago, pkdesign said:

That is what I always thought. So I am guessing this is some sort of macOS weirdness? (see attached)

GPT don't have an ESP if the disk is  <=2 GB. It's also written to your log:

/dev/disk4 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *2.0 GB     disk4
   1:                  Apple_HFS Boot                    1.9 GB     disk4s1

...that disk4 doesn't have it. Take a 4 GB stick at least ;)

  • Like 1
2 hours ago, vector sigma said:

GPT don't have an ESP if the disk is  <=2 GB. It's also written to your log:


/dev/disk4 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *2.0 GB     disk4
   1:                  Apple_HFS Boot                    1.9 GB     disk4s1

...that disk4 doesn't have it. Take a 4 GB stick at least ;)

 

i tested lastest commit.

strangely i can't install only clover without terminal command. 

also i have a question. previous clover package have checked default driver. there is no default driver in new package. is it right?

×
×
  • Create New...