Jump to content

Clover General discussion

ErmaC

By ErmaC,
in Clover

 Share
30960 posts in this topic

Recommended Posts

PMheart
PMheart
Posted
Posted

Update

Commits 4025 - 4027: Sync some of Patches_for_EDK2 to latest EDK2 + resolve error mentioned in posts yesterday.

Commits 4028, 4030: Explained in "Clover Change Explanations" + added parametrization in commit 4030 to allow -gcc53 to be used on both Linux and Darwin builds where GCC binaries are located in different paths.

Hi. I found that mtoc is still installed in /usr/local/bin instead of $TOOLCHAIN_DIR/bin/mtoc.NEW

  • Like 1
Zenith432
Zenith432
Posted
Posted

installing in /usr/local/bin requires sudo, so the script installs in $TOOLCHAIN_DIR/bin/mtoc.NEW to avoid sudo.  After script you have to copy it manually

sudo /bin/cp -p $TOOLCHAIN_DIR/bin/mtoc.NEW /usr/local/bin

:blink:

Hi. I found that mtoc is still installed in /usr/local/bin instead of $TOOLCHAIN_DIR/bin/mtoc.NEW

  • Like 1
PMheart
PMheart
Posted
Posted (edited)

installing in /usr/local/bin requires sudo, so the script installs in $TOOLCHAIN_DIR/bin/mtoc.NEW to avoid sudo.  After script you have to copy it manually

sudo /bin/cp -p $TOOLCHAIN_DIR/bin/mtoc.NEW /usr/local/bin

:blink:

Sorry I use Micky's script to build Clover. But I found nothing in his script on this. Actually. It seems that we shall always call mtoc.NEW from /usr/local/bin instead of $TOOLCHAIN_DIR/bin right?

 

Yup. Firstly I ran buildmtoc.sh.

/Users/vanilla/Documents/Build_Clover/src/edk2/Clover/buildmtoc.sh 

Status: cctools-895.tar.gz not found.
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 1675k  100 1675k    0     0   115k      0  0:00:14  0:00:14 --:--:--  182k
- Creating new RAM disk

Initialized /dev/rdisk1 as a 300 MB case-insensitive HFS Plus volume
-  cctools-895 extract...
-  cctools-895 make mtoc...
-  cctools-895 installing mtoc...
-  cctools-895 mtoc installed in /Users/vanilla/src/opt/local

- Ejecting RAM disk
"disk1" unmounted.
"disk1" ejected.

Okay. Without errors. But I prefer to put Clover source code related in ~/Documents/Build_Clover/src, rather than ~/src. And I copied ~/src/opt/local/bin/mtoc.NEW to ~/Doc*/Build_Clover/src/opt/local/bin/mtoc.NEW

 

And previously I have mtoc.NEW installed in /usr/local/bin like this.

Vanillas-MacBook:~ vanilla$ ls /usr/local/bin | grep -i mtoc
mtoc
mtoc.NEW

Then. After installing mtoc in ~/Doc*/Build_Clover/src/opt/local/bin/mtoc.NEW, I tend to remove them.

sudo rm /usr/local/bin/mtoc*

Ok. Removed. Now run Micky's script again. And I was still asked to install mtoc in /usr/local/bin although I'd installed it in ~/Doc*/Build_Clover/src/opt/local/bin/mtoc.NEW.

boot6
                          <----------------------------------------------------
TOOLCHAIN_DIR: /Users/vanilla/Documents/Build_Clover/src/opt/local
Installing mtoc
Password:

After typing the pwd/installing mtoc. Oops. They are still installed in /usr/local/bin...

Vanillas-MacBook:~ vanilla$ ls /usr/local/bin | grep mtoc
mtoc
mtoc.NEW

Any idea?  :)

 

=================

 

[uPDATE]

Ok. It's related to ebuild.sh.

# Check Xcode toolchain
checkXcode () {
    XCODE_BUILD="/usr/bin/xcodebuild"
    local LOCALBIN="/usr/local/bin"
    local CLOVERBIN="${CLOVERROOT}/BuildTools/usr/local/bin"
    if [[ ! -x "${XCODE_BUILD}" ]]; then
        echo "ERROR: Install Xcode Tools from Apple before using this script." >&2
        exit 1
    elif [[ -f "${CLOVERBIN}/mtoc.NEW.zip" ]]; then
        unzip -qo "${CLOVERBIN}/mtoc.NEW.zip" -d "${CLOVERBIN}"
        [[ ! -d "${LOCALBIN}" ]] && sudo mkdir -p "${LOCALBIN}"
        if [[ ! -x "${LOCALBIN}/mtoc" ]]; then
            echo "Installing mtoc"
            sudo ln -s "${CLOVERBIN}/mtoc.NEW" "${LOCALBIN}/mtoc"
        fi
        if [[ ! -x "${LOCALBIN}/mtoc.NEW" ]]; then
            echo "Installing mtoc.NEW"
            sudo ln -s "${CLOVERBIN}/mtoc.NEW" "${LOCALBIN}/mtoc.NEW"
        fi
        sudo -k
    fi
}

The question. Why we need to add a soft link on this...

Edited by PMheart
Philip Petev
Philip Petev
Posted
Posted

Unless there are some manual operations that require calling the mtoc binary directly by using its name, there's no practical point of symlinking that binary to /usr/local/bin. Wherever that binary could be, its path can be specified and used as a script variable and that binary has no practical usage for most users (besides those who compile Clover) . Just my opinion, the question is for Slice to answer to.

  • Like 1
PMheart
PMheart
Posted
Posted

Unless there are some manual operations that require calling the mtoc binary directly by using its name, there's no practical point of symlinking that binary to /usr/local/bin. Wherever that binary could be, its path can be specified and used as a script variable. Just my opinion, the question is for Slice to answer to.

I think in this case we can use a variable instead... And sorry. It's somehow late. Time to sleep. :)

 

 

Sent from my iPhone 7 using Tapatalk

Zenith432
Zenith432
Posted
Posted

mtoc is hardcoded in tools_def to come from /usr/local/bin

Clover/Patches_for_EDK2/Conf/tools_def.txt:*_XCODE32_*_MTOC_PATH        = /usr/local/bin/mtoc
Clover/Patches_for_EDK2/Conf/tools_def.txt:      *_*_*_MTOC_PATH  = /usr/local/bin/mtoc.NEW
BaseTools/Conf/tools_def.template:*_XCODE32_*_MTOC_PATH        = /usr/local/bin/mtoc
BaseTools/Conf/tools_def.template:      *_*_*_MTOC_PATH  = /usr/local/bin/mtoc

I see now that there is some code in ebuild.sh to copy the binary in Clover tree mtoc.NEW.zip to /usr/local/bin. buildmtoc.sh is old and I just now checked it in. When I wrote it I didn't want to use sudo in it because sudo needs user interaction, so it places the product in $TOOLCHAIN_DIR/bin.

PMheart
PMheart
Posted
Posted

mtoc is hardcoded in tools_def to come from /usr/local/bin

Clover/Patches_for_EDK2/Conf/tools_def.txt:*_XCODE32_*_MTOC_PATH        = /usr/local/bin/mtoc
Clover/Patches_for_EDK2/Conf/tools_def.txt:      *_*_*_MTOC_PATH  = /usr/local/bin/mtoc.NEW
BaseTools/Conf/tools_def.template:*_XCODE32_*_MTOC_PATH        = /usr/local/bin/mtoc
BaseTools/Conf/tools_def.template:      *_*_*_MTOC_PATH  = /usr/local/bin/mtoc
I see now that there is some code in ebuild.sh to copy the binary in Clover tree mtoc.NEW.zip to /usr/local/bin. buildmtoc.sh is old and I just now checked it in. When I wrote it I didn't want to use sudo in it because sudo needs user interaction, so it places the product in $TOOLCHAIN_DIR/bin.
Wah lau. And why ebuild.sh wants to create a link in /usr/local/bin? And tested, after simply commented out those related lines, ebuild.sh exits...

 

 

Sent from my iPhone 7 using Tapatalk

tluck
tluck
Posted
Posted

@Slice:

What is the use of Shell64.efi?  Seems like Clover always uses Shell64U.efi for 64-bit shell.

 

i don't know the actual difference (and I look forward to perhaps an explanation)

 

but here is my use (and observation):

on my 2011 Lenovo T420 - only Shell64.efi works.

where as on my 2016 Lenovo T460 - only Shell64U.efi works.

 

I have post-install script to remove one or the other. 

Sherlocks
Sherlocks
Posted
Posted

@tluck

 

i tested your rc script. it seems no failure case.

i hope add remove nvram file in root if we have ESP. The code you added before did not work(maybe old rc script version when i request it).

You can temporarily put the nvram file in the root and test whether the nvram file is deleted from the rc script.

 

I will be constantly tested after it is reflected in official clover version and I will report later on whether there are any problems.

 

thanks in advance

Slice
Slice
Posted
Posted

What are the implications? Would I still be able to boot macOS from my BIOS based motherboard (z68x-ud5-b3)?

It introduced ab ovo in refit to boot WindowsXP on old real Macs with special bootcamp drivers specific for those models.

It can't be used on Hackintoshes.

By dropping "Shellx64.efi" into my esp, I can launch efi shell from asus setup

Just rename one or another Shell version to this name.

  • Like 3
tluck
tluck
Posted
Posted

@tluck

 

i tested your rc script. it seems no failure case.

i hope add remove nvram file in root if we have ESP. The code you added before did not work(maybe old rc script version when i request it).

You can temporarily put the nvram file in the root and test whether the nvram file is deleted from the rc script.

 

I will be constantly tested after it is reflected in official clover version and I will report later on whether there are any problems.

 

thanks in advance

 

@sherlocks

- glad to hear the nvram save script as LogoutHook method is working for you.

- The current script does not have a remove /nvram.plist feature.

- The current script will only write /nvram.plist when an ESP is not located on the HDs (either not present or not mountable for some reason)

 

- so I think you are asking for a new feature in the script to check and remove  /nvram.plist if an ESP is present. OK.

 

- As far as "official clover"... it is left to the "Clover Dev Team" to decide how to (re) implement this method.

  • Like 1
Sherlocks
Sherlocks
Posted
Posted

@sherlocks

- glad to hear the nvram save script as LogoutHook method is working for you.

- The current script does not have a remove /nvram.plist feature.

- The current script will only write /nvram.plist when an ESP is not located on the HDs (either not present or not mountable for some reason)

 

- so I think you are asking for a new feature in the script to check and remove  /nvram.plist if an ESP is present. OK.

 

- As far as "official clover"... it is left to the "Clover Dev Team" to decide how to (re) implement this method.

 

 

q. so I think you are asking for a new feature in the script to check and remove  /nvram.plist if an ESP is present. OK.

a. right. because we got no more failure case.

 

i will wait your new script. 

thanks

Dajjal
Dajjal
Posted
Posted

After trying r4035 .metadata_never_index keeps getting created in the root of my system drive causing spotlight to be, well broken to a certain degree.Running mdutil -E  via terminal results in Indexing and searching disabled. Going back to 4012 resolves it, can someone shed some light as to why that file is created?Also a little bit off but i've noticed that 2 nvram.plist gets created, one on my EFI and one on my root.I tried checking the pref of clover to Never save nvram to disk but it still gets created...

tluck
tluck
Posted
Posted

@Dajjal,

 

the current nvram save method has some design flaws and/or execution issues  - meaning it can behave (fail) in ways you have described.  Specifically, running the 80.save_nvram_plist.fixed script via CloverDaemon during shutdown is not reliable. The LogoutHook method seems to work better in this situation.

 

remove /.metadata_never_index

install the attached zip via the patch_nvram_save_scripts.command

 

@Sherlocks

this script version has a check for /nvram.plist and will remove the file if there is an ESP.

  • Like 1
Dajjal
Dajjal
Posted
Posted

Tried it but the nvram.plist is still at the root.Below is the terminal output.I have selected rc scripts via the installer so not sure why terminal says no file etc.....

cp: root/etc/rc.clover.lib: No such file or directory
cp: root/Library/LaunchDaemons/com.projectosx.clover.daemon.plist: No such file or directory
logout
Sherlocks
Sherlocks
Posted
Posted

@Dajjal,

 

the current nvram save method has some design flaws and/or execution issues  - meaning it can behave (fail) in ways you have described.  Specifically, running the 80.save_nvram_plist.fixed script via CloverDaemon during shutdown is not reliable. The LogoutHook method seems to work better in this situation.

 

remove /.metadata_never_index

install the attached zip via the patch_nvram_save_scripts.command

 

@Sherlocks

this script version has a check for /nvram.plist and will remove the file if there is an ESP.

 

checked. it works

 

thanks

  • Like 1
Dajjal
Dajjal
Posted
Posted

@tluck

 

Followed your instructions, it installs ok but .metadata_never_index keeps coming back.I noticed that it's also on the ESP as well.Further more a file called LibraryLaunchDaemons get created after running the terminal commands in the root of my HD and it's not hidden.....Bless

 Share
Go to topic listing
×
×
  • Create New...