Contribute
Register

EFIClone - automatic backup of the EFI partition

Joined
Jun 25, 2011
Messages
38
Motherboard
Gigabyte GA-Z68MX-UD2H
CPU
i5-2500K
Graphics
HD 3000
Mac
  1. MacBook Pro
  2. Mac mini
Classic Mac
  1. LC
  2. PowerBook
  3. Quadra
  4. SE
Mobile Phone
  1. iOS
I'm glad to present the first version of EFIClone - a shell script that, when combined with either Carbon Copy Cloner or SuperDuper!, will allow fully automatic, one-step backups of bootable Hackintosh hard drives. CCC and SD! only copy the visible macOS partition - and leave the EFI partition where the boot loader and customizations untouched.

Fortunately, both products allow the user to set a shell script to run on the completion of the main copy job. That's where this script comes it. Taking input from the backup programs, this script will automatically mount the hidden EFI partitions, copy all data from the source EFI partition to the destination, and then verify that the copy succeeded.

Once the CCC or SD! job with EFIClone completes, you can immediately boot from that new hard drive without having to re-run any CloverConfig, MultiBeast or KExtBeast installations.

Update... I have added a secondary script that can be installed to automatically make a backup archive of good EFI partition contents for you at each successful boot.

The script is included in the beta4 zip file and instructions for installation and use are in post #19 here.


https://www.tonymacx86.com/threads/...-the-efi-partition.246540/page-2#post-1703662



There are a few requirements in order to run this script.

1. Either CCC or SuperDuper!. CCC allows the trial version to run post-copy scripts, so you can use that if you want. (Though I think CCC is definitely worth the price and recommend that you get a license). SuperDuper!, unfortunately, requires that the program be licensed in order to unlock the ability to run a post-install script, but the script has been designed to work with SuperDuper! as well.

2. A hackintosh running macOS 10.9 or later. (Technically, it can run on a real Mac - it just isn't necessary to make a bootable hard drive on a real mac.

3. Because this requires an EFI partition to copy the data to, this does mean that the destination drive where you are copying your boot drive to be a GPT formatted macOS native partition. It should support EFI partitions on drives with both physical partitions and virtual disk partitions. (Both coreStorage and APFS volumes are supported).

4. A little bit of willingness to tinker. Because this is dealing with low-level stuff, I have made the default mode of what I have distributed "passive". In the initial test mode, the script will run and will log what it WOULD do, but it will not actually modify any data. In order to actually get the script to do its thing, you need to edit the script and change the value of one config variable. For now at least, I don't plan to change this default behavior as I want the script to get a lot more use and testing before I am comfortable letting it rip in the wild.

Below are detailed instructions on how to install/configure the script and attach it to either CCC or SD!.

I have set up a GitHub project to track issues and enhancements. If you try it out and want to get assistance or have an enhancement you'd like to see, please consider posting an issue there.

Here is the link to the project on GitHub

https://github.com/wombat94/EFIClone

By all means, please post your experiences here on this thread. I will monitor and help out as best i can.

The latest version of the script will be attached to this first post and will always be available on GitHub as well.

If all of this is TL;DR... here's the shorthand:

1. The script as shipped will not actually modify anything. In order to get it to copy your data on the EFI partition, you MUST edit the script and turn off TEST_MODE. Instructions are in the script.
2. This is release under GPL license. Feel free to use, share, incorporate anything I have here, but please keep the license, copyright and attribution
3. This is release with NO WARRANTY. I would not post it publicly if I didn't think that it was pretty safe, but this is definitely beta software and to do it's thing it has to delete and copy data - this is NEVER risk free. Please be sure to have a safe copy of your data before running this script. I hate to say it this way, because I believe in the value here, but USE THIS AT YOUR OWN RISK.

With that said... the detailed instructions are below and the .zip file attachment has the goods.

I'm glad to be able to share something back to the community. I hope you find it useful.

Wombat94

(please note... I ran out of time this evening tracking down a bug in my validation routine, so I do not have screenshots in the instructions below. Hopefully you can figure it out, but I do plan to come back and enhance this first post in the next few days)



EFIClone
EFIClone.sh is a macOS bash shell script for Hackintosh machines that is designed to integrate with either Carbon Copy Cloner or SuperDuper! - the two most popular macOS disk cloning utilities.

CCC and SD! both will automatically create bootable clones on real Macintoshes in a single step. Though modern Macs support the EFI booting in order to maintain compatibility with running non-Apple operating system on their hardware, they do NOT need the EFI partition in order to boot MacOS. Because of this, the disk clone utilities do not copy the contents of the secondary EFI partition from one drive to another when doing their job.

This is where EFIClone comes in.

Both CCC and SD! have the ability to configure a "post flight" script that will be launched when the main clone job has been completed.

Both programs pass details of the source and destination drives that were used in the clone job, and from this the script is able to find the associated EFI partitions and automatically copy the contents of the critical EFI folder from the source drive to the destination drive as well.

The script provides extensive logging, has a "test" mode that will log what it WOULD have done but will not modify any data, and sends a notification to the macOS notification center with the results of the run.

When configured in your CCC or SD! clone job, EFIClone will allow you to do a single-step clone from your current hackintosh drive to a truly bootable backup drive with no other steps required.

SCRIPT CONFIGURATION

There are currently only two user confiruation settings.

Since this is a script file, they have to be manually edited with a text editor.

The most important setting is the TEST_SWITCH.

TEST_SWITCH="Y" (Default on a new install is "Y")

  • a value of "Y" tells the script to only test it's run - no modification of data will happen
  • a value other than "Y" allows the script to run in normal mode - it will delete the contents of the destination EFI partition and replace them with the contents of the source EFI partition.
This setting tells the script whether to run in Test Mode. In Test Mode all parsing of the script input will take place, the EFI partitions will be mounted, the data on the source and destination partitions will be verified and all activity will be logged, but NO DATA WILL BE MODIFIED. This is a safety measure. Please run the script with TEST_SWITCH="Y" at least once and review the log file to see the results before attemtping to let the script modify anything. I use this script for myself and have no problems with it but is is brand new (beta) and it WILL delete the contents of what it believe is the EFI partiton on the destination drive. It is possible that something could be screwed up and I don't want to delete the wrong data. Regardless of what the test shows, I have to add this disclaimer: I AM NOT RESPONSIBLE FOR DATA LOSS ON YOUR SYSTEM. PLEASE ENSURE YOU HAVE A WORKING BACKUP BEFORE YOU ATTEMPT TO USE THIS SCRIPT. I HAVE DONE EVERYTHING I CAN TO PREVENT DATA LOSS, BUT THERE MAY BE BUGS IN THIS CODE. I PROVIDE NO WARRANTY ON THE SOFTWARE. USE AT YOUR OWN RISK.

The only other setting is the path where the log file will be written out.

LOG_FILE="$PWD/EFIClone.log" (Default is the path to the working directory and a file named EFIClone.log)

There is no absolute need to change this setting, but if you want to force the log to be written elsewhere, you can put the full path in this setting.

From what I can tell, both Carbon Copy Cloner and SuperDuper! run the script with a woking directory of the root of the boot drive "/". That is where it writes the log on my system every time. If you can't find the log, just search for it in SpotLight.

INSTALLATION
There really is nothing to "install". This is a simple shell script that relies ONLY on native macOS command line utilities to perform all of its functions.

Download the file and place it anywhere on your system that is accessible.

CLONE UTILITY CONFIGURATION
The configuration of both utilities is similar, but not exact. See the following sections for each.

Carbon Copy Cloner

  1. Create a Clone task as you normally would, defining the Source and Destination partitions.
  2. Click on the Advance Settings button, just below the Source partition.
  3. The advanced settings pane will open. If necessary scroll down until you can see the section labeled "AFTER COPYING FILES" and click on the folder icon next to "Run a Shell Script:"
  4. Use the file dialog to select EFIClone.sh from the folder where you placed it after downloading.
  5. After you have selected it, your task should look like this - with the script name "EFIClone.sh" showing next to the "Run a Shell Script:" line. If you want to you can click on the "eye" icon to see a read-only version of the script. If you need to change the script (or remove it completely) you can click on the "X" icon to deatch the script from your CCC Task.
SuperDuper!

  1. Choose your Source and Destination partitions in the "Copy" and " to " drop down menus.
  2. Click on the "Options..." button
  3. This will display the "General" options tab. Click on "Advanced" to show the Advanced options.
  4. Check the box that says "Run shell script after copy completes" and click on "Choose..."
  5. Use the file dialog to select EFIClone.sh from the folder where you placed it after downloading.
  6. After you have selected it, the dialog should show the path to the script.
Please report any bugs. Feel free to open issues for enhancements you would like to see.
 

Attachments

  • EFIClone0.1beta4.zip
    16.1 KB · Views: 933
Last edited:
This post will contain release notes on the script as it changes over time...

#Release Notes
#
# version 0.1beta3
# 2/24/2018
# - Updated to use rsync to handle the deletion of information from the desination drive. Basically,
# allow rsync to do its thing
# - Added additional check, based on clover boot log retrieved with bdmesg, to ensure that the
# destination EFI partition is NOT the EFI partition that was used to boot the computer.
#
# version 0.1beta2
# 2/23/2018
# Clean up and combine.
# -Combined the two versions of the script into a single script that detects whether it was called from
# Carbon Copy Cloner or SuperDuper! and behaves accordingly in the setup.
# -Added validation of the copied data through SHASUM hashing of all visible files in the source and
# destination EFI partitions after the delete/rsync copy is complete
# -Changed the method of copying files from cp to rsync
# -Modified the copy path of the source to include the root directory - not just the /EFI/ directory
# and subdirectories.
#----------------------------------------------------------------------------------------------------------
# version 0.1beta1
# 2/22/2018
# Initial Release
#----------------------------------------------------------------------------------------------------------
 
Last edited:
This post will contain a list of upcoming enhancements planned for the script...

- Add configuration options that would allow the destination to be a user-defined folder on the destination data partition. This could be in addition to the EFI partition copy or instead of the EFI partition copy. The destination could be either a folder or a zip archive. This option will allow the archiving of the EFI partition configuration over time for rollback or recovery purposes. (added 1/24/2018)

- Make the script able to be run manually. Allow the script to be executed on an ad-hoc basis. This along with the above change would allow for quick backups of the EFI partition before and after changes are made to keep a history of the changes without having to run CCC or SD! (added 1/24/2018)
 
Last edited:
For reference, here is the content of the original post from the HP 6300/8300 pro where the idea came to me and some background research that I did...

I've been trying to understand why CCC does not copy the EFI partition and I believe that I finally do understand it.

I'm fairly certain that real Macintoshes do not use the EFI partition to boot the computer. The partition is only used in two cases on a Mac from what I can tell... the EFI partition is definitely used as a staging area to update the EFI firmware of the computer. I have two MacBook Pros and they both have firmware update files in /EFI/APPLE/FIRMWARE and /EFI/APPLE/EXTENSIONS

But in the EFI spec, the EFI firmware will look for the bootloader in /EFI/BOOT/bootx64.efi

On my work MacBook (which does not have a bootcamp installation) there is not even an /efi/boot/ folder - much less a bootx64.efi file inside.

On my personal MacBook (which DOES have a windows 10 bootcamp installation) there is a /efi/boot/ folder and the bootx64.efi file is an exact copy of the same file from the /MICROSOFT/ folder in the EFI partition. This matches my understanding of how it should work.

On my hackintosh, the /EFI/BOOT/CLOVERX64.efi file is a copy of /EFI/CLOVER/CLOVERX64.efi - this again makes sense since Clover is the bootloader that will control loading the OS.

So given this info, I think that what is going on is that Apple is basing their bootloader architecture on EFI (or more correctly UEFI) but since they live in the closed-hardware walled garden world of only having to run on their hardware with known configurations, instead of having their EFI firmware always look at /EFI/BOOT, they default to look at /<bootvolume>/System/Library/CoreServices/boot.efi

Given how bootcamp works, I would guess that they have an extension that allows you to update some static parameter value somewhere to either look for boot.efi or allows it to fallback to the UEFI standard of /EFT/boot/bootx64.efi, and further, holding down the Option key on a real mac will then scan for either /EFI/boot/bootx64.efi on attached drives or /System/Library/CoreServices/boot.efi on attached devices to allow you to choose where to boot.

Given all of that, it now makes sense to me that CCC doesn't copy the EFI partition... I don't believe it supports copying a BootCamp partition in CCC and that is the only reason you would ever want to copy the EFI partition on a real mac.

Know that all of the above is purely speculation from me, but it seems to fit the evidence at hand and it makes sense.

From what I've read (though I haven't tested this) it should be unnecessary to actually "install" Clover to the EFI partition if you already have a correctly configured Clover installation (as you would on your current volume that you are backing up)... CCC allows a shell script to be run after the clone completes. It should be possible to create a script that would be able to mount the source disk's EFI partition and the destination disk's EFI partition and copy all the contents over.

I'm going to take a look for my own benefit. If I can find some reliable way of identifying the source volume and destination volume that are used, I might be willing to share, but this could be a very dangerous script if applied incorrectly.

[edited to add]
... CCC passes in the source and destination volume identifiers as parameters to the pre- and post- clone scripts, so this should be a pretty safe process - if you agree to let CCC do its thing to those volumes then I can be comfortable that it is okay to handle the copy of date on the EFI partitions associated with those volumes. I will definitely play with this tonight.
 
Hmm... just a thought I had here. Would anyone be interested in a version/enhancement of this script that could be scheduled to run automatically to just make a versioned backup of the EFI partition on the boot drive to some location?

The thought that I have is that time I most need my backups on my hacks is when I have been tinkering and trying something out and have an "uh oh" moment. What I need then is the EFI partition as it was before the oops... only I don't always follow best practices and do a backup before I tinker with something.

The idea I have is to have a version that would run every x minutes - would check to see if the contents of the EFI boot partition have changed since the last time it ran, and if so, would create a new backup in a designated location - with a date/time stamp so they can be kept historically.

If you screw something up, as long as you have an emergency boot thumb drive somewhere, you can revert easily to a particular point-in-time in the past. Sort of like a windows system restore, but only for the EFI partition.

I recognize that you could screw something up un /L/E or /S/L/E, but I'm not ready to go there. Changing things in Clover/EFI is what most often screws me up.

Anyone care to comment?
 
Hmm... just a thought I had here. Would anyone be interested in a version/enhancement of this script that could be scheduled to run automatically to just make a versioned backup of the EFI partition on the boot drive to some location?

The thought that I have is that time I most need my backups on my hacks is when I have been tinkering and trying something out and have an "uh oh" moment. What I need then is the EFI partition as it was before the oops... only I don't always follow best practices and do a backup before I tinker with something.

The idea I have is to have a version that would run every x minutes - would check to see if the contents of the EFI boot partition have changed since the last time it ran, and if so, would create a new backup in a designated location - with a date/time stamp so they can be kept historically.

If you screw something up, as long as you have an emergency boot thumb drive somewhere, you can revert easily to a particular point-in-time in the past. Sort of like a windows system restore, but only for the EFI partition.

I recognize that you could screw something up un /L/E or /S/L/E, but I'm not ready to go there. Changing things in Clover/EFI is what most often screws me up.

Anyone care to comment?
Maybe something like this with -n --dry-run
Code:
rsync -arn SOURCE DESTINATION
should print out something like 'Copied ...bytes' without actually doing the copy

If you have bytes copied, compress your current version of DESTINATION to a time-stamped archive, then do an incremental backup for real.
 
Maybe something like this with -n --dry-run
Code:
rsync -arn SOURCE DESTINATION
should print out something like 'Copied ...bytes' without actually doing the copy

If you have bytes copied, compress your current version of DESTINATION to a time-stamped archive, then do an incremental backup for real.

That is a very good call. I was already planning to use dry-run to enhance my "test mode" of the script to print out the details of what the script would have copied to the log. I can use it interactively with the EFI backup idea to determine if I need to copy anything very easily.

Thanks for the pointer!
 
That is a very good call. I was already planning to use dry-run to enhance my "test mode" of the script to print out the details of what the script would have copied to the log. I can use it interactively with the EFI backup idea to determine if I need to copy anything very easily.

Thanks for the pointer!
Another way: compress the EFI folder and checksum it, then compare it to your last backup. If they differ keep the new one.
 
Back
Top