Installing macOS High Sierra from Scratch: Not So Good a User Experience

One week ago a MacBook Pro of a relative of mine stopped booting. The symptoms indicated a hard disk failure, and the diagnosis confirmed it. I ordered a replacement drive on Amazon and I decided to allocate 30 minutes of a bright Saturday morning to fix it. The procedure should have been very simple:

• Create a bootable image of the latest macOS (High Sierra).
• In the meantime, swap the hard disk in the MacBook Pro (a procedure that hardly takes more than 10 minutes on a MacBook with a serviceable hard disk drive such as this one).
• Boot from an external device.
• Launch the installation.
• Go out and run.

Unfortunately, it took at least twice the estimated time and three macOS installation attempts.

Attempt 1: Launching the macOS Installer

The MacBook Pro booted the base system correctly from the external device, but when I launched the installer, it failed with the following message: 

This copy of the Install macOS High Sierra.app application is damaged and can't be used to install macOS.

A quick search confirmed that this error frequently appears since macOS Sierra and the workarounds I found are quite imaginative. Apparently, many people thinks the installer is actually broken and are trying to download it again. Fortunately, it didn't take that much time to fix the problem. A post on the Apple website described the same problem (although on Sierra) and its solution (after several calls to Apple customer support, according to the author): deleting the ./Contents/SharedSupport/InstallInfo.plist from the bootable image should do the trick. And it did.

Attempt 2: Launching the macOS Installer

The second attempt looked promising: the installer now launched correctly. Unfortunately, it failed on the second screen with the following message:

The recovery server could not be contacted.

The first thing I do in these cases is open a terminal and perform basic checks. The second check I made caught the problem: the system was reporting January, 1st 2001 as the current date. Therefore, most probably, the HTTPS connection to the recovery server was failing because the certificate check was failing (chances are the validity period of that certificate appeared to be in the future). 

I fixed the date using the date command and restarted the macOS installer.

Attempt 3: Finding the Hard Disk Drive

The installer was now working, but it couldn't find any disk to install the system. I quitted the installer (for the third time) and opened Disk Utility. To my surprise, Disk Utility couldn't find any internal disk either. Again, a quick search confirmed the obvious: High Sierra's Disk Utility doesn't recognise unformatted internal drives. I opened the terminal again in order to quickly format the drive:

• First of all, confirm the disk is available and its device name:

$ diskutil list

/dev/disk0 (internal, physical):

[...snip...]

• Then, format it to make it available to Disk Utility:

$ diskutil eraseDisk JHFS+ NewDisk GPT disk0

Disk Utility could now see the device. I reformatted it using APFS, restarted the installer again and this time the I successfully made it to the end of the installation.

Final Thoughts

I never needed to reinstall OS X or macOS on any of the three computers I owned in the last 10 years: this was the first macOS installation from scratch I performed in a very long time. However, the three errors I experienced have three characteristics in common which make this experience unsettling:

• They are obscure and difficult to troubleshoot. I bet most non-tech-savvy user would have to ask for help.
• They have been known for years.
• They are, or seem to be, easily solvable. The date problem, for instance: why wouldn't an installer which requires a working Internet connection not synchronise the current time using NTP?

Come on Apple, you can do better than this.

Modifying Sun Java Enterprise System installation or completely removing it on Solaris 10

I wrote other posts describing why and how I installed components from Sun Microsystems' Sun Java Enterprise System 5 (JES from now on) on Solaris. It may sound somewhat silly, but one of the questions related to the JES installer I heard so far is how software can be uninstalled. That's strange, and more if you consider the nature of Solaris 10 package management system. Somehow, having a GUI makes the situation more complicated, because a person unfamiliar with Solaris 10 and with Sun's way of distributing software would expect the same installer to do the job. Whoever knows of its existence may also also think that prodreg is sufficient to perform the uninstallation, but its not, for the reasons I will clarify soon.

The worst thing, in my humble opinion, is that Sun's documentation is usually good and very detailed. For every product I'm trying to remember, there's always a detailed installation document. What's not so clear to the newbie, in reality, is that documentation is there to be read. If you feel like doing it, read this blog and go here, where you can find complete information about JES installations. You should read it carefully while planning your installations/upgrades/uninstallations.

Here's the long story short.

How the JES installer works

The JES installer is an utility that eases the installation and the configuration of a set of server-side products which are bundled together. The installer also takes care of interdependencies between products, which may be complex, with various preinstallation and postinstallation procedures. The JES installer for Solaris uses the usual operating system package management system to deploy package on a host. For the same reason, the JES installer also provides an uninstallation utility which should be used when removing JES components instead of removing pagkages with other means, such as pkgrm or prodreg.

JES installation utilities

The JES installer can be found on the directory which corresponds to the platform you're installing and its called installer. This is the program you'll launch when installing JES for the first time. If you invoke it with no arguments, a GUI will be displayed and you will be able to choose the packages you need and perform your installation.

Even if having a GUI gives you the idea that everything will be managed for you by it, you're wrong. Read the documents before performing the installation of any document.

Patching installer

If JES has already been installed or if you need to patch the installer itself, you will find another copy (packaged) of the installer in the /var/sadm/prod/sun-entsys5u1i/Solaris_{x86,sparc} directory. Once the JES installer has been patched, that's the copy that should be used when installing or modyfing the current installation.

JES uninstaller

Once the JES installer has installed some of the products of the JES distribution, you will find the uninstallation utility in /var/sadm/prod/SUNWentsys5u1. The uninstaller, as the installer, can be run either in graphical, text or silent mode. Due to the complexity of the relationships between the component, an uninstallation should be carefully planned, too. Once more time: read the docs.

Uninstaller limitations

The JES uninstaller has some limitations, including the following:

• it only uninstalls software installed with the installer
• it does not remove shared components
• it does not support remote uninstallations
• some uninstallation behavior depends on the components being removed and it does not limit to data or configuration files.
• it does not unconfigure the Access Manager SDK on the web server.