macOS High Sierra (10.13) Unsupported Macs Thread

[Forbidden Era]

I made some progress.. The one thing I was thinking could've caused an issue may have been it, as I said, when I did the post install, I had to do it from target disk mode from my MBP this the post install detected the AMD in my laptop and wanted to apply that patch.

I copied the kexts that patch changes from the installer to SLE and rebooted, I got glitchyness and it didn't work too well, although the one screen on the 560ti looked the best..? So I figured maybe the kexts were slightly diff on the installer and maybe a reinstall would help..so I reinstalled it, not sure if it actually overwrote those kexts now either as I still got glitchiness after rebooting..not as bad this time though..but with the glitchiness, it would kick me out shortly after logging in..

Noticing my Cinema display on the 560ti had less glitches, I unplugged the screens from the Quadro and tried logging in again.. No glitches, and I am logged in, with acceleration and NVIDIA driver running, supposedly.

CUDA-Z still wont run.. but I can do rotation, and the graphics are clearly much smoother... I wouldn't be surprised if I have to find an older CUDA package for my card maybe..maybe even older drivers..but really I don't need CUDA atm..just proper acceleration..

Now to figure out why the Quadro boots me out..
[doublepost=1544783634][/doublepost]Well, I wasn't expecting THAT..

METAL: SUPPORTED

what the heck? I guess FERMI can do metal!?!

Edit: Fermi CANNOT do metal. My system information said Metal: Supported for some reason but openglviewer showed no support and metal apps (tried Dirt Rally and a metal benchmark app) would crash. I did not have metal disabled though and did have accel. I ended up getting a 960 instead.

But perhaps not very well? Maybe that's why the quadro is booting me out with displays attached?

I don't get booted if it's in there w/ no displays.

Both my cards are running at 2.5GT/s though for some reason. Tried swapping the Quadro from Slot3 (x16) to slot 2 (x4) and no difference. At first it was partially wiggled out a bit from my testing but I don't think this affected anything..hopefully..but who knows, could've messed it up a bit.. though the boot screen renders fine.. and the glitches are identical to what they were before it wiggled...so hw prob fine, I'm sure it's sw.

I guess I can have Mojave now too, if this card'll do some Metal.. I thought it was 6xx or kepler up?

BTW This is all running without WhateverGreen/Lilu - just stock OS X + dosdude1 patch.

 

[Forbidden Era]

Screw Fermi!

Now I have Metal compatibility. Yay.

Just gotta get CUDA working now, for some reason, she don't wanna go, on latest web drivers and cuda drivers, cuda-z says it detects no CUDA cards

 

[philgxxd]

If you re-apply the nightshift patch there is a very good chance it will break some of your System Preference panels, namely the Trackpad and Keyboard panels.
If you'd like to test this, first make sure you have a known bootable backup of your system just in case you need to restore back to a working system.

That happened to me after running the latest update from the App Store and applying the Nightshift patch again from the Applications folder.
After that I couldn't open anymore the preferences for Mouse,Keyboard and Trackpad on my MBP 4,1 17".
So I did the Postinstall from the USB pen drive twice, during the latter with forced kextcache option checked but that didn't help.
Is there any solution to this ?

UPDATE: I did a search and found the answer...USE f.lux

#4237

 

[Forbidden Era]

Still can't get CUDA-Z to launch, says no Cuda cards. Have latest web drivers and cuda drivers. Pew pew.

This is with only the 960 now. The fermi cards are retired, the fans were f**ked on the 560ti anwyay.

Curious..I have never seen any nvidia card ramp up fans in os x. Heck, I don't even know if its ramping core clocks and such. The game I want to play runs at like 0.25fps (Dirt Rally, metal-based game) but the gfxbench metal benches ran smoothly.

 

[Squirrels Everywhere]

No, haven't run @dosdude1's post-install scripts again. Don't know if I should? I just rebooted and haven't noticed any issues yet. Having said that, the Patch Updater shows that I have various patches installed - one of which is Night Shift, but I don't see the Night Shift tab in the Displays preference pane. I don't really use Night Shift but maybe I should re-apply them all? Willing to take advice here.

You need to follow the instructions in section Security And OS Standalone Updates in the OP. That'll tell you how to add your board id, and remove your model from the Unsupported list. Being Unix-literate, I didn't faff around using Text Wrangler of BBedit - I just edited in place using old-skool vi.

<snip>.

I am on a Mac Pro 3,1 with High Sierra and had the same failure with SecUpd2018-003, "An error occurred while running scripts from the package “XXXX.RecoveryHDUpdate.pkg” - first time I’ve had a problem updating. OS was toast. While I could boot, there were dozens of duplicate kext errors. Inability to update the recovery partition trashes the boot volume? Seriously?

Install.log seemed to indicate possibly it was trying to create a new, or maybe resize, the recovery partition, which wouldn't work the the file system mounted. Rather than render replaceRecovery inert, I chose to run it by hand to see if I could get any more diagnostics out of it.

- Restored OS and recovery partition from a backup
- Unpacked the security update package (I unpacked to /var/tmp/expanded) per the instructions sited by mrploppy, from the first page of this thread. Modify per instructions to allow it to run on the current machine.
- The recovery partition files image will be found at /var/tmp/expanded/EmbeddedOSFirmware.pkg/RecoveryHDMeta.dmg
- Mount the image: open /var/tmp/expanded/EmbeddedOSFirmware.pkg/RecoveryHDMeta.dmg
- cd /var/tmp/expanded/SecUpd2018-003HighSierra.RecoveryHDUpdate.pkg/Scripts

I first tried calling dm directly using install.log as a guide. This is the part that failed in the App Store install:

Enter (all one line): ./Tools/dm ensureRecoveryPartition / /Volumes/RecoveryHDMeta/BaseSystem.dmg /Volumes/RecoveryHDMeta/BaseSystem.chunklist /Volumes/RecoveryHDMeta/AppleDiagnostics.dmg /Volumes/RecoveryHDMeta/AppleDiagnostics.chunklist 0 0 0

Log showed this, which was not in the previous failure log:

HFS/CS EnsureRecoveryPartition: Attaching disk image /Volumes/RecoveryHDMeta/BaseSystem.dmg
HFS/CS EnsureRecoveryPartition: Operation 10.0% complete
HFS/CS EnsureRecoveryPartition: Reusing recovery partition; no growth needed; host is a simple storage partition
HFS/CS EnsureRecoveryPartition: Checking and re-using booter

dm completed without error, recovery partition successfully updated. I then tried running the entire replaceRecovery script by hand.

- Enter: diskutil unmount /Volumes/RecoveryHDMeta (Unmount the previously mounted disk image)
- Enter: export PACKAGE_PATH=/private/var/tmp/RecoveryHDMeta.dmg (this environment variable is used by the script, rather than passed as a command parameter)
- Enter: ./replaceRecovery / /
The second parameter is the volume you are updating (current boot volume is root).
The first parameter is unused by the script.


This again showed:

HFS/CS EnsureRecoveryPartition: Operation 10.0% complete
HFS/CS EnsureRecoveryPartition: Reusing recovery partition; no growth needed; host is a simple storage partition
HFS/CS EnsureRecoveryPartition: Checking and re-using booter

and ran to completion without error. Later checking the recovery partition, it was updated to 10.13.6, and I was able to boot from it. Prior to the update, recovery partition was 10.13.2

After successfully updating the recovery partition, I repackaged the security update, and ran the modified standalone security update package. The security update ran without a hitch.

Security update is installed, and recovery partition is updated and still bootable. YMMV..

 

[mrploppy]

I am on a Mac Pro 3,1 with High Sierra and had the same failure with SecUpd2018-003, "An error occurred while running scripts from the package “XXXX.RecoveryHDUpdate.pkg” - first time I’ve had a problem updating. OS was toast. While I could boot, there were dozens of duplicate kext errors. Inability to update the recovery partition trashes the boot volume? Seriously?

Install.log seemed to indicate possibly it was trying to create a new, or maybe resize, the recovery partition, which wouldn't work the the file system mounted. Rather than render replaceRecovery inert, I chose to run it by hand to see if I could get any more diagnostics out of it.

- Restored OS and recovery partition from a backup
- Unpacked the security update package (I unpacked to /var/tmp/expanded) per the instructions sited by mrploppy, from the first page of this thread. Modify per instructions to allow it to run on the current machine.
- The recovery partition files image will be found at /var/tmp/expanded/EmbeddedOSFirmware.pkg/RecoveryHDMeta.dmg
- Mount the image: open /var/tmp/expanded/EmbeddedOSFirmware.pkg/RecoveryHDMeta.dmg
- cd /var/tmp/expanded/SecUpd2018-003HighSierra.pkg/Scripts

I first tried calling dm directly using install.log as a guide. This is the part that failed in the App Store install:

Enter (all one line): ./Tools/dm ensureRecoveryPartition / /Volumes/RecoveryHDMeta/BaseSystem.dmg /Volumes/RecoveryHDMeta/BaseSystem.chunklist /Volumes/RecoveryHDMeta/AppleDiagnostics.dmg /Volumes/RecoveryHDMeta/AppleDiagnostics.chunklist 0 0 0

Log showed this, which was not in the previous failure log:

HFS/CS EnsureRecoveryPartition: Attaching disk image /Volumes/RecoveryHDMeta/BaseSystem.dmg
HFS/CS EnsureRecoveryPartition: Operation 10.0% complete
HFS/CS EnsureRecoveryPartition: Reusing recovery partition; no growth needed; host is a simple storage partition
HFS/CS EnsureRecoveryPartition: Checking and re-using booter

dm completed without error, recovery partition successfully updated. I then tried running the entire replaceRecovery script by hand.

- Enter: diskutil unmount /Volumes/RecoveryHDMeta (Unmount the previously mounted disk image)
- Enter: export PACKAGE_PATH=/private/var/tmp/RecoveryHDMeta.dmg (this environment variable is used by the script, rather than passed as a command parameter)
- Enter: ./replaceRecovery / /
The second parameter is the volume you are updating (current boot volume is root).
The first parameter is unused by the script.


This again showed:

HFS/CS EnsureRecoveryPartition: Operation 10.0% complete
HFS/CS EnsureRecoveryPartition: Reusing recovery partition; no growth needed; host is a simple storage partition
HFS/CS EnsureRecoveryPartition: Checking and re-using booter

and ran to completion without error. Later checking the recovery partition, it was updated to 10.13.6, and I was able to boot from it. Prior to the update, recovery partition was 10.13.2

After successfully updating the recovery partition, I repackaged the security update, and ran the modified standalone security update package. The security update ran without a hitch.

Security update is installed, and recovery partition is updated and still bootable. YMMV..

Interesting. I'll read this in more detail later but my initial comment is that, while I've had errors in the past related to updating the recovery partition, it's never resulted in an unbootable system.

I tried looking at the dm script but it's binary. Do you know what its purpose is, and what it's attempting to do? And what does dm stand for?

So am I right in thinking that when you run the replaceRecovery script, the "hdiutil attach" works fine?

@Squirrels Everywhere
Update: Now that I've had a closer look, I have a couple more points:
1. In the instructions you give, I think you meant
cd /var/tmp/expanded/SecUpd2018-003HighSierra.RecoveryHDUpdate.pkg/Scripts
There is no replaceRecovery script in /var/tmp/expanded/SecUpd2018-003HighSierra.pkg
2. When you refer to running dm directly " because this is the part that failed". To be precise, for myself and others, it's not the dm that fails - it's the "hdiutil attach" that precedes it. This causes the replaceRecovery script to exit at that point.
3. The first parameter to replaceRecovery is used to determine the filesystem type (apfs or hfs). The dm command is different if it's apfs.

 

[Squirrels Everywhere]

Interesting. I'll read this in more detail later but my initial comment is that, while I've had errors in the past related to updating the recovery partition, it's never resulted in an unbootable system.

I tried looking at the dm script but it's binary. Do you know what its purpose is, and what it's attempting to do? And what does dm stand for?

So am I right in thinking that when you run the replaceRecovery script, the "hdiutil attach" works fine?

@Squirrels Everywhere
Update: Now that I've had a closer look, I have a couple more points:
1. In the instructions you give, I think you meant
cd /var/tmp/expanded/SecUpd2018-003HighSierra.RecoveryHDUpdate.pkg/Scripts
There is no replaceRecovery script in /var/tmp/expanded/SecUpd2018-003HighSierra.pkg
2. When you refer to running dm directly " because this is the part that failed". To be precise, for myself and others, it's not the dm that fails - it's the "hdiutil attach" that precedes it. This causes the replaceRecovery script to exit at that point.
3. The first parameter to replaceRecovery is used to determine the filesystem type (apfs or hfs). The dm command is different if it's apfs.

I should have mentioned that I am using hfs rather than apfs. My High Sierra is also a simple partition, not Core Storage.

I don't know what dm stands for, but maybe "disk management", and it appears to be the binary the does the actual updating of the recovery partition using the supplied mounted .dmg. From the command usage:

Private utility to run APIs from DiskManagement framework for Apple installers​

Usage: dm <verb> <parameters> where <verb> is as follows:

erp|ensureRecoveryPartition
erb|ensureRecoveryBooter​

On #1, you are absolutely right. I copied and pasted from the wrong place. My apologies. Updated the post.

On #2, that is interesting. As far as I can tell, for me it was dm that failed - the actual updating of the recovery partition. In the log below, you can see that the disk image was mounted and it moved on to execute dm. hdiutil failing doesn't make much sense unless the .dmg is bad or missing - it's just mounting a disk image.

On #3, that $1 is an awk parameter, not the shell script input parameter 1. The file system type is determined by the replaceRecovery script, not passed as a command parameter. In replaceRecovery script, you will find the line:

FS_TYPE=$(diskutil info "${TARGET}" | awk '$1 == "Type" { print $NF }')​

The '$1' is a variable for awk. Try executing the above command replacing ${TARGET} with the file system of your choice, and then: echo $FS_TYPE. It grabs the file system type from "diskutil info" output.

Here is the log I received on the failure:

2018-12-14 20:36:25-06 macpro system_installd[1006]: replaceRecovery: Attempting to create temporary mount point
2018-12-14 20:36:25-06 macpro system_installd[1006]: replaceRecovery: Attempting mount of /Library/Updates/041-20511/SecUpd2018-003HighSierra.RecoveryHDUpdate.pkg to /var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/tmp.cJBCmrK1
2018-12-14 20:36:26-06 macpro system_installd[1006]: replaceRecovery: Checksumming Protective Master Boot Record (MBR : 0)…
2018-12-14 20:36:26-06 macpro system_installd[1006]: replaceRecovery: Protective Master Boot Record (MBR :: verified CRC32 $B846FF09

<snip>

2018-12-14 20:36:31-06 macpro system_installd[1006]: replaceRecovery: /dev/disk13 GUID_partition_scheme
2018-12-14 20:36:31-06 macpro system_installd[1006]: replaceRecovery: /dev/disk13s1 Apple_HFS /private/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/tmp.cJBCmrK1

<snip>

2018-12-14 20:36:31-06 macpro diskmanagementd[1636]: diskmanagement: [DMToolRecoveryPartition ensureRecoveryPartitionForVolume:]: donor disk's storage system is simple so it itself will be the donor
2018-12-14 20:36:31-06 macpro diskmanagementd[1636]: diskmanagement: [DMToolRecoveryPartition ensureRecoveryPartitionForVolume:]: normalized donor: logical=0x7fa76d803408=disk3s4=High Sierra SSD=(iflvuuid=(null)) physical=0x70000eddfb40=disk3s4=High Sierra SSD=disk3s4 storage=(null)

<snip>

2018-12-14 20:36:34-06 macpro system_installd[1006]: replaceRecovery: ./Tools/dm - dm - Version 5
2018-12-14 20:36:34-06 macpro system_installd[1006]: replaceRecovery: HFS/CS EnsureRecoveryPartition: LogicalTarget=disk3s4 BaseSystemDMG=/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/tmp.cJBCmrK1/BaseSystem.dmg BaseSystemCL=/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/tmp.cJBCmrK1/BaseSystem.chunklist DiagDMG=/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/tmp.cJBCmrK1/AppleDiagnostics.dmg DiagCL=/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/tmp.cJBCmrK1/AppleDiagnostics.chunklist VerifyImage=0 RepairDonor=0 Bless=0
2018-12-14 20:36:34-06 macpro system_installd[1006]: replaceRecovery: HFS/CS EnsureRecoveryPartition: Async call initiate
2018-12-14 20:36:34-06 macpro system_installd[1006]: replaceRecovery: HFS/CS EnsureRecoveryPartition: Operation in progress
2018-12-14 20:36:34-06 macpro system_installd[1006]: replaceRecovery: HFS/CS EnsureRecoveryPartition: Operation start confirmed
2018-12-14 20:36:34-06 macpro system_installd[1006]: replaceRecovery: HFS/CS EnsureRecoveryPartition: Attaching disk image /var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/tmp.cJBCmrK1/BaseSystem.dmg
2018-12-14 20:36:34-06 macpro system_installd[1006]: replaceRecovery: HFS/CS EnsureRecoveryPartition: Operation 10.0% complete
2018-12-14 20:36:34-06 macpro system_installd[1006]: PackageKit: releasing Spotlight indexing
2018-12-14 20:36:34-06 macpro install_monitor[2318]: Re-included: /Applications, /Developer, /Library, /System, /bin, /private, /sbin, /usr
2018-12-14 20:36:35-06 macpro system_installd[1006]: PackageKit: releasing backupd
2018-12-14 20:36:35-06 macpro system_installd[1006]: PackageKit: allow user idle system sleep
2018-12-14 20:36:35-06 macpro system_installd[1006]: PackageKit: Install Failed: Error Domain=PKInstallErrorDomain Code=112 "An error occurred while running scripts from the package “SecUpd2018-003HighSierra.RecoveryHDUpdate.pkg”." UserInfo={NSFilePath=replaceRecovery, NSURL=file:///Library/Updates/041-20511/SecUpd2018-003HighSierra.RecoveryHDUpdate.pkg, PKInstallPackageIdentifier=com.apple.pkg.SecUpd2018-003HighSierra.RecoveryHDUpdate.17G4015, NSLocalizedDescription=An error occurred while running scripts from the package “SecUpd2018-003HighSierra.RecoveryHDUpdate.pkg”.} {
<snip>

 

[mrploppy]

I should have mentioned that I am using hfs rather than apfs. My High Sierra is also a simple partition, not Core Storage.

I don't know what dm stands for, but maybe "disk management", and it appears to be the binary the does the actual updating of the recovery partition using the supplied mounted .dmg. From the command usage:

Private utility to run APIs from DiskManagement framework for Apple installers​

Usage: dm <verb> <parameters> where <verb> is as follows:

erp|ensureRecoveryPartition
erb|ensureRecoveryBooter​

On #1, you are absolutely right. I copied and pasted from the wrong place. My apologies. Updated the post.

On #2, that is interesting. As far as I can tell, for me it was dm that failed - the actual updating of the recovery partition. In the log below, you can see that the disk image was mounted and it moved on to execute dm. hdiutil failing doesn't make much sense unless the .dmg is bad or missing - it's just mounting a disk image.

On #3, that $1 is an awk parameter, not the shell script input parameter 1. The file system type is determined by the replaceRecovery script, not passed as a command parameter. In replaceRecovery script, you will find the line:

FS_TYPE=$(diskutil info "${TARGET}" | awk '$1 == "Type" { print $NF }')​

The '$1' is a variable for awk. Try executing the above command replacing ${TARGET} with the file system of your choice, and then: echo $FS_TYPE. It grabs the file system type from "diskutil info" output.

Here is the log I received on the failure:

2018-12-14 20:36:25-06 macpro system_installd[1006]: replaceRecovery: Attempting to create temporary mount point
2018-12-14 20:36:25-06 macpro system_installd[1006]: replaceRecovery: Attempting mount of /Library/Updates/041-20511/SecUpd2018-003HighSierra.RecoveryHDUpdate.pkg to /var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/tmp.cJBCmrK1
2018-12-14 20:36:26-06 macpro system_installd[1006]: replaceRecovery: Checksumming Protective Master Boot Record (MBR : 0)…
2018-12-14 20:36:26-06 macpro system_installd[1006]: replaceRecovery: Protective Master Boot Record (MBR :: verified CRC32 $B846FF09

<snip>

2018-12-14 20:36:31-06 macpro system_installd[1006]: replaceRecovery: /dev/disk13 GUID_partition_scheme
2018-12-14 20:36:31-06 macpro system_installd[1006]: replaceRecovery: /dev/disk13s1 Apple_HFS /private/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/tmp.cJBCmrK1

<snip>

2018-12-14 20:36:31-06 macpro diskmanagementd[1636]: diskmanagement: [DMToolRecoveryPartition ensureRecoveryPartitionForVolume:]: donor disk's storage system is simple so it itself will be the donor
2018-12-14 20:36:31-06 macpro diskmanagementd[1636]: diskmanagement: [DMToolRecoveryPartition ensureRecoveryPartitionForVolume:]: normalized donor: logical=0x7fa76d803408=disk3s4=High Sierra SSD=(iflvuuid=(null)) physical=0x70000eddfb40=disk3s4=High Sierra SSD=disk3s4 storage=(null)

<snip>

2018-12-14 20:36:34-06 macpro system_installd[1006]: replaceRecovery: ./Tools/dm - dm - Version 5
2018-12-14 20:36:34-06 macpro system_installd[1006]: replaceRecovery: HFS/CS EnsureRecoveryPartition: LogicalTarget=disk3s4 BaseSystemDMG=/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/tmp.cJBCmrK1/BaseSystem.dmg BaseSystemCL=/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/tmp.cJBCmrK1/BaseSystem.chunklist DiagDMG=/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/tmp.cJBCmrK1/AppleDiagnostics.dmg DiagCL=/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/tmp.cJBCmrK1/AppleDiagnostics.chunklist VerifyImage=0 RepairDonor=0 Bless=0
2018-12-14 20:36:34-06 macpro system_installd[1006]: replaceRecovery: HFS/CS EnsureRecoveryPartition: Async call initiate
2018-12-14 20:36:34-06 macpro system_installd[1006]: replaceRecovery: HFS/CS EnsureRecoveryPartition: Operation in progress
2018-12-14 20:36:34-06 macpro system_installd[1006]: replaceRecovery: HFS/CS EnsureRecoveryPartition: Operation start confirmed
2018-12-14 20:36:34-06 macpro system_installd[1006]: replaceRecovery: HFS/CS EnsureRecoveryPartition: Attaching disk image /var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/tmp.cJBCmrK1/BaseSystem.dmg
2018-12-14 20:36:34-06 macpro system_installd[1006]: replaceRecovery: HFS/CS EnsureRecoveryPartition: Operation 10.0% complete
2018-12-14 20:36:34-06 macpro system_installd[1006]: PackageKit: releasing Spotlight indexing
2018-12-14 20:36:34-06 macpro install_monitor[2318]: Re-included: /Applications, /Developer, /Library, /System, /bin, /private, /sbin, /usr
2018-12-14 20:36:35-06 macpro system_installd[1006]: PackageKit: releasing backupd
2018-12-14 20:36:35-06 macpro system_installd[1006]: PackageKit: allow user idle system sleep
2018-12-14 20:36:35-06 macpro system_installd[1006]: PackageKit: Install Failed: Error Domain=PKInstallErrorDomain Code=112 "An error occurred while running scripts from the package “SecUpd2018-003HighSierra.RecoveryHDUpdate.pkg”." UserInfo={NSFilePath=replaceRecovery, NSURL=file:///Library/Updates/041-20511/SecUpd2018-003HighSierra.RecoveryHDUpdate.pkg, PKInstallPackageIdentifier=com.apple.pkg.SecUpd2018-003HighSierra.RecoveryHDUpdate.17G4015, NSLocalizedDescription=An error occurred while running scripts from the package “SecUpd2018-003HighSierra.RecoveryHDUpdate.pkg”.} {
<snip>

Firstly, I owe you an apology. You're absolutely right about the awk, of course. I'd actually run that statement from the command line to see what diskutil returned ... and then I had a complete brain fart.

It's definitely the "hdiutil attach" in replaceRecovery that fails for me. I reported this way back - see post #3640 - and possibly earlier. The error I get is "replaceRecovery: hdiutil: attach failed - Device not configured"

As a test, today I tried performing the hdiutil attach from the command line. With the plain vanilla SecUpd2018-003HighSierra.pkg it works and mounts the images you quoted in your post. However, with the modified pkg the hdiutil attach fails. The error I get from the command line is "image not recognized". So, my quandary is: the pkg needs modification in order to pass the supported platform test, but the modified (and re-packaged) pkg fails the hdiutil attach during replaceRecovery.

Could you do me a favour and perform the same tests for me and see if you get the same error? Clearly there's something different about the repackaged modified pkg (aside from the edits made) that's causing it to fail to mount. I'm no expert in this matter and despite turning on -verbose i can't make head nor tail of it.

 

[Squirrels Everywhere]

Firstly, I owe you an apology. You're absolutely right about the awk, of course. I'd actually run that statement from the command line to see what diskutil returned ... and then I had a complete brain fart.

It's definitely the "hdiutil attach" in replaceRecovery that fails for me. I reported this way back - see post #3640 - and possibly earlier. The error I get is "replaceRecovery: hdiutil: attach failed - Device not configured"

As a test, today I tried performing the hdiutil attach from the command line. With the plain vanilla SecUpd2018-003HighSierra.pkg it works and mounts the images you quoted in your post. However, with the modified pkg the hdiutil attach fails. The error I get from the command line is "image not recognized". So, my quandary is: the pkg needs modification in order to pass the supported platform test, but the modified (and re-packaged) pkg fails the hdiutil attach during replaceRecovery.

Could you do me a favour and perform the same tests for me and see if you get the same error? Clearly there's something different about the repackaged modified pkg (aside from the edits made) that's causing it to fail to mount. I'm no expert in this matter and despite turning on -verbose i can't make head nor tail of it.

Mounting the image from the modified package seems to work for me. See below.

Digging through the install log after I manually updated the recovery partition, I'm not finding any evidence it called replaceRecovery. My assumption is that the installer determined the recovery partition was already current, so didn't need to call that. But I'm also not an expert with installers, so IDK for sure. I did install using the modified .pkg, rather from App Store.

I tried your test two different ways - with a fixed mount point, and using the directory created by "mktemp -d". Both worked.

$ pkgutil --expand /Volumes/Mac\ Pro/Misc\ Stuff/Downloads/MacOSX\ Updates/High\ Sierra/SecUpd2018-003HighSierra.Modified.pkg /tmp/test

$ mkdir /tmp/mountme
$ /usr/bin/hdiutil attach -nobrowse /tmp/test/EmbeddedOSFirmware.pkg/RecoveryHDMeta.dmg -mountpoint /tmp/mountme

Checksumming Protective Master Boot Record (MBR : 0)…
Protective Master Boot Record (MBR :: verified CRC32 $B846FF09
<snip>
Checksumming GPT Header (Backup GPT Header : 7)…
GPT Header (Backup GPT Header : 7): verified CRC32 $AC07A0F6
verified CRC32 $0616C30D
/dev/disk24 GUID_partition_scheme
/dev/disk24s1 Apple_HFS /private/tmp/mountme
$ umount /tmp/mountme


$ MOUNT_POINT="$(/usr/bin/mktemp -d)"
$ echo $MOUNT_POINT
/var/folders/yf/kpk1j8tx5q3f07_skhp213900000gn/T/tmp.PWgVLVsM

$ /usr/bin/hdiutil attach -nobrowse /tmp/test/EmbeddedOSFirmware.pkg/RecoveryHDMeta.dmg -mountpoint $MOUNT_POINT

/dev/disk24 GUID_partition_scheme
/dev/disk24s1 Apple_HFS /private/var/folders/yf/kpk1j8tx5q3f07_skhp213900000gn/T/tmp.PWgVLVsM

$ umount $MOUNT_POINT
$ rmdir $MOUNT_POINT

 

[mrploppy]

Mounting the image from the modified package seems to work for me. See below.

Digging through the install log after I manually updated the recovery partition, I'm not finding any evidence it called replaceRecovery. My assumption is that the installer determined the recovery partition was already current, so didn't need to call that. But I'm also not an expert with installers, so IDK for sure. I did install using the modified .pkg, rather from App Store.

I tried your test two different ways - with a fixed mount point, and using the directory created by "mktemp -d". Both worked.

$ pkgutil --expand /Volumes/Mac\ Pro/Misc\ Stuff/Downloads/MacOSX\ Updates/High\ Sierra/SecUpd2018-003HighSierra.Modified.pkg /tmp/test

$ mkdir /tmp/mountme
$ /usr/bin/hdiutil attach -nobrowse /tmp/test/EmbeddedOSFirmware.pkg/RecoveryHDMeta.dmg -mountpoint /tmp/mountme

Checksumming Protective Master Boot Record (MBR : 0)…
Protective Master Boot Record (MBR :: verified CRC32 $B846FF09
<snip>
Checksumming GPT Header (Backup GPT Header : 7)…
GPT Header (Backup GPT Header : 7): verified CRC32 $AC07A0F6
verified CRC32 $0616C30D
/dev/disk24 GUID_partition_scheme
/dev/disk24s1 Apple_HFS /private/tmp/mountme
$ umount /tmp/mountme


$ MOUNT_POINT="$(/usr/bin/mktemp -d)"
$ echo $MOUNT_POINT
/var/folders/yf/kpk1j8tx5q3f07_skhp213900000gn/T/tmp.PWgVLVsM

$ /usr/bin/hdiutil attach -nobrowse /tmp/test/EmbeddedOSFirmware.pkg/RecoveryHDMeta.dmg -mountpoint $MOUNT_POINT

/dev/disk24 GUID_partition_scheme
/dev/disk24s1 Apple_HFS /private/var/folders/yf/kpk1j8tx5q3f07_skhp213900000gn/T/tmp.PWgVLVsM

$ umount $MOUNT_POINT
$ rmdir $MOUNT_POINT

Thanks for doing that. Much appreciated. Not sure if we're talking at slightly crossed purposes though. What I see in my install log, albeit with my doctored replaceRecovery script is

installd[5269]: replaceRecovery: But NOT ... Attempting mount of /Users/xxxxx/Desktop/SecUpd2018-003Modified.pkg to /var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/tmp.gHQvlSr0

My script doesn't do the attach, because I've commented it out, but it still echos what it would have tried to do. So, I take that to mean that the installation, when run with the un-doctored script, is trying to attach the whole Modified.pkg (which in effect only mounts the dmg's within it, AFAIK) and not just the RecoveryHDUpdate pkg from inside it. Do you agree?

Would you mind trying the test again, but this time with the whole modified pkg?

 

[Squirrels Everywhere]

Thanks for doing that. Much appreciated. Not sure if we're talking at slightly crossed purposes though. What I see in my install log, albeit with my doctored replaceRecovery script is

installd[5269]: replaceRecovery: But NOT ... Attempting mount of /Users/xxxxx/Desktop/SecUpd2018-003Modified.pkg to /var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/tmp.gHQvlSr0

My script doesn't do the attach, because I've commented it out, but it still echos what it would have tried to do. So, I take that to mean that the installation, when run with the un-doctored script, is trying to attach the whole Modified.pkg (which in effect only mounts the dmg's within it, AFAIK) and not just the RecoveryHDUpdate pkg from inside it. Do you agree?

Would you mind trying the test again, but this time with the whole modified pkg?

Ahhh... I looked closer at my original failure log. Now I'm with you. My original failure was an install from App Store, unmodified pkg - got past the mount and failed on the "dm". Your original failure was using a modified standalone pkg file, which failed on the mount, before it got to dm. I am seeing the same (or at least similar) failure as you trying to mount the modified pkg:

$ /usr/bin/hdiutil attach -nobrowse /tmp/SecUpd2018-003HighSierra.Modified.pkg -mountpoint /tmp/mountme

hdiutil: attach failed - image not recognized

$ hdiutil attach -nobrowse /Volumes/Security\ Update\ 2018-003/SecUpd2018-003HighSierra.pkg -mountpoint /tmp/mountme

Checksumming Protective Master Boot Record (MBR : 0)…
<snip>
/dev/disk26 GUID_partition_scheme
/dev/disk26s1 Apple_HFS /private/tmp/mountme

$ ls -la /tmp/mountme

total 951712
drwxr-xr-x 6 root wheel 272 Nov 27 16:31 .
drwxrwxrwt 30 root wheel 1020 Dec 19 16:13 ..
-rw-r--r-- 1 root wheel 328 Nov 27 16:31 AppleDiagnostics.chunklist
-rw-r--r--@ 1 root wheel 2943304 Nov 27 15:49 AppleDiagnostics.dmg
-rw-r--r-- 1 root wheel 1984 Nov 27 16:31 BaseSystem.chunklist
-rw-r--r--@ 1 root wheel 484320396 Nov 27 15:50 BaseSystem.dmg

I never even considered that a .pkg could be passed to hdiutil as a disk image - no idea how to rebuild the modified package that way. At least at first glance, they look the same in Pacifist.

The workaround seems to be to run replaceRecovery by hand passing it the correct .dmg in the environment variable, to update the recovery partition, then run the full installer - and that seemed to be absolutely required for me. But still, it sure would be good to know how to correctly rebuild the .pkg so it can be processed the same as the original Apple one (and see if it fails on dm...).

 

[mrploppy]

Ahhh... I looked closer at my original failure log. Now I'm with you. My original failure was an install from App Store, unmodified pkg - got past the mount and failed on the "dm". Your original failure was using a modified standalone pkg file, which failed on the mount, before it got to dm. I am seeing the same (or at least similar) failure as you trying to mount the modified pkg:

$ /usr/bin/hdiutil attach -nobrowse /tmp/SecUpd2018-003HighSierra.Modified.pkg -mountpoint /tmp/mountme

hdiutil: attach failed - image not recognized

$ hdiutil attach -nobrowse /Volumes/Security\ Update\ 2018-003/SecUpd2018-003HighSierra.pkg -mountpoint /tmp/mountme

Checksumming Protective Master Boot Record (MBR : 0)…
<snip>
/dev/disk26 GUID_partition_scheme
/dev/disk26s1 Apple_HFS /private/tmp/mountme

$ ls -la /tmp/mountme

total 951712
drwxr-xr-x 6 root wheel 272 Nov 27 16:31 .
drwxrwxrwt 30 root wheel 1020 Dec 19 16:13 ..
-rw-r--r-- 1 root wheel 328 Nov 27 16:31 AppleDiagnostics.chunklist
-rw-r--r--@ 1 root wheel 2943304 Nov 27 15:49 AppleDiagnostics.dmg
-rw-r--r-- 1 root wheel 1984 Nov 27 16:31 BaseSystem.chunklist
-rw-r--r--@ 1 root wheel 484320396 Nov 27 15:50 BaseSystem.dmg

I never even considered that a .pkg could be passed to hdiutil as a disk image - no idea how to rebuild the modified package that way. At least at first glance, they look the same in Pacifist.

The workaround seems to be to run replaceRecovery by hand passing it the correct .dmg in the environment variable, to update the recovery partition, then run the full installer - and that seemed to be absolutely required for me. But still, it sure would be good to know how to correctly rebuild the .pkg so it can be processed the same as the original Apple one (and see if it fails on dm...).

Thanks again for doing that. So, at least we now know that trying to "hdiutil attach" a modified pkg (modified per the instructions in the OP) fails. Like you, I have no idea why and don't know anywhere near enough to try and fix it. If the clever people are still following this thread (and haven't all gone to Mojave) then maybe one of them will know. If they care enough. Clearly, some don't care about the recovery partition, and its update, anymore - personally, even if it's a kludge I'd rather see an installation run to completion so that all the loose ends are tied up.

I am curious about one thing you said though: in your "original failure", did you not have to edit the App Store update pkg to get past the supported platform check? Or were you referring to your manual update of the recovery partition only?

BTW, I agree with your conclusion of how to perform the update error free. "We" should document that - and possibly try and get it added to the OP.

 

[Squirrels Everywhere]

Thanks again for doing that. So, at least we now know that trying to "hdiutil attach" a modified pkg (modified per the instructions in the OP) fails. Like you, I have no idea why and don't know anywhere near enough to try and fix it. If the clever people are still following this thread (and haven't all gone to Mojave) then maybe one of them will know. If they care enough. Clearly, some don't care about the recovery partition, and its update, anymore - personally, even if it's a kludge I'd rather see an installation run to completion so that all the loose ends are tied up.

I am curious about one thing you said though: in your "original failure", did you not have to edit the App Store update pkg to get past the supported platform check? Or were you referring to your manual update of the recovery partition only?

BTW, I agree with your conclusion of how to perform the update error free. "We" should document that - and possibly try and get it added to the OP.

I'm using the patcher from dosdude1.com (as I assume you are?). He's done some magic that takes care of the platform check and makes both the App Store and the installer happy. I've been running it this way since Sierra. Until now, I've never had an issue installing anything directly from the App Store. I've never had to download the standalone installer.

Besides the pkg/hdiutil thing, I haven't figured out why dm thought it had to create a new recovery partition when I did the original install, but when I ran dm or replaceRecovery by hand specifying the .dmg instead of .pkg, it knew it didn't need to create or resize the recovery partition. The app store install does the reboot-to-install thing. Maybe something different in the environment? IDK. I did not try to run the app store installer after manually updating the recovery partition, just used the standalone installer then - I didn't want to take a chance on having to restore a fourth time if it failed again. Probably should have tried that, but by then just wanted to get it fixed.

 

[mrploppy]

I'm using the patcher from dosdude1.com (as I assume you are?). He's done some magic that takes care of the platform check and makes both the App Store and the installer happy. I've been running it this way since Sierra. Until now, I've never had an issue installing anything directly from the App Store. I've never had to download the standalone installer.

Besides the pkg/hdiutil thing, I haven't figured out why dm thought it had to create a new recovery partition when I did the original install, but when I ran dm or replaceRecovery by hand specifying the .dmg instead of .pkg, it knew it didn't need to create or resize the recovery partition. The app store install does the reboot-to-install thing. Maybe something different in the environment? IDK. I did not try to run the app store installer after manually updating the recovery partition, just used the standalone installer then - I didn't want to take a chance on having to restore a fourth time if it failed again. Probably should have tried that, but by then just wanted to get it fixed.

Yes, I use @dosdude1's patcher to install major and minor updates e.g. High Sierra, or Sierra before that, and their incremental updates to 10.13.6. I tend to use the Combo Updates. However, I always use the method outlined in the OP for security updates and supplemental updates. Makes me wonder why it's described in the OP if it's possible to update directly from the App Store.

 

[ScooterComputer]

Ahhh... I looked closer at my original failure log. Now I'm with you. My original failure was an install from App Store, unmodified pkg - got past the mount and failed on the "dm". Your original failure was using a modified standalone pkg file, which failed on the mount, before it got to dm. I am seeing the same (or at least similar) failure as you trying to mount the modified pkg:

$ /usr/bin/hdiutil attach -nobrowse /tmp/SecUpd2018-003HighSierra.Modified.pkg -mountpoint /tmp/mountme

hdiutil: attach failed - image not recognized

$ hdiutil attach -nobrowse /Volumes/Security\ Update\ 2018-003/SecUpd2018-003HighSierra.pkg -mountpoint /tmp/mountme

Checksumming Protective Master Boot Record (MBR : 0)…

According to the hdiutil man page, the attach option "attempts to intelligently verify images that contain checksums before attaching them." I'm wondering if in the creation of the modified pkg, that needed checksum is not being recreated, with a command-line option. You could attempt to replace hdiutil with with hdid (which does NOT, by default, perform the verify) if you can find the calling script. But I'm betting that is "built-in". Alternatively, need to figure out how to create a valid checksum on the modified pkg.

Wow I really wish I had a 2010 Mac Pro to more easily monkey with this stuff!

 

[mrploppy]

According to the hdiutil man page, the attach option "attempts to intelligently verify images that contain checksums before attaching them." I'm wondering if in the creation of the modified pkg, that needed checksum is not being recreated, with a command-line option. You could attempt to replace hdiutil with with hdid (which does NOT, by default, perform the verify) if you can find the calling script. But I'm betting that is "built-in". Alternatively, need to figure out how to create a valid checksum on the modified pkg.

Wow I really wish I had a 2010 Mac Pro to more easily monkey with this stuff!

I daresay you're right - I'd guess it's either a checksum or signature or something like that.

We know the calling script - it's called replaceRecovery, and it's the one I modified to exclude the hdiutil and dm completely (just to get the installer to run to completion).

Update: not really an update, just me thinking to myself about this. As interesting as it is, it may all be moot because there may never ever be another update to High Sierra. Pretty certain that there'll never be any more system updates, so it'll only ever be security updates from now on. And there may be none - or am I being naive?

 

[L Caputo]

Yes, I use @dosdude1's patcher to install major and minor updates e.g. High Sierra, or Sierra before that, and their incremental updates to 10.13.6. I tend to use the Combo Updates. However, I always use the method outlined in the OP for security updates and supplemental updates. Makes me wonder why it's described in the OP if it's possible to update directly from the App Store.

Many people were keen to learn of a way to install standalone updates if they were having problems with the App Store or were wanting to install updates to multiple Macs, and preserve their data allowance. Handy to have the updates around in case you need to re install, etc.
Alrighty.

 

[mrploppy]

Many people were keen to learn of a way to install standalone updates if they were having problems with the App Store or were wanting to install updates to multiple Macs, and preserve their data allowance. Handy to have the updates around in case you need to re install, etc.
Alrighty.

Yes, of course.

 

[j2048b]

so i got my 2008 mac pro 3.1 wanting to upgrade it but need to know if i first need to install sierra and then os high sierra? or can i just use the info here and upgrade to high sierra and press on from there?

 

[j2048b]

So i tried to boot from my usb to do this update and it is stuck showing an apple and full bar along the bottom, is that normal?

 

[DeltaMac]

So i tried to boot from my usb to do this update and it is stuck showing an apple and full bar along the bottom, is that normal?

You didn't say which OS X system you are trying to boot. If it is Sierra or High Sierra, then you should re-check booting on an older installer, such as El Cap, or even Lion.
Does your MPro boot to a system that you know it supports? Try booting to an El Capitan install, or even Lion.
If it won't boot to Sierra, but WILL boot to El Capitan, or something older, then your Sierra bootable installer may be miscofigured, so you should try redoing that installer USB.

 

[j2048b]

You didn't say which OS X system you are trying to boot. If it is Sierra or High Sierra, then you should re-check booting on an older installer, such as El Cap, or even Lion.
Does your MPro boot to a system that you know it supports? Try booting to an El Capitan install, or even Lion.
If it won't boot to Sierra, but WILL boot to El Capitan, or something older, then your Sierra bootable installer may be miscofigured, so you should try redoing that installer USB.

Im on el capitain, trying to boot to os high sierra on the usb to do the upgrade as dosedude explained but also never tried to make a boot disk or in this case a usb,

Ok cool ill see about that, i followed dosdudes instructions from his web site, and it just wouldnt work for me, then my computer went back to flashing ot a and ot b again on the logic board, and shut down so now i need to find out if its the logic board or power supply or ehat ever it could.possibly be

 

[Cisto1983]

Hi guys,
I'm experiencing some problems with my iMac 9,1 (C2D 2,93/8GB/480GB SSD/GT120, on High Sierra since almost a year now) and I can't really quite understand the reason. The machine often freezes, usually when waking up from sleep (the fans start spinning, but the screen won't turn on; the leds on the apple usb keyboard don't turn on as well), but sometimes it also freezes during operation, without any particularly replicable steps (with or without disk activity, with or without high cpu usage, etc etc).
I tried do read the diagnostic logs, but I'm not able to understand why... nothing is striking out as an obvious reason. Is somebody willing to help me?

 

[sda2012]

Hello, i just have succefully installed 10.13.6 on my 4.1 mbp early 2008. The only issue that I have is the right click (2 finger gesture) that is not working.. but 3 finger gestures are.

Is there a fix for that? is very anoying not to have the right click with the gesture. Any help will be apreciate.

 

[jhowarth]

I daresay you're right - I'd guess it's either a checksum or signature or something like that.

We know the calling script - it's called replaceRecovery, and it's the one I modified to exclude the hdiutil and dm completely (just to get the installer to run to completion).

Update: not really an update, just me thinking to myself about this. As interesting as it is, it may all be moot because there may never ever be another update to High Sierra. Pretty certain that there'll never be any more system updates, so it'll only ever be security updates from now on. And there may be none - or am I being naive?

Is it correct to assume that these Security Update 2018-03 failures in the recovery update scripts won't occur if you haven't installed the Recovery Partition patch?