macOS 10.13.4 Causing Installation Log Failures
It’s unusual that I see something entirely new on my Mac. A few days ago, I got up early to get some writing done, but my 27-inch iMac’s Internet connection was being horribly slow, and the entire machine was struggling. Restarting my AirPort Extreme Base Station didn’t seem to help, so I restarted the Mac. Instead of booting normally, I ended up at a screen containing only an Installation Log window and an error dialog saying “The macOS installation couldn’t be completed.” That was confusing since I hadn’t asked the App Store app to install macOS 10.13.4.
However, clicking the Restart button just brought up the screen and error dialog again. I looked through the log and saved a copy, but none of the errors looked all that problematic.
With seemingly no other recourse, I clicked Restart one last time, held down Command-Option-R to boot into macOS Recovery, and reinstalled the operating system. (Did you know that different versions of Command-R cause different versions of macOS to be installed by macOS Recovery? Check out this Apple support article for the details.) Afterward, everything was fine, so I chalked it up to gremlins and started writing this article, but got sidetracked by work on our Internet infrastructure.
A few days later, however, my MacBook Air was performing badly, so I decided to restart it as well. I know for certain that it was running 10.13.3, and I explicitly did not ask for 10.13.4 to be installed — I just wanted a quick restart to clear up the performance problems.
Shockingly, when the MacBook Air rebooted, it showed the same Installation Log screen and error. The log looked similar, and restarting had no effect. Rather than reinstall macOS right away, though, I tried something new: I held down the Option key at startup and then selected my boot drive. That worked — the MacBook Air booted normally into macOS 10.13.3, and when I intentionally installed 10.13.4, the installation proceeded properly.
Surprising as it was to experience the same entirely new problem on both of my Macs in quick succession, I figured that I do things that most users don’t, like enable the root user to test security bugs (see “High Sierra Bug Provides Full Root Access,” 28 November 2017). But just a few hours later, my son Tristan called. This never happens — like many people of his generation, Tristan is categorically allergic to the telephone — but I hadn’t responded to a picture of his MacBook Pro that he’d sent me in Slack. When I looked, I couldn’t believe my eyes. It was the same Installation Log screen and error as I’d seen on both my Macs.
Luckily, the trick I’d employed to get my MacBook Air to boot worked well for him too — it’s always nice when we aged parents get to show off our technical prowess. Tristan also provided another data point that he had not tried to install 10.13.4 at all. In fact, his MacBook Pro had restarted only because he had plugged it back in after it had run out of power and shut down. He said that it had been running very slowly before that too.
So let’s recap. In three separate instances, a Mac that’s running macOS 10.13.3 starts running slowly. Upon restart — without the user asking to install 10.13.4 — the Mac boots into the Installation Log app and shows an error saying the macOS installation couldn’t be completed. Restarting doesn’t help, but the first thing to try is holding down Option as the Mac boots and selecting the primary drive. If that doesn’t work, boot into macOS Recovery and reinstall the operating system. No data will be lost either way, but hey, make sure you have backups anyway!
How common is this problem? Unclear, although there’s a discussion of it on AskDifferent that covers the same ground I did. If you’ve already upgraded to macOS 10.13.4, you’re probably safe. But if you’ve been holding off upgrading, which is usually the cautious thing to do, be aware that it’s possible you might encounter this situation on your next restart.
I have little idea of what could be going on under the hood. Perhaps it’s related to the “Download newly available updates in the background” checkbox in System Preferences > App Store, although that was set differently on my two Macs. It might not even be connected to macOS 10.13.4 — perhaps the “macOS installation” that’s failing is related to the “Install system data files and security updates” checkbox, which should always remain selected (see “Make Sure You’re Getting OS X Security Data,” 30 March 2016).
If you have any insight into this problem, let us know in the comments.
You’re not alone, although my experience was different. I bought a new MacBook Air which was sold by MicroCenter as coming with 10.12, but was running 10.13.1 (NOT .3) when I got it up and running. It did that happily for several days until a couple of days ago, when I left it plugged in to recharge and was stunned when I opened it to find it was booting up an upgrade and supposedly would need 13 minutes before it was finished. It didn’t wait that long, but it came up in 10.13.4. Perhaps because I haven’t installed much of anything onto it yet, I didn’t see any problems yet, but I definitely had not set it to auto-update. Really not good, Apple
I had this same problem on my iMac (2012) which has been acting oddly for a few months. I didn’t think too much of it an chalked it up as another mark against its aging issues.
I solved it by booting to recovery and running disk utility, which took awhile and fixed what appears to be some significant issues (something about the UUID not matching?) and since then its been fine.
A few months ago, my mother-in-law sent me an email asking if she should update the MBA we bought her for Christmas the year before to High Sierra. I advised her to hold off; I had a Reminder set every month to decide whether or not to tell her to go ahead and try it. Finally, last week, I said it should be ok.
Guess what happened?
Over the phone I also had her try to reinstall from Recovery, and was plotting when or even whether I should make the 45 minute drive to pick it up and see if I could fix it if that didn’t work. But, as it did with you, reinstalling from Recovery worked fine.
Did anyone experiencing the problem try the four-finger salute to reset NVRAM (hold command-option-P-R and wait for 2 or 3 additional startup chimes)? I’m pretty sure that some of these issues can be avoided by using the High Sierra 10.13.4 Combo Update, which can under most circumstances be applied to a qualifying target partition even while booted from another qualifying partition. There’s also a chance that a “mac os x install data” folder at the root level of the target partition could be errantly left behind during an installation and require certain some specific actions to get things working correctly again.
I think the Apple HT204904 article has some information about startup key combinations for reinstalling MacOS that are simplified to the extent of causing confusion. For example, if the installer finds what it considers a viable system on your target partition, it will not install anything older to that partition.
There have even been circumstances in the past where a supplemental security update could supersede the latest OS installer version and render the built-in system installer absolutely useless. In such a case, the only way to install was to hack the system version information on the target partition to make it appear to the installer to contain an older system version, or to perform a wipe and install (Archive and Install went away after 10.4 Tiger, if I remember correctly, but that’s good, because it was one of the most confusing and potentially destructive installation processes I’ve ever encountered).
Even if you’ve erased your target partition, you can’t install Sierra on an APFS volume. Also (correct me if I’m wrong), although you can nondestructively convert an HFS+ volume to APFS, you can’t nondestructively perform the action in a reverse manner, that is, convert an APFS volume to HFS+.
No, I didn’t think to try that because the log was showing failures that sounded like they were related to the disk in some way — files not existing or not being able to create the files.
And just to reiterate, in none of these cases was I trying to update — I was just restarting to solve performance problems. So if there was an actual installation of macOS 10.13.4 taking place, it was kicking itself off, rather than going on my command.
That’s what made me think of the “mac os x install data” folder, because I seem to remember some cases where that folder could be around for awhile and somehow be involved in startup problems later on. Anyway, I always try to reset NVRAM whenever a simple restart doesn’t work, because it’s pretty easy, and I’ve never (at least not when using recent system versions) had any significant complications arise from using it. It can be important to disconnect everything other than power and keyboard when performing it, however.
I’ve seen this too on other Mac installs… quite a few long nights with my client base.
Could be some overlap/bug like the one in create install media.
I"m just spitballing here, from insights gleaned in ‘other’ resources, to whit:
This installer path "\.I ABootFiles\boot.efi " was changed by Apple
// OS X installer paths
STATIC CHAR16 *OSXInstallerPaths[] = {
L"\Mac OS X Install Data\boot.efi",
L"\macOS Install Data\boot.efi",
L"\macOS Install Data\Locked Files\Boot Files\boot.efi",
L"\OS X Install Data\boot.efi",
L"\.IABootFiles\boot.efi",
L “\System\Library\CoreServices\boot.efi”
︎ new Path
};
Credit: Chris1111
Hello,
I have the same problem, I can access by pressing the option button at the beginning, but every time I turn it off and on, it gives the error being necessary to keep pressing the button every time I restart it.
Were you unable to resolve the issue permanently?
Thank you
Did you update to 10.13.4 after getting it to boot? That might fix things, assuming you don’t need to stay at 10.13.3 for other reasons (like the dual-display apps). I did update, and don’t seem to have any trouble at restart.
I’ve had to go into safe boot lately to do OS upgrades and Friday (the 13th) I decided to go for .4. As often happens something hangs and I reboot, but this time I ended up at the same screen you saw. I looked through the log and couldn’t see anything that seemed suspicious, but I’m pretty minor league on reading logs. I tried safe boot again but to no avail. Forgot about Cmd-R mode and spent $75 at the local computer store to find out about my ignorance. If I’d only waited a couple of days or had read my saved notes on recovery.
The other problem I ran into is that I booted my MBP 2013 off another drive and tried Disk Utility and it would only do a quick check (took only a few seconds to check the drive compared to the normal minute or two) which seemed odd. It was odd, it should have told me I can’t use DU from a hard drive on an SSD formatted with APFS. I’d probably read that “long” ago, but that became part of my $75 education.
When I quickly Googled for problems with 2013 vintage MBP I found out that cable failures to the drive were common, so I quit looking then figuring OK the drive is good and I just need a cable.
Everything seems OK now, the store did the .4 upgrade and since I took it in this morning and picked it up an hour ago I can’t say everything is fine. Only one startup.
You can add the DU misinformation to your list of Mac irritants.
I had a very similar experience (MacBookPro mid 2012) previous day I updated to 10.13.3 -long time user playing cautiously with updates. The update run fine, the machine appeared to be somewhat slow (lots of beach balls) but was serviceable.
Shut down and re started next morning & got a warning similar to AE’s though the graphic was different. Tried several of the “usual” things; safe boot, running Disk D. from a clone start up disk etc. On the second attempt to start up from a remote disk I got the “cannot complete the update again”. Spent an hour and a half with the Apple service folks who re set PRAMS and eventually re installed 10.13.4. Good service but very unusual problem. As far as I can tell, no data was compromised. Hope Apple comes clean with an explanation
I had a less traumatic update experience yesterday with my MBP 2014, without the Installation Log screen. I had been working and left the computer plugged in. When I returned a few minutes later the screen was black and unresponsive. After a few minutes wait, pressing keys and diddling I pressed the start button - and nothing happened, even after repeated attempts and holding it down.
Finally it did restart - several times, with different kinds of installation process bars showing different amounts of time that installation would take. After about 30-40 minutes the process completed and I could log in as usual. The OS 10.13.4 update was installed even though I never actively check auto install in preferences.
I had upgraded to High Sierra a few weeks ago and haven’t had any problems.
Hi Adam I didn’t experience your errors BUT when I upgraded to 10.13.4 last night I got a notification from the App Store that there is another update to 10.14.5! I can only assume that another update means that something isn’t working as well as Apple wants. As my iPhone 6S updated its OS without my asking it to (I always leave at least a week before updating). Thus the control of updating IS being wrested away from us users and firmly in the court of Apple’s patrician (I don’t include our distaff as I’m a gentleman:) propeller-heads; this is borne out by a news item (that I haven’t verified yet) that Apple is disabling iPhones which have had their screen repaired by a third party! They DON’T want us messing around with “their” shiny technology:((
Are you enrolled in the beta program? 10.13.5 went into beta right after the release of 10.13.4 (this is how these things pretty much always work).
Not sure about iOS, as I’ve never had an iOS device update without
I did have an iPad that was on iOS 10 for many months after 11 was released.
No, not in the beta program. Was very surprised at being forced updated, can’t remember it ever happening before.
This is one reason why I prefer to never do an “automatic” update of the Mac OS, even one “within” the same Mac OS. For OS 10.13.4, given that it had bene a while since OS 10.13.3 was released, and with 7 beta versions of OS 10.13.4, I did a clean, fresh installation of V10.13.4.
With V10.13.5 (now at its second beta), I will most likely download the Combo Updater, and do the update myself. Like the clean installation above, that gives me way more control over the upgrade process.
I would double check that, the only way to have macOS 10.13.5 is to be in the beta program. The latest release is 10.13.4, which came out March 30th.
Misunderstanding, I don’t have 10.13.5 installed. 10.13.4 was force installed over 10.13.3.
I found the solution here: macOS 10.13.3 Update FAIL · GitHub
Simply follow this:
Sorry for the bump but this happened to me again this week. I am running macOS 10.13.6 and noticed that Security Update 2018-003 had been downloaded. I did not run it at once. The next day after shutting down and trying to start up the installation log appeared just as it did for people postponing the 10.13.4 update. So whatever the underlying problem is, it continues.
Edited to clarify. Here are my App Store preferences:
My complaint is not that the security update tried to install automatically, because my preferences allow security updates to be installed; my complaint is that it failed with a very confusing notification.
Well it’s happening to me suddenly too, on my iMac Pro running 10.3.6. I had installed the Security Update 2018-003 10.13.6. I started experience periodic loss of power to my Drobo 5D drive only to have it start back up on its own in a minute or two. It may be an intermittent problem with the power brick and a replacement has been ordered.
However, after this, I noticed general sluggish behavior of the Mac and decided to restart. I got the aforementioned Log and message that the installation couldn’t be completed. I restarted 3 times and got the log all three times. Finally, like others, I opted to reinstall the system. Before doing so I did try to reset NVRAM and the SMC, and ran Disk First Aid, scanned with ClamXAV and Malwarebytes, and everything else I could think of. Reinstalling did work, but it has continued to happen. After another Drobo power failure/restart (hurry up FedEx!!) today and another reinstall I started looking for more info and found this discussion.
I don’t know much about reading the logs, but I did notice one section in it that read:
Dec 16 19:45:28 iMac-Pro ReportCrash[611]: Time Awake Since Boot: 66 seconds
Dec 16 19:45:28 iMac-Pro ReportCrash[611]:
Dec 16 19:45:28 iMac-Pro ReportCrash[611]: System Integrity Protection: disabled
I’ve never knowingly disabled SIP, and I verified it was Enabled by checking it in Terminal. Perhaps that happens on every boot? I wish I knew what else to look for in the logs, but most of it is meaningless to me. the whole ReportCrash[611] section is quite long and involved.
I’m going to make a note to try holding down Option at boot and try to choose the main startup volume again as suggested here.
Actually, that option only controls background security related updates (e.g. XProtect, MRT & Gatekeeper data). Security Updates that show up in the Mac App Store Software Updates have only been allowed to take place automatically once when Apple felt the need was dire.
Yes, you will need to do that in order to take any next step. Make sure to disconnect all peripherals except wired keyboard and mouse before attempting the update. If that fails, boot into Safe Mode and try there or download the standalone update and run that.
-Al-
That’s what I thought too, then this happened with the Security Update 2018-003 waiting on the App Store and it was forced as well, making me wonder. Anyhow, my main complaint is that the update failed. There is an underlying bug there in the type of installation that runs automatically on a restart or startup, and Apple should fix that. Especially since the situation can cause people to take all kinds of drastic actions, because it looks so scary to the non-expert user (first time it happened, back on 10.13.3, I did a bare metal OS install and then individually installed all my apps, data and settings from disk clone backups. Took half a week. Then Adam posted about it and I felt like an idiot.)
It happened to me again last week. When starting up the computer some kind of system update failed. I think it was 10.13.7. After retrying in vain a few times and getting the same message I went in to Disk Utility from the meny and chose my Startup Disk as a last resort and restarted. which actually seemed to stop the install loop. I was afraid to restart the computer for a few days after that but did finally (by mistake forgetting about the problem) and it restarted ok without trying to install.
The only problems I’ve been having recently are with Time Machine backups failing sometimes since I don’t do them regularly since I don’t use the computer at home so much. In addition my hard drive was very full, with around 9 gb of 500. After that episode I trashed a bunch of stuff and freed up about 80 gb and backed up, after which I successfully installed 10.13.7 (I think it was).
Yesterday I installed Mojave, and it seems you no longer can see what system installations you’ve recently previously done, which is why I’m not positive about the version numbers.
Edit: I corrected above so it reads 10.13.7.
Yeah, that worked for me too, last week, saving me from the installation failing loop.
I don’t disagree and I suspect if Apple knew the root cause they would have done so by now. Despite the number of users reporting the problem here, it still appears to be a minority and doesn’t match my experience, nor that of several dozen others who I know successfully installed it the first time the tried.
The only way it might get fixed is for users having the issue to contact Apple so they can determine what those users have in common. I’m going to guess that most such users have an older Mac out of warranty and hesitate to call. I would also guess that Apple isn’t willing to devote much in the way of engineering assets to an older OS on older equipment.
I Had the same problem today. OSX 10.13.6. The description of the preliminary misbehaviour is spot-on.
Had this happening 2 times by now, quite scary actually as it’s something I had not seen happening before. Is this rather solely related to a software error that might be fixable or could it be related to a failing ssd, etc…?