boot.efi developer's thread

Discussion in 'Mac Programming' started by mikeboss, Oct 2, 2015.

  1. rthpjm, Nov 25, 2015
    Last edited: Nov 30, 2015

    rthpjm macrumors 6502

    rthpjm

    Joined:
    Jan 31, 2011
    Location:
    U.K.
    #876
    Hello Pike,

    It's great to have you back. I am so pleased to hear that you are on the mend. I'm sure you are more pleased (and mightily relieved too)! Don't push yourself too hard, take the time to recuperate... Don't vegetate though, keeping the brain active is important too :)

    I decided to see if I could prove a memory leak. My first test may show that there is an apparent leak. I built an installer, booted from it, before starting the installer I opened a terminal from the Utilities and created a launchd plist. The plist called vm_stat every 5 seconds. Once I confirmed it was running I quit the terminal and ran the installer.
    My MacPro was at full configuration with it's 32GB RAM, so the install completed cleanly.

    I have briefly examined the vm_stat output and can see definite trends up and down. There's a distinct period where free memory is continually dropping, then free memory springs back up. Which I assume is once the decompression completes near the end of the Installer progress. (For anyone interested, I've attached the vm_stat file)...

    A picture paints a thousand words:
    Screen Shot 2015-11-25 at 15.27.36.png

    vm_stat reports free pages, a page is 4KB. I found the lowest free figure and crunched the numbers:
    5159861 free pages
    4096 * 5159861 = 21134790656 bytes ~= 19.7 GB free

    I have 32MB installed
    32 - 19.7 ~= 12.3 GB used

    Whilst not conclusive it does sort of tally with the tests observations by Inspector42.

    When I was doing this test, I did notice that the log file was recording font errors at approximately the same frequency as the 'tick' of the progress bar. I'll focus my next tests to see if I can pin down the culprit. I'm starting to suspect it's the Language Chooser, which acts as the progress manager, I think it may be this process that is throwing the font errors. If the code, which is likely to be in a loop is allocating memory for fonts (but then not releasing) it might be a possible explanation. Admittedly this just guess-work at the moment.

    ============================ EDIT ============================

    So I have now fixed the font "issue". The only effect this had was to remove the log file entries. The good news is that the log file is MUCH easier to read now. The bad news is that it had no effect on the memory profile.

    Screen Shot 2015-11-30 at 11.09.29.png

    I have updated post #807 with the Version 2 of the createpikeinstallmedia tool

    I have also run the installer-with-fonts using 8GB of RAM. It still fails. The graph is interesting, it shows the install stopping short...

    Screen Shot 2015-11-30 at 20.12.00.png

    I'm going to try to identify which process is consuming the RAM, but I have a sneaking feeling that it may be intentional because of this log file line
    Code:
    Mac-Pro OSInstaller[485]: Activated virtual memory backing store at mount point '/Volumes/El Capitan'
     

    Attached Files:

  2. javirnat macrumors newbie

    javirnat

    Joined:
    Jun 14, 2015
    Location:
    Valldemossa (Baleares Spain)
    #877
    ---------------------------------------------------------------------
    I´m very happy to know that you are back with us. Take care and welcome . We wish the best for you .
     
  3. Inspector42 macrumors newbie

    Inspector42

    Joined:
    Nov 8, 2015
    Location:
    Germany
    #878
    Hi Pike, welcome back. I am truely relieved by your recovery.
    As Peter suggested, please take it slowly although I can understand your eagerness to get engaged again
     
  4. Morpheo macrumors 65816

    Morpheo

    Joined:
    Feb 26, 2014
    Location:
    Paris/Montreal
    #879
    So great to have you back Pike. Don't spend too much time in front of this damn computer now... take care m8 :)
     
  5. Pike R. Alpha macrumors 6502

    Pike R. Alpha

    Joined:
    Oct 4, 2015
    Location:
    Spain
    #880
    Thanks. No worries. Will only be here for five minutes or so. Need time to recover, but I am still here ;)
     
  6. RaimisFr macrumors newbie

    Joined:
    Dec 2, 2015
    #881
    Hello,
    I have an external drive named USB. After this "./createpikeinstallmedia /Volumes/USB I get the next message: "
    /Users/xxx/Desktop/piki/createpikeinstallmedia /Volumes/USB
    Cannot find copy of Pike's boot.fi
    Place a copy of Pike's boot.efi into the same folder as this script"
    Where is the problem?
    Thanx
     
  7. rthpjm macrumors 6502

    rthpjm

    Joined:
    Jan 31, 2011
    Location:
    U.K.
    #882
    Hello RaimisFr

    Well that is odd. I presume you successfully unzipped the file, and that you haven't moved any of the files?
    You should have a pikify3.1 folder with the following contents:

    Code:
    OSInstall.collection
    boot.efi
    boot_black_3_1.efi
    boot_grey_3_1.efi
    bootbase.efi
    createpikeinstallmedia
    missing-fonts.tgz
    pikify.pkg
    
    You may or may not see the missing-fonts.tgz - it depends which version of pikify.zip you downloaded.

    The error message you are getting tells me that boot.efi is missing. Whilst you are using the terminal, list the contents of the folder ls -1 (that's the number 1) and compare with the list above...
     
  8. rthpjm, Dec 4, 2015
    Last edited: Dec 9, 2015

    rthpjm macrumors 6502

    rthpjm

    Joined:
    Jan 31, 2011
    Location:
    U.K.
    #883
    I've moved this post to the original Mac Pro (1,1/2,1) and El Capitan thread.

    If you are looking for my Boot64 tools, you will find them updated at post #1391
     
  9. Inspector42 macrumors newbie

    Inspector42

    Joined:
    Nov 8, 2015
    Location:
    Germany
    #884
    Excellent work ! For the paranoid, one option to maintain comfort but reduce exposure, could be to limit access rights of changing boot.efi to the launch daemon. As I am not familiar with the details of sand boxing and SIP I started a search. While I haven't figured out how to do the above, I discovered this https://derflounder.wordpress.com/2...dding-another-layer-to-apples-security-model/.
    The author mentions that when talking to Apple engineers they stated that those files controlling SIP are "owned" by Apple and will be overwritten when modified. Hence we need to carefully watch, if that will happen with the pending 10.11.2 update. It may defeat this approach.
     
  10. rthpjm macrumors 6502

    rthpjm

    Joined:
    Jan 31, 2011
    Location:
    U.K.
    #885
    That is true. Under normal circumstances, all items under /System are considered to be exclusive to Apple (to do with as they please). That's why there is (user accessible) /Library that mirrors the layout of /System/Library. Normally, non-Apple files are placed in /Library, items here are persistent and not typically overwritten by Apple.

    Yes it's possible that Apple will continually overwrite the SIP paths file, but at the moment the technique will work because changes become resident after reboot. The current Apple update processes (App Store and DMG download) reboot after the installer has made its changes.

    The paths file is SIP protected, that's why step 1 requires us to boot from another partition. The Boot64 folder in /Library/Applications Support is a little more exposed. I'll have a look to see if I can bring that under SIP protection. From a security perspective we have to accept that we're making a conscious choice to allow access to the boot.efi file. We are a relatively small group of owners that are continuing on with our 32-bit machines, from a risk profile I'd say it is a low likelihood, low impact risk. The good news is that any malware that has an attack vector to overwrite the boot.efi file directly would simply be subject to the pikeyosfix or Boot64 replacement. If we can protect our files, the attack vector window closes further.

    When Pike is well enough, his approach of using a kernel extension may prove to be more secure...
     
  11. Inspector42, Dec 5, 2015
    Last edited: Dec 6, 2015

    Inspector42 macrumors newbie

    Inspector42

    Joined:
    Nov 8, 2015
    Location:
    Germany
    #886
    I fully support rthpjm's assessment. The limited number of El Capitan users with "old hardware" is not very attractive to attackers and a simple boot.efi replacement would be cured with the daemon before it can do any damage, I had overlooked that in my thoughts.
    Since one can always choose to not install the automated replacement, this is more of a personal preference issue.
    If Apple was really concerned about modified Sandbox/SIP they would have chosen to replace the files with 10.11.1 update already.

    EDIT:
    Just revisited how Pike´s yosefix is working as I had it installed on my SSD and wanted to finally put El Captan on it without wiping the disk. The spare boot.efi.pike is located at /usr/standalone/i386 and hence it is protected by SIP. I just replaced it with the El Capitan version sitting there anyway. The com.pike.yosefix.plist is placed in /Library/LaunchDaemons, the script code for replacement is embedded there. This is then the only file exposed somewhat.
     
  12. 666sheep macrumors 68040

    666sheep

    Joined:
    Dec 7, 2009
    Location:
    Poland
    #887
  13. nathanonlaptop macrumors newbie

    nathanonlaptop

    Joined:
    Apr 30, 2011
    Location:
    Jacksonville, AL USA
    #888
    Hey Guys, I'm new to this tread.
    I have a Mac Pro 1,1 , bios patched to 2,1.
    x2 2.66ghz Xeon X5355, 16 GB ram

    I've done the manual boot.fi patches to the install files in the past, but this time I'm using pikify 3.1v3 to automate the process. I'm having some trouble getting things to work. First try, install hung up at 14 min ~10% mark. Rebooted, second and third try, didn't get past install boot screen without a panic. See images below. What might be the culprit here? I just upgraded from 10GB to 16GB ram to be able to use this patch. IMG_3890.jpg
    IMG_3894.jpg
     
  14. rthpjm, Dec 9, 2015
    Last edited: Dec 9, 2015

    rthpjm macrumors 6502

    rthpjm

    Joined:
    Jan 31, 2011
    Location:
    U.K.
    #889
    Hello Nathan,

    Almost everyone that has reported similar KPs has found that their RAM was the cause. You say yours is new, so my best advice would be to power-off. Pull the RAM riser cards from the machine, work through each RAM stick and make sure your have fully pressed it home in its socket. Be firm. Then put the riser cards back into the machine, but don't put the side panel back on, leave it open. Power on the machine, look at the exposed parts of the RAM riser cards, are any of the LEDs illuminated? if so it's an indication of bad ram, or bad connection. If you do see lit LEDs, power off, pull the riser cards, eject your RAM sticks, maybe shuffle (in pairs) them a bit, then re-insert all your RAM. Re-insert the riser cards, power on, check for LEDs lit.

    If you still have LEDs lit, this time try to make a note of the LED position (there's usually two rows of two on 1,1 riser cards, each corresponding to a RAM slot). Repeat the pull, eject, shuffle re-seat, re-install, but this time try to be specific about where you put the stick that was marked by the LED (e.g. if it was slot 3 that was illuminated, during the shuffle put that stick back into slot 1). Power on, see if the LED follows the stick of RAM. If it does then you've found a potential culprit.

    If there are no lit LEDs, then perform a visual check and make sure you have matched pairs in the slots...

    Also, just to be clear, pikify3.1 is only intended to install new copies of El Capitan (onto a new/spare disk for example - if you are brave it should be okay to upgrade from Yosemite by this method too).

    I'm not sure what you mean by automate, but if you already have El Capitan installed and just want to automate the "putting back of the modifications when the Apple updates overwrite them", then you should be looking at CapitanPikeFix or my Boot64....
     
  15. nathanonlaptop macrumors newbie

    nathanonlaptop

    Joined:
    Apr 30, 2011
    Location:
    Jacksonville, AL USA
    #890
    Thanks for that advise! After re-pikifying my drive with 10.11.2, I am now back to the 13 minutes-then-hang issue. I tried re-seating all of my 2GB ram modules, rearranging them, checking lights, etc. to no success. I ran the install with 2GB of ram with the exact same hangs in the same spots as with 16GB, just took a bit longer. I have two drives in this mac, an SSD for OS boot, and a HDD for storage. Back last year when updating to Yosemite, I installed mountain lion on the storage drive just in case of catastrophic failure with my SSD. If I boot into mountain lion, I can see all 16GB registered in system profiler. I have another mac that is El Capitan friendly; is there a step-by-step guide to manually swapping the boot.efi files without having to run the pikified installer locally?

    Thanks in advance!
     
  16. rthpjm, Dec 10, 2015
    Last edited: Dec 11, 2015

    rthpjm macrumors 6502

    rthpjm

    Joined:
    Jan 31, 2011
    Location:
    U.K.
    #891
    There is a guide on page 32 of this thread (post #783) written by Peter Holbrook.

    Out of interest, take a look at the (incomplete) contents of your target drive. You should find the log file at /Volumes/[your drive]/var/log/install.log. If you still have the log file, compress it and post it, I'll take a look at it for you....
     
  17. nathanonlaptop macrumors newbie

    nathanonlaptop

    Joined:
    Apr 30, 2011
    Location:
    Jacksonville, AL USA
    #892
    Here you go. I was monitoring the log during the install, saving it to a flash disk periodically to make sure it was saved. Didn't know it was writing to the install disk. I noticed this chunk of the log seemed to be culprit

    Code:
    Dec 10 14:53:46 Mac-Pro OSInstaller[456]: OSIInstallElement <OSIInstallElement: 0x7fad8e839ff0> errored out:Error Domain=PKInstallErrorDomain Code=110 "An error occurred while extracting files from the package “Essentials.pkg”." UserInfo={NSUnderlyingError=0x7fad90961f00 {Error Domain=PKXARArchiveErrorDomain Code=101 "archive verify failed" UserInfo={NSURL=file:///System/Installation/Packages/Essentials.pkg#Payload, NSFileOwnerAccountID=0, NSFileHFSTypeCode=0, NSFileSystemFileNumber=350, NSFileExtensionHidden=false, NSFileSystemNumber=16777225, NSFileSize=5585759678, NSFileGroupOwnerAccountID=0, NSFileOwnerAccountName=root, NSFilePosixPermissions=420, NSFileHFSCreatorCode=0, NSFileCreationDate=2015-12-03 17:18:11 +0000, NSFileType=NSFileTypeRegular, NSFileGroupOwnerAccountName=wheel, NSFileReferenceCount=1, NSFileModificationDate=2015-12-03 17:20:27 +0000, NSLocalizedDescription=archive verify failed}}, NSFilePath=/Volumes/Macintosh HD/.OSInstallSandboxPath/Root, NSURL=Essentials.pkg -- file:///System/Installation/Packages/OSInstall.mpkg#Distribution, PKInstallPackageIdentifier=com.apple.pkg.Essentials, NSLocalizedDescription=An error occurred while extracting files from the package “Essentials.pkg”.}
    Dec 10 14:53:46 Mac-Pro OSInstaller[456]: ------- Install Failed -------
    Dec 10 14:53:46 Mac-Pro OSInstaller[456]: Operation: Install packages failed, Failure Reason: Error Domain=PKInstallErrorDomain Code=110 "An error occurred while extracting files from the package “Essentials.pkg”." UserInfo={NSUnderlyingError=0x7fad90961f00 {Error Domain=PKXARArchiveErrorDomain Code=101 "archive verify failed" UserInfo={NSURL=file:///System/Installation/Packages/Essentials.pkg#Payload, NSFileOwnerAccountID=0, NSFileHFSTypeCode=0, NSFileSystemFileNumber=350, NSFileExtensionHidden=false, NSFileSystemNumber=16777225, NSFileSize=5585759678, NSFileGroupOwnerAccountID=0, NSFileOwnerAccountName=root, NSFilePosixPermissions=420, NSFileHFSCreatorCode=0, NSFileCreationDate=2015-12-03 17:18:11 +0000, NSFileType=NSFileTypeRegular, NSFileGroupOwnerAccountName=wheel, NSFileReferenceCount=1, NSFileModificationDate=2015-12-03 17:20:27 +0000, NSLocalizedDescription=archive verify failed}}, NSFilePath=/Volumes/Macintosh HD/.OSInstallSandboxPath/Root, NSURL=Essentials.pkg -- file:///System/Installation/Packages/OSInstall.mpkg#Distribution, PKInstallPackageIdentifier=com.apple.pkg.Essentials, NSLocalizedDescription=An error occurred while extracting files from the package “Essentials.pkg”.}
     

    Attached Files:

  18. rthpjm, Dec 11, 2015
    Last edited: Dec 11, 2015

    rthpjm macrumors 6502

    rthpjm

    Joined:
    Jan 31, 2011
    Location:
    U.K.
    #893
    Hi Nathan,

    I have compared your log file to a successful one of mine. Everything looks the same up to around line 307, then your log file differs significantly from mine. It might have something to do with you saving your log file periodically.

    I have attached my log file so that you can compare. You will notice that your log file fills up with SFLList entries, opendirectoryd, and "Folder Manager" entries. If you ignore those entries (or use a text editor to remove them), our log files are similar until you get to the error message you show in the code box above.

    Looking more closely at the error message, the good news is that it is not the one I expected to see if it was a memory related issue - if it was the known memory issue, it usually fails during stream decoding (decompressing) of the Essentials.pkg. Your message says "verify failed".

    This leads me to think there are a number of possibilities:
    A drive issue, that has corrupted the Essentials.pkg file. Can you tell me what media you are using for the installer? Is it a USB memory stick, an internal drive/partition, an external drive, or something I haven't thought of?
    Have you run Disk Utility on the drives you are using? If not can you do so? (you might be best to boot from a different drive to perform a full check on the installer drive and the target drive).
    My best guess at the moment is that your installer drive is corrupted and/or failing. I would suggest that you try to reformat and rebuild the installer drive, then try again. If it still fails, use disk util to check both the installer drive and the target drive. Try again. If that fails, try to build an installer on different media, try again. If that fails, try to install on a different target drive.

    A final thought; Is your copy of 'Install OS X El Capitan.app' unmodified? If you have previously attempted to modify it then that could also be the cause of the failure to verify the Essentials.pkg. If you need to download a new copy of 'Install OS X El Capitan.app', you must first remove all copies of it from your system, otherwise the App Store will look like it starts to download and then immediately stops.
     

    Attached Files:

  19. rthpjm, Dec 11, 2015
    Last edited: Dec 11, 2015

    rthpjm macrumors 6502

    rthpjm

    Joined:
    Jan 31, 2011
    Location:
    U.K.
    #894
    Whilst checking out Nathan's issue above, I noticed that his installer was reporting the Base System as 10.11.2.

    I went to the App Store, re-downloaded OS X El Capitan (becomes /Applications/Install OS X El Capitan.app).

    Indeed the BaseSystem is 10.11.2, but so is the rest of the deployment. Installing with the latest copy gets you to 10.11.2 directly. And of course pikifying (createpikeinstallmedia) works. I wonder if it has done anything to the memory requirement?...

    ------ edit ------

    No it doesn't

    Screen Shot 2015-12-11 at 14.20.39.png
     
  20. dgwilson macrumors member

    dgwilson

    Joined:
    Feb 8, 2015
    Location:
    Wellington, New Zealand
    #895
    Thanks for the information about the latest El Capitan installer on the App Store being 10.11.2 - I'll do a clean download.

    Anyway... I wanted to report a couple of things.
    a. I have 2 x MacPro1,1 machines with 16GB of RAM - one of which I'm happy to play with.
    b. I have upgraded via the Appstore to 10.11.2 successfully. The upgrade involved letting the AppStore download/install do it's thing... and the reboot after install went to the alternate OS on the machine. I then replaced the boot.efi files on the El Capitan drive and rebooted (after checking the startup volume). At this point I have not updated the RecoveryHD. I'm just missing some manual instructions for that.


    Code:
    ... NOTE BELOW - Where I'm copying boot_pike.efi - you need this to be the same EFI that was used with pikify - or later as appropriate. 
    
    
    cd cd /Volumes/El\ Capitan/usr/standalone/i386/
    sudo cp boot_pike.efi boot.efi
    
    cd /Volumes/El\ Capitan/System/Library/CoreServices/
    sudo chflags nouchg boot.efi
    sudo cp boot_pike.efi boot.efi
    sudo chflags uchg boot.efi
    

    - David
     
  21. PeterHolbrook macrumors 6502a

    Joined:
    Sep 23, 2009
    #896
    Look for my complete installation guide, above (written weeks ago). It contains a thorough explanation of everything that needs to be done.
     
  22. dgwilson macrumors member

    dgwilson

    Joined:
    Feb 8, 2015
    Location:
    Wellington, New Zealand
    #897
    Excellent Peter. Thank you.

    I've got the instructions - they're in this post: http://forums.macrumors.com/threads/boot-efi-developers-thread.1924434/page-32#post-22213699

    I have encountered an issue when I try to change the flags on the boot.efi file.

    Code:
    sudo chflags nouchg boot.efi
    chflags: boot.efi: Operation not permitted
    
    According to the finder I can only "read" ... assuming that's my Admin user.
    And it appears that sudo does not have write permission either.


    I've missed something.

    - David
     
  23. rthpjm macrumors 6502

    rthpjm

    Joined:
    Jan 31, 2011
    Location:
    U.K.
    #898
    Hi David

    I have encountered a strange effect when I upgraded from 10.11.1 to 10.11.2. I have tested and confirmed that it is repeatable. Here is how I tested:

    I used my pikify3.1.v5 script to create an installer, based on the original 10.11.0 download.
    Installed 10.11.0 with no problems.
    Confirmed my mods to /S/L/Sandbox/Compatibility.bundle/Contents/Resources/paths were in place
    Installed my Boot64.v2 automated protector
    Upgraded to 10.11.1 using the Support download disk image for 10.11.1 successfully
    Reconfirmed my mods were in place
    Reconfirmed that Boot64 was able to replace/protect the boot.efi files
    Upgraded to 10.11.2 using the MAS.
    Reconfirmed my mods were in place
    However, I find that those mods to the paths file do not seem to be "active"
    /S/L/C/boot.efi is SIP protected as is the paths file.

    I've done some investigation, and I think that I have figured it out. There is some caching going on. There is a command (rootless-init) that appears to read the configuration files and most likely builds a binary cache for the kernel. I say "most likely" because there is no information available for rootless-init, and I haven't taken a close look at the binary yet.

    I have now tested the complete upgrade sequence as above with a new version of my Boot64 tool. This time it worked and I got to 10.11.2 with /S/L/C/boot.efi and the paths file exempt from SIP (/u/s/i/boot.efi was never a problem as far as I can see).

    BTW, chflags is a SIP protected operation. Even if the file is excluded from SIP, chflags is not permitted. You have to boot from another partition, or disable SIP from the Recovery HD, make the change, then re-enable SIP. (I prefer to boot from another partition, I'm lazy and it cuts out a couple of steps).

    I will upload Boot64.v3 to the main 2006/7 El Capitan thread today...

    I will assume you have performed my suggested modifications to the /S/L/Sandbox/.../paths file
    If you find yourself in this 10.11.2 situation try the following:
    Boot from the Recovery HD of your main boot drive
    Open a terminal
    Disable SIP (csrutil disable)
    Reboot back to your main OS partition
    SIP should be off, type
    Code:
    /usr/libexec/rootless-init
    You should not get any errors when running that command
    Reboot to your Recovery partition
    Open a terminal
    Enable SIP (csrutil enable)
    Reboot to your main OS partition
    Confirm the /S/L/C/boot.efi file is now replaceable
    Confirm /S/L/Sandbox/Compatibility.bundle/Contents/Resources/paths file is editable
     
  24. PeterHolbrook macrumors 6502a

    Joined:
    Sep 23, 2009
    #899
    If you read my guide with due attention, you'll notice that all such operations are supposed to be carried out using the Terminal on the INSTALLER partition, not the live El Capitan partition. If you run all the relevant commands from the installer, you'll be root by default, and you'll be able to bypass whatever SIP configuration you may have on your El Capitan partition(s). Please, note that changing SIP settings or using sudo is unnecessary. The Terminal of the installer has EVERYTHING you might deem necessary.
     
  25. rthpjm macrumors 6502

    rthpjm

    Joined:
    Jan 31, 2011
    Location:
    U.K.
    #900
    If you originally started with pikify3.1, then the recovery partition should already be modified (pikify does it for you :D).

    It is possible that the 10.11.2 Recovery HD update may have overwritten things.

    The simple change is posted at #1454 on the main thread.

    If you feel the need to change the BaseSystem.dmg as well...
    Assuming the recovery partition is mounted at /Volumes/Recovery HD
    Code:
    rsync -ah --progress /Volumes/Recovery\ HD/com.apple.recovery.boot/BaseSystem.dmg /tmp
    hdiutil attach -nobrowse -noverify -owners on -kernel /tmp/BaseSystem.dmg -shadow
    cp [pike-boot.efi] /Volumes/OS\ X\ Base\ System/System/Library/CoreServices/boot.efi
    cp [pike-boot.efi] /Volumes/OS\ X\ Base\ System/usr/standalone/i386/boot.efi
    cd /
    hdiutil detach /Volumes/OS\ X\ Base\ System/
    rm /Volumes/Recovery\ HD/com.apple.recovery.boot/BaseSystem.dmg
    hdiutil convert -format UDZO -imagekey zlib-level=9 /tmp/BaseSystem.dmg -shadow -o /Volumes/Recovery\ HD/com.apple.recovery.boot/BaseSystem.dmg
    rm /tmp/BaseSystem.dmg /tmp/BaseSystem.dmg.shadow
    The Recovery HD is not usually large enough to make the changes in-place, hence the copy to /tmp
     

Share This Page