Great people share their wisdom without asking for anything in return…

Menu

Did you know that there are specific SIP (System Integrity Protection) requirements for startosinstall so that you can use all of its arguments?

Some of you may think that this is bollocks, but hold on. Not so fast. Go the the High Sierra (Beta) app folder and cd into the Contents/Resources directory. Then enter:

./startosinstall --usage

You may get the following output:

Usage: startosinstall
Arguments
--applicationpath, a path to copy of the OS installer application to start the install with.
--license, prints the user license agreement only.
--agreetolicense, agree to license the license you printed with --license.
--rebootdelay, how long to delay the reboot at the end of preparing. This delay is in seconds and has a maximum of 300 (5 minutes).
--pidtosignal, Specify a PID to which to send SIGUSR1 upon completion of the prepare phase. To bypass "rebootdelay" send SIGUSR1 back to startosinstall.
--converttoapfs, specify either YES or NO on if you wish to convert to APFS.
--installpackage, the path of a package to install after the OS installation is complete; this option can be specified multiple times.
--usage, prints this message.
Example: startosinstall --converttoapfs YES

Or this output:

Usage: startosinstall --volume <target volume path>
Arguments
--applicationpath, a path to copy of the OS installer application to start the install with.
--license, prints the user license agreement only.
--agreetolicense, agree to license the license you printed with --license.
--rebootdelay, how long to delay the reboot at the end of preparing. This delay is in seconds and has a maximum of 300 (5 minutes).
--pidtosignal, Specify a PID to which to send SIGUSR1 upon completion of the prepare phase. To bypass "rebootdelay" send SIGUSR1 back to startosinstall.
--converttoapfs, specify either YES or NO on if you wish to convert to APFS.
--installpackage, the path of a package to install after the OS installation is complete; this option can be specified multiple times.
--usage, prints this message.
--volume, path to the target volume.
Example: startosinstall --volume /Volumes/Target --converttoapfs YES

You see. That’s not the same output, and it depends on your SIP settings. And here is why.

Now. Some of you may have SIP partly or completely disabled, and will not notice the difference. Unlike me. I run my Mac/Hack with SIP fully enabled. That is why I get the first output, and thus I have change the SIP settings before I can use the –volume argument, because startosinstall requires – at least – either CSR_ALLOW_UNRESTRICTED_NVRAM/0x40/64 or CSR_ALLOW_ANY_RECOVERY_OS/0x100/256. Without one of these, the –volume argument won’t be supported.

Please note that this SIP requirement was first introduced in a Beta of Sierra 10.12.4, and I ran into it before, but the only reference I had were my own notes. Not exactly rocket science, but it is something that I wanted to share with you 😉

More than ten years ago I worked on code for VirtualBox. To get OS X 10.5 (codename Leopard) installed on it. And I can happily claim that I was the very first person to do it. That also triggered my attention to OS X.

At that time I left the Ubuntu developer community and started to work for Google Inc. And now. Ten years later. I’m still here. And I became the person who I am. A man now. A father of two great children. The husband of my beautiful wife. People who I love to pieces.

And you know what. Nobody expected me to stay this long. Many thought that I was somebody else. Because I helped my father and later my sister. As a sidekick – first public appearance as a hacker in 2012 and I started to blog in 2013. Boy what a joy that was. Fond memories.

Anyway. Even I thought that I won’t change jobs. Not ever. That is. Until I was asked for a job interview in the US of A. So I went. I listened. Got the offer for a great job, but I declined the offer.

Not that I didn’t like it, because I did, but I promised my mom to carry on her work. As a Doctor. To help people in need. Yeah mom. I made you that promise, and I am a man of my word, so I will do that. Happily.

This is also the reason why you see me using my title (Dr.) for the very first time, here, and in my scripts, and other source code. Something I have refuses to do for many years. Simply because this is not my day job.

Now what?

I am happy to announce that I am set to retire at Google next year, and do something completely different. This was a very difficult decision, and that was why, in part, we went off sailing this summer.

Also. You must have noticed that some of your comments got approved, some time before the actually reply. And you know what. There is a simple explanation for it. The approval is actually done by someone else. My very own sidekick (my wife Angélica who is working as one of the hosts in our hotel in Spain).

In other words. We will carry on with the legacy of Master Chief (Pike’s father) and Revogirl (Pike’s late sister). For as long as possible.

Update: version 4.1 includes two bug fixes and now also supports -a update (to install updates).

I still have some partitions with older versions of macOS High Sierra, and I ran installSeed.py v3.8 on one of them to get the latest beta, but all I got was the previous one. Hmm. That’s odd. That’s not the expected result. Something was wrong.

I checked the catalog data and noticed that we have two sets of updates. Hmm. An unusual situation. Which is not supported in version 3.8. I wanted to have it fixed a.s.a.p. and thus my work was committed 10 hours ago already. But I ran out of time, and energy, to blog about it so here you have it. I hope that installSeed.py v4.0 also works for you. Let’s look at the changes.

Right. The target test partition is still running an older version of macOS 10.13 but the script is already checking for 10.13.1 (per default). As it should. And thus all I had to do was to add the -m 10.13 arguments. Like it says now. Fine. Let’s do that.

Previously I assumed that Apple was going to use one of these Xeon W models, but it turns out that I was wrong – based on new data that I found. Intel apparently makes special (OEM) SKU’s for Apple’s new iMac Pro, and here are the first two known models:

Both running with a lower base frequency than the W-2145 (3.7GHz) and W-2155 (3.3GHz). And there can only be one reason for this. Heat!

Source: Geekbench OpenCL Score 1 and 2
Note: Don’t you worry about the results. Apple isn’t showing it’s hand just yet – the used GPU’s were running at a lower frequency.

Additional data

The board-id that I found in the (assumed) firmware of the iMac Pro is: Mac-7BA5B2D9E42DDD94 and some of the data that I found earlier may be an indication that the new B serie processors include support for processor graphics (IGPU). Another key factor that contributes to the need for a lower base frequency.

Intel Speed Shift Technology

I disassembled the first High Sierra Beta XNU Kernel, months ago, and I found out that Intel Speed Shift Technology aka HWP is set to enabled for processors with CPUID 0x05065X. Like the Intel Xeon W-21NN series processors.

Internal Graphics

Back in June I was surprised to find a reference to “Integrated Video Controller” in the leaked firmware for the iMac Pro. Some time later I also found data in the info.plist of AppleGraphicsDevicePolicy.kext that shows us that Apple disables – note the unload key – the IGPU (the internal GPU). Look here:

This may well be an indication that the new Intel Xeon’s do in fact support processor graphics, but we will have to wait until the actually release of the iMac Pro, or macOS High Sierra 10.13.2 (which Apple appears to be using internally already) before we really know what is going on here.

Edit: If you use my blog article as source, then please be so kind to add a link/reference. Thank you.

Don’t be an ass. Like mac4ever.com for the lack of reference (shame on you) because seriously guys… as a die hard Googler, nobody else blogged about it before I did!

The highlighted board-id (Mac-7BA5B2D9E42DDD94) is the apparent new iMac Pro. One with a 8-core/16 threads and Intel W-2140B processor. And for people wondering about its performance. Well. Take a look at this OpenCL score. This SKU runs at a lower (500 MHz) base frequency than the W-2145. Which runs at a base frequency of 3.7GHz. The 10 core/20 thread SKU is the W-2150B with a base frequency of 3GHz. With a 300MHz lower base frequency than the W-2155.

There are also two (1, 2) CPU Geekbench results with an early SKU (showing Intel 0000%) with a matching CPUID of the one that I found, back in August, in the leaked firmware of the iMac Pro. These are running 1300MHz slower than the W-2145 but note that this may be in fact be the 18 core SKU. Thing is. Apple is using a core/thread limiter. In short. You should take the results with a grain of salt.

Another new one, at the bottom of the list, is the Mac-F221DCC8/MacPro5,1 which comes with the High Sierra installer app.

There are also a total of five board-id’s with an Apple model set to “Unknown”. I did this because we don’t officially know any of their real model names. You may count only four of them, but there’s also this one:

Mac-CF21D135A7D34AA6 | Unknown |AAPLX589.88Z.0161.B00.1705100046

Which I left out intentionally. I have some ideas about the following board-id’s:

But that’s educated guesswork only. Nothing official. Anyway. Here’s the change log. Per revision. From v1.5 up to v2.2

Changelog for v1.5:

– check for installSeed.py and download it when missing.
– code refactored (no more code duplication).
– the output of the scrit is now a lot quicker.
– now reads the supported board-id’s from the firmware payload files.
– changed version number to v1.5

Changelog for v1.6:

– support for older version of efiupdater added.

Changelog for v1.7:

– now using the right patch for support of older versions of efiupdater.

Changelog for v1.8:

– whitespace changes.
– now checking both UUID’s (for old and new hardware models).

Changelog for v1.9:

– read EFI version from IODeviceTree:/rom.

Changelog for v2.0:

– check for Mac-F221DCC8/MacPro5,1 Apple UUID added.
– made some preparation for the next major release.
– shebang line changed.

Changelog for v2.1:
– now also checks the firmware directory of the installer.
– use filename instead of myBoardID (for MacPro5,1).
– removed spaces in one of the Apple UUID’s (done to verify the UUID).

Wait what? Another update? Yes indeed. But listen. The previous versions of EFIver.py where nothing more than a rewrite of a bash script, but the next latest update of EFIver.py (version 1.5) is an important update. It’s not only a rewrite of the first three versions of EFIver.py, but now it also reads the supported board-id’s from the actual firmware files. It will now also download installSeed.py for you (for people who haven’t already). Now take a look at the output: