Jump to content

Clover General discussion


ErmaC
29,866 posts in this topic

Recommended Posts

I can never get Snow Leopard to boot with Clover. Probably something I'm doing I'm sure but it has never worked for me.

See

Screen shot 2017-03-01 at 20.38.59.png

You may see Clover revision 0x0fb4 = 4020

  • Like 3
Link to comment
Share on other sites

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.

  • Like 2
Link to comment
Share on other sites

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
Link to comment
Share on other sites

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
Link to comment
Share on other sites

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
Link to comment
Share on other sites

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
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

@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

Link to comment
Share on other sites

@Slice:

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

Obsolete.

Some years ago there were one version for CloverEFi and other for UEFI.

Link to comment
Share on other sites

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
Link to comment
Share on other sites

@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
Link to comment
Share on other sites

@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

Link to comment
Share on other sites

×
×
  • Create New...