To get the latest features and maintain the security, stability, compatibility, and performance of your Mac, it's important to keep your software up to date. Apple recommends that you always use the latest macOS that is compatible with your Mac.

1. El Capitan No Packages
2. No Packages Eligible For Install Mac App

Learn how to upgrade to macOS Big Sur, the latest version of macOS.

MacOS – Mac stuck in “El Capitan” installer loop: “no packages were eligible for install”. My problem is that my Mac starts up to the 'El Capitan' installer. After restarting several times, OS X is still on screen telling me that 'no packages were eligible for install'. Can someone help please, and can you bear in mind that I’m not. Jul 26, 2019 The combo updater contains all the files necessary to install macOS on all Macs, whereas the version downloaded from the App Store only has the files for your specific Mac. It may be that the combo updater works, where the Mac App Store version doesn’t. Install in Recovery Mode. This is the last resort if nothing else works. My end goal was to install macOS 10.13 High Sierra. I read online that one must upgrade to OS X 10.11 before upgrading to macOS 10.13 if one is starting from OS X 10.6. This upgrade route did not work for me no matter how many solutions I attempted.

Check compatibility

The version of macOS that came with your Mac is the earliest version it can use. For example, if your Mac came with macOS Big Sur, it will not accept installation of macOS Catalina or earlier.

If a macOS can't be used on your Mac, the App Store or installer will let you know. For example, it might say that it's not compatible with this device or is too old to be opened on this version of macOS. To confirm compatibility before downloading, check the minimum hardware requirements:

• macOS Catalina 10.15 hardware requirements
• macOS Mojave 10.14 hardware requirements
• macOS High Sierra 10.13 hardware requirements
• macOS Sierra 10.12 hardware requirements
• OS X El Capitan 10.11 hardware requirements
• OS X Yosemite 10.10 hardware requirements

Download macOS using Safari on your Mac

Safari uses these links to find the old installers in the App Store. After downloading from the App Store, the installer opens automatically.

• macOS Catalina 10.15 can upgrade Mojave, High Sierra, Sierra, El Capitan, Yosemite, Mavericks
• macOS Mojave 10.14 can upgrade High Sierra, Sierra, El Capitan, Yosemite, Mavericks, Mountain Lion
• macOS High Sierra 10.13 can upgrade Sierra, El Capitan, Yosemite, Mavericks, Mountain Lion

Safari downloads the following older installers as a disk image named InstallOS.dmg or InstallMacOSX.dmg. Open the disk image, then open the .pkg installer inside the disk image. It installs an app named Install [Version Name]. Open that app from your Applications folder to begin installing the operating system.

• macOS Sierra 10.12 can upgrade El Capitan, Yosemite, Mavericks, Mountain Lion, or Lion
• OS X El Capitan 10.11 can upgrade Yosemite, Mavericks, Mountain Lion, Lion, or Snow Leopard
• OS X Yosemite 10.10can upgrade Mavericks, Mountain Lion, Lion, or Snow Leopard

OSX flat packages are single installer files with .pkg file extensions.

They appear to have originated with OSX 10.5. You can’t install these fileson OSX < 10.5.

The previous packaging formats were bundles rather than single files:

bundle

A structured directory hierarchy that stores files in a way thatfacilitates their retrieval (see glossary in the software delivery legacyguide)

See OSX legacy packaging redux for details.

As far as I know there is no Apple document describing the flat packageformat.

You may find these other pages useful as background:

• A MacTech flat package article;
• An introduction to the flat package format;
• A guide on unpacking flat packages manually;
• A comprehensive stackoverflow package building answer.

About the examples on this page¶

I wrote this page in reStructuredText (reST) for Sphinx, with some customSphinx extensions. The extensions pick up the code fragments in this page andrun them on my laptop as part of the build process for the web pages. Theyalso write out the example files listed on this page. The combination meansthat, at the time I last built the website, I confirmed that the code ran onmy laptop, and gave the output you see here.

Flat packages in general¶

Flat packages are xar archives (see the xar man page).

To see the contents of a flat package, the most convenient command ispkgutil--expand, as in:

This will unpack product archive (meta-packages) and their component packages,and allows you to futz with the directory contents in an_output_dir beforereconstituting the package with:

On OSX, tar will unpack xar archives, and will automatically detect thatthe archive is in xar format with tarxfmy.pkg, if you really want to dothe unpacking without pkgutil.

Different package types¶

Flat packages can be of type:

• product archive – a meta-package format containing one or morecomponent packages with an XML file specifying the behavior of theinstaller, including system and volume requirement checks giving informativeerror messages. See the productbuild man page for more detail.
• component package – an installer to install one component. Generallyincluded as part of a product archive but can be used as an installer inits own right. A component package installer cannot control the behavior ofthe installer, but can abort the install or raise a post-install errorvia preinstall and postinstall scripts.

Component installer¶

A component installer goes through these stages:

1. Runs preinstall script if present. An exit code other than zero abortsthe installation.
2. Writes payload to one or more locations on the target volume
3. Runs postinstall script if present. An exit code other then zero givesan error message.

We start with some component packages that only have scripts and no payload,to show how they work.

Component installer scripts¶

The scripts need to be executable:

Each package needs a package identifier to identify it to the database ofinstalled packages on the target system.

You can list the recorded installed packages on target / with:

Build the package with a fake identifier:

Install the package:

Check the scripts ran by looking for output:

Exit code other than zero causes the installer to give an error message:

Fixed if the script is not run:

There are some useful environment variables available to thepreinstall, postinstall scripts:

Here are the new environment variables inserted by the installer:

These appear to be a superset of the environment variables listed for the oldbundle installers at install operations.

No payload, no receipt¶

El Capitan No Packages

These “scripts only” installers have no payload, and write no package receiptto the package database:

Payload¶

A flat-package component installer can install one or more bundles to givenoutput locations on the target filesystem.

There are two ways of specifying payload with target location:

• Using a destination root, using --root flag to pkgbuild. Thisanalyzes a given directory root-path taking this directory to representthe root / directory of the target system. The installer will copy eachdirectory at root-path to the target system at the same relativefilesystem location.
• By individual bundle component, using --component flag topkgbuild. Specify directories to copy, and give their output locationsseparately using the --install-location flag.

Destination root¶

Do the install:

This install did write a package receipt:

Explicit component(s)¶

We point to a bundle to install and (usually) specify the install location.

In this case the bundle must be a properly formed bundle of some sort.

I’ll make a debug symbols bundle by doing a tiny compilation with clang:

Build, install the package:

The installer has written the expected output files:

You can add more than one bundle to a single component installer.

Here I make another bundle with a different name:

When you add more than one component, you need to give a package identifier,because pkgbuild will not know which component to get an identifier from.

Product archive¶

Component packages give a very basic default install.

Product archives allow you to wrap one or more component installs with aninstall configuration that includes:

• custom welcome, readme, license and conclusion screens;
• custom system requirement and volume requirement checks with informativeerror messages using Javascript code;
• ability to customize choices of component packages to install usingJavascript code.

An XML file named Distribution specifies these options (see distributiondefinition file).

Building product archives with productarchive¶

productarchive has five modes of action:

Archive for “in-app” content¶

This appears to be something to do with the App Store. Use the --contentflag for this one.

Archive from destination root¶

Build an archive from a directory where the paths of the files relative to the--root directory give the output install location on the target volume(see Destination root).

Archive from component bundle(s) or package(s)¶

Build a product archive from one or more components by passing:

• bundle path(s) with one or more uses of the --component flag (seeExplicit component(s)) and / or;
• package paths(s) with one or more uses of the --package flag.

Build product archive with two component bundles:

Make bundles into component packages:

Build product archives from the component packages:

Build a Distribution file from component bundle(s) / packages(s)¶

This builds a template Distribution XML file by analyzing one or morecomponents in the form of bundles or .pkg files. Use the --synthesizeflag.

Analyze two component bundles to give a Distribution file:

Analyze two component packages to give a Distribution file:

Archive from Distribution file¶

Build a product archive from a pre-existing Distribution file, using the--distribution flag. The Distribution file refers to pre-existingcomponent .pkg files. If these are not in the current directory, you cangive paths to find .pkg files with the --package-path flag.

Customizing the Distribution file¶

See: distribution definition file and installer Javascript reference.

Adding system and volume checks¶

Now make the volume check fail:

The volume check gets run on every candidate volume; each volume that passesthe check is eligible for the install.

Debugging Distribution Javascript with system.log¶

Getting the Javascript right can be tricky because it is running in a highlyspecific environment. system.log() can help.

Use the -dumplog flag to the installer to see the log.

Adding custom script checks¶

You can add custom executable scripts or binaries to run via the Javascriptfunctions such as the volume check and the system check.

No Packages Eligible For Install Mac App

You first have to enable the allow-external-scripts option in theDistribution file XML:

This will cause the installer GUI to ask if you want to allow an externalscript to check if the software can be installed.

You can then call external programs via the Javascript system.run()function. The programs you call with system.run either need to be on thesystem PATH that the installer uses, or provided in the installer, usually viathe --scripts flag to productbuild. Here’s an example of a commandalready on the path:

Check the script ran:

Here’s an example of a custom script:

Make a directory to contain the test script:

Use test script to look for any interesting environment variables available tothe custom script:

The script must be executable:

Build the product archive with --scripts flag:

Check the environment variables available to the custom script. We alreadyhave /tmp/my_sudo_envs.log with the standard environment variablesavailable as root, so look for the difference:

There do not seem to be any environment variables to tell us where theinstaller .pkg file is. Here we can work out which volume the installeris installing to with the SUDO_COMMAND variable, but this will only workfor command line installs - the installer GUI does not set this variable.

Customizing the installer pages¶

See distribution definition file for details.

You can customize these pages:

• Welcome (<welcome.../> element)
• Readme (<readme.../>)
• License (<license.../>)
• Conclusion (<conclusion.../>)

To do this, you specify the filename containing the custom text, and theformat of the file. For example:

The file should be in the Resources/<language>.lproj directory of theinstaller .pkg, where <language> is a language like “English”,“French” or “Spanish”, or shorthand for these such as “en”, “fr”, “es”. Youcan provide a Resources directory with the --resources flag toproductbuild.

We use the --resources flag to add the resources directory:

The welcome won’t show up in the command line install, so you need to run thisinstaller via the GUI to see the new text.

I used an HTML file here, and that works as expected, for me at least. Thereare many installers that use .rtf files instead of HTML, but I heard arumor that productbuild does not deal with these correctly. If you want touse rich text format files with productbuild, you might have to do somepost-processing of your installer with – pkgutil--expandmy_archive.pkgout_dir; (futz); pkgutil--flattenout_dirmy_archive.pkg.