How does one patch something the traditional way? I haven't been able to find anything on the internet about this
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
macOS 10.15 Catalina on Unsupported Macs
- Thread starter 0403979
- WikiPost WikiPost
- Start date
- Sort by reaction score
- Status
That's great! I was thinking about upgrading the card, but since I use only bluetooth on my cMP 4,1->5,1 I think I'll just keep using the one I have.
dd has a similar function, which has been added quite a while ago and it's the
status=progress
option.
So you'd just have to do something like
dd if=/dev/xxx of=/dev/xxx bs=4096 status=progress
EDIT: actually, it looks like the dd included in High Sierra is *very* old. Not the end of the world, just install coreutils from brew and you're good to go.
brew install coreutils
gdd if=/dev/xxx of=/dev/xxx bs=4096 status=progress
notice the "g" at the beginning to specify the GNU version.
Attachments
Last edited:
NO, you will risk two times to brick your MacbookPro:
1) Using Clover bootloader on a real Mac is very dangerous it will patch on-the-fly the EFI EEPROM SMC injecting something
2) Assuming you will able to spoof your Mac as a supported Catalina machine, then it will do a EFI firmare update totally incompatible with your Mac
In both cases the risk to brick your machine is very high!
Ok Thank you for the information, I just really want to try out Catalina but don't know where to start, I see alot of people saying they got it working on their devices, but with no information on how patch these files for yourself
I posted here about how I got it installed on a 2010 MacBook without access to a supported Mac. Some others have had success with a VM. The simplest method is probably to clone from a supported computer, but I haven't tried that.
Agreed, I was just typing an alternative very similar way:
- Download the "Install macOS 10.15 beta.app" (6,5 gb)
- Show its packages Contents/SharedSupport/
- Take the BaseSystem.dmg apart and restore it on an empty (at least 10 gb) USB drive or disk partition
- Copy from Contents/SharedSupport/ these files in the root of your "Restored BaseSystem.dmg" USB drive:
AppleDiagnostics.chunklist, AppleDiagnostics.dmg, BaseSystem.chunklist and BaseSystem.dmg
(You need also another BaseSystem.dmg copied inside the USB "restored Basesystem.dmg" otherwise will fail during installation)
- Now from Contents/SharedSupport/ open/mount the InstallESD.dmg and copy (from Finder) the Packages (overwriting the Packages.alias) folder into your USB (restored BaseSystem) /System/Installation/
(this will take a while)
- Go to /System/Installation/Packages/ and you should or patching the Distribution inside or "downgrade" the OSInstall.mpkg, as @ASentientBot rightly suggested an HighSierra one is good since you have a MBP 2011 that is HighSierra natively supported
Meanwhile on your MacBookPro you have to set from a Terminal Shell nvram boot-args="-no_compat_check"
Reboot and boot targeting this USB Drive, format as or use as target install disk one with APFS and it should install.
Last edited:
Ditto. Those are Hackintosh tools, be careful.
Automated patchers and installers are on the way. Many of us created Catalina boot USB sticks with supported machines, then manually patched our sticks to make them boot on our unsupported machines. Sorry but the steps are a little daunting if you haven't done this type of thing before OR aren't comfortable with the Mac Terminal. I would recommend waiting a bit until nicely packaged images are available with instructions OR a custom patcher is released. You can also retrace our steps since page 1, if you are so inclined, it's all buried in there. Sorry, things may become easier soon...
EDIT: didn't realize @jacluke and @ASentientBot responded. They describe alternate valid workflows. Good luck.
I haven't really delved into it before but I wish to learn
Many Swift frameworks use C for low level stuff and raw speed. Perfect web server does this for SSL and HTTP and one other lib. It is the fastest Swift web server, and it’s also faster than Node.js
You can also run Obj-C and Swift in the same app, except for SwiftUI.
My swift framework that I made to stream HLS data can probably work wirh and Obj-C client. Just haven’t tried it.
Two schools of thought.
Audio frameworks in real time are better with C. Swift alone is not fast enough to do a real time audio tap, but Swift with a Framework that uses C is.
Many ways to skin a Cat(ilina).
[doublepost=1560202694][/doublepost]If anyone wants to do a knowledge share between Swift and Obj-C, I’m all for it.
[doublepost=1560203028][/doublepost]
Back up your data.I already converted my Mojave terminal to Oh My ZSH
NoGiveUp even without acc. Wanna try it on my imac 11.2 pls! -Tell me if i can soldering a metal-ready GPU which one to be fit?
Best Luck @dosdude & All Teammates
Best Luck @dosdude & All Teammates
Last edited:
Figured out a reproduce-able method for creating an image of Catalina dual mode APFS containers to make it easier to move installations quickly. If this guide isn't clear enough let me know and I'll clean it up :
Used Clonezilla Live newest version – filename was clonezilla-live-20190420-disco-amd64.iso. Copied to bootable USB with Etcher / Rufus (make sure it’s GPT partitioned).
1. Clonezilla Live 1024*768, press Enter
2. Start CloneZilla, press Enter
3. Device-image, press Enter
4. Local_dev, press Enter
5. Insert USB to save image to (must be HFS or Xfat, cannot be APFS) wait 5 seconds, press enter
6. If your USB shows on the list, press Ctrl + C to go to the next step
7. Choose your USB drive and partition to save the image to and then press Enter
8. If your drive is HFS, you will get a warning, press Y to continue
9. Choose the folder on the drive to save the image to and press Enter
10. Arrow down to saveparts, then press Enter
11. Choose a new name for the image file or press enter to keep the defaults
12. Choose the source partition (your APFS container that is currently working)
13. Press Enter to choose default priority mode for cloning
14. Press Enter to choose Default Advanced Parameters
15. Arrow down to –Z0 for No Compression and press Enter
16. Add 10 zeros to make sure the file is not split during cloning, then press Enter
17. Press Enter to Skip Source File System Checking
18. Arrow down once to Skip checking the saved image then press Enter
19. Press Enter to not encrypt the image
20. Press Enter to choose shutdown options after cloning
21. You will get a warning about Volume size limit and list of the exact command to run, press Enter
22. Confirm the image information and press Y to continue
23. The Cloning Process will begin, this step took exactly 5 minutes on my machine
24. After cloning a summary will be displayed, press Enter
25. Arrow down to reboot, press Enter
26. Hold the Left Alt key down while rebooting and choose a working Catalina boot device
27. Once booted, find the image file folder you specified in Clonezilla
28. Sort by File Size, the biggest file in the folder should end with img.uncomp.aa
29. Rename the file by removing the uncomp.aa and changing it to .img
30. Now double clicking on the .img file will open it as a usable image in Disk Utility
31. You can now restore to any size drive natively using Disk Utility, all the way down to the size of the used space in the 2 APFS containers that show up, mine was ~ 14.7GB so it fits perfectly on a 16GB USB drive.
32. If you run through the process once more after restoring to a smaller drive you will have a permanent copy shrunk to ~14.7GB
33. When you use Disk Utility to restore the APFS container, it will put both images back correctly and re-enumerate the UUID correctly
34. Confirmed clone ability to External USB drives (multiple) as well as to Internal SSD / Hard drive on any Mac that will boot the Catalina Recovery drive.
Caveats – I had to disable SIP to make all this work, everything worked fine and a reset the PRAM to remove the Verbose boot which turned SIP back on and I had TONS of issues. Turning it back off fixed them instantly.
Also the only Disk Utility that seems to handle Catalina APFS containers is the Catalina version itself. High Sierra did NOT work. I have not tried Mojave yet but plan to test it ASAP.
Used Clonezilla Live newest version – filename was clonezilla-live-20190420-disco-amd64.iso. Copied to bootable USB with Etcher / Rufus (make sure it’s GPT partitioned).
1. Clonezilla Live 1024*768, press Enter
2. Start CloneZilla, press Enter
3. Device-image, press Enter
4. Local_dev, press Enter
5. Insert USB to save image to (must be HFS or Xfat, cannot be APFS) wait 5 seconds, press enter
6. If your USB shows on the list, press Ctrl + C to go to the next step
7. Choose your USB drive and partition to save the image to and then press Enter
8. If your drive is HFS, you will get a warning, press Y to continue
9. Choose the folder on the drive to save the image to and press Enter
10. Arrow down to saveparts, then press Enter
11. Choose a new name for the image file or press enter to keep the defaults
12. Choose the source partition (your APFS container that is currently working)
13. Press Enter to choose default priority mode for cloning
14. Press Enter to choose Default Advanced Parameters
15. Arrow down to –Z0 for No Compression and press Enter
16. Add 10 zeros to make sure the file is not split during cloning, then press Enter
17. Press Enter to Skip Source File System Checking
18. Arrow down once to Skip checking the saved image then press Enter
19. Press Enter to not encrypt the image
20. Press Enter to choose shutdown options after cloning
21. You will get a warning about Volume size limit and list of the exact command to run, press Enter
22. Confirm the image information and press Y to continue
23. The Cloning Process will begin, this step took exactly 5 minutes on my machine
24. After cloning a summary will be displayed, press Enter
25. Arrow down to reboot, press Enter
26. Hold the Left Alt key down while rebooting and choose a working Catalina boot device
27. Once booted, find the image file folder you specified in Clonezilla
28. Sort by File Size, the biggest file in the folder should end with img.uncomp.aa
29. Rename the file by removing the uncomp.aa and changing it to .img
30. Now double clicking on the .img file will open it as a usable image in Disk Utility
31. You can now restore to any size drive natively using Disk Utility, all the way down to the size of the used space in the 2 APFS containers that show up, mine was ~ 14.7GB so it fits perfectly on a 16GB USB drive.
32. If you run through the process once more after restoring to a smaller drive you will have a permanent copy shrunk to ~14.7GB
33. When you use Disk Utility to restore the APFS container, it will put both images back correctly and re-enumerate the UUID correctly
34. Confirmed clone ability to External USB drives (multiple) as well as to Internal SSD / Hard drive on any Mac that will boot the Catalina Recovery drive.
Caveats – I had to disable SIP to make all this work, everything worked fine and a reset the PRAM to remove the Verbose boot which turned SIP back on and I had TONS of issues. Turning it back off fixed them instantly.
Also the only Disk Utility that seems to handle Catalina APFS containers is the Catalina version itself. High Sierra did NOT work. I have not tried Mojave yet but plan to test it ASAP.
if you add those what does that produce?
that looks exciting to me tbh for acceleration
I really don't know as I don't have Catalina up and running but I do know Apple and Nvidia are at odds with each other so maybe that's why they are not included or maybe they do install during the setup process
[doublepost=1560207993][/doublepost]The other thing I noticed is openGL and openCL are in the base system but not openAL which is a cross platform audio package API
I have done this a Mac Pro and it is not recommended. If you pick the wrong reference computer, it can stop your computer from booting and you have to go in and change the startup volume or remove the EFI partition.
And there isn't an EFI partition or volume on APFS Containers. I am sure there is still EFI, it's just not a partition anymore. So you're adding something in front of something instead letting the system use Preboot volume directly that's on APFS.
third, if you need power management kexts for your Motherboard, well, how is it gonna know to load them if the system thinks it's a Mac mini instead of a Mac Pro? Hope that helps.
It's a roll of the dice and I decided to quit doing it as it won't be standard practice on a Mac.
These tricks are ok on VMs and on Hacktintoshes because they natively lack the open firmware needed to boot macOS.
When a patch tool is out, this will be much easier.
I am working on a signed OSInstall file that may help with booting. My object is to return true on any of its error checks. Package it up. compare my packaged file with the original and then hex edit the areas on the signed file to see if it runs and then a native installer would might work without jump through hoops. Others might have gotten this to work already, but I haven't yet on my MP3,1. but by returning true no matter what right away should prevent the OSInstall file from hiccuping. And I'll be using an OSInstall file for that install. Shooting for a 1:1.
[doublepost=1560208795][/doublepost]APFS has an interesting feature that allows clones of a volume or directory that don't require extra space and it only takes up more space when bits are changed. I am not sure if that works across containers, I doubt it, but you should be able to do this:
clone an APFS Volume within the same container instantly. Make backups, modifications, create snapshots, do versioning while taking up nearly the same amount of space. It allows shared bytes that are common.
Here is a brief technote from Apple about it:
https://developer.apple.com/documentation/foundation/file_system/about_apple_file_system
I'll be playing around with it once I get my Mojave install back on a usable drive.
Last edited:
APFS Cloning update / shared data:
I was able to do a quick test in Swift, and I am able to clone volumes instantly between two volumes on the same container. And it does the same with directories on the same volume. No matter how big they are, they are created instantly.
Now for creating volumes, that has to be done separately. But once a volume is created, you can go through its directories recursively:
like /Volume/Home - Data/Devices
to /Volume/Home - Data/Devices
and so on.
so do use the cloning feature, looping over directories will be needed or copy the original to a temp dir and move it once the volume is created.
Next test, clone data between two containers on the same disk and see if the data is shared or if it's independent.
The cloning aspect is interesting on the container, because you could clone the system or data volume, make changes to the main one and if you mess up, you can clone the origin back in an instant.
This could save a lot of time in testing.
Anyone who wants to do their own Swift code and follow along here my starting code:
There is not much to it other than putting some brains behind it. The beauty of this technique is if you clone from HFS+ to APFS directories, it will copy automatically. You won't get the benefits of cloning with shared data but it will just work.
I am gonna do some manual clones with some kext patches and see how it fairs and how well I can revert back from a clone. The ability to do snapshots of a file system is pretty neat. We are talking Nanoseconds of time.
[doublepost=1560213461][/doublepost]@ pkouame: did you post which Kexts you used for your MP3,1? Looking to save a little time. I'll see what the patch tool has if it has anything I can spot.
I was able to do a quick test in Swift, and I am able to clone volumes instantly between two volumes on the same container. And it does the same with directories on the same volume. No matter how big they are, they are created instantly.
Now for creating volumes, that has to be done separately. But once a volume is created, you can go through its directories recursively:
like /Volume/Home - Data/Devices
to /Volume/Home - Data/Devices
and so on.
so do use the cloning feature, looping over directories will be needed or copy the original to a temp dir and move it once the volume is created.
Next test, clone data between two containers on the same disk and see if the data is shared or if it's independent.
The cloning aspect is interesting on the container, because you could clone the system or data volume, make changes to the main one and if you mess up, you can clone the origin back in an instant.
This could save a lot of time in testing.
Anyone who wants to do their own Swift code and follow along here my starting code:
Code:
// Created by Starplayr on 6/10/19.
// Copyright © 2019 Todd Bruss. All rights reserved.
import Foundation
let source = "/Volumes/MyHome - Data/Device" //source
let destination = "/Volumes/MyHome2 - Data/Device" //destination
let fileManager = FileManager() //shared instance is declared once
do {
try fileManager.copyItem(atPath: source, toPath: destination) //new Syntax
} catch {
print(error)
}There is not much to it other than putting some brains behind it. The beauty of this technique is if you clone from HFS+ to APFS directories, it will copy automatically. You won't get the benefits of cloning with shared data but it will just work.
I am gonna do some manual clones with some kext patches and see how it fairs and how well I can revert back from a clone. The ability to do snapshots of a file system is pretty neat. We are talking Nanoseconds of time.
[doublepost=1560213461][/doublepost]@ pkouame: did you post which Kexts you used for your MP3,1? Looking to save a little time. I'll see what the patch tool has if it has anything I can spot.
Last edited:
This makes no sense... if you make any edit to a signed file, the signature is instantly broken.
Then how are users editing the Distribution file and getting that to work?
If it one bit is edited on the .mpkg via a hex editor without decompressing it and recompressing it breaks?
I was thinking the signing would be elsewhere in the file and I didn't think it looked at the bits in the Distribution file. I'll try one character first and see what happens.
Last edited:
When you expand and edit the Distribution file, the signature is removed.
Hex-editing a compressed package would be impractical anyways, and would immediately invalidate the checksum/signature -- that is the point of the signature!
Right but was I am attempting is edit the file. recompress it a mpkg.
compare the two packages.. one part were the signature is it should be obvious. and should the 1 bit I changed.
Guess I will find out. It's a small test anyways.
I really don't understand how others on the MP5,1 are editing the file and getting that work without signing.
How can the signing be turned off or ignored like in the patched installers?
well, I have some other ideas around the APFS cloning, so I may be able to get the installer to run unsigned and create the Data drive separately.
Last edited:
I think I followed everything correctly, but I'm guessing I probably did not, can I added verbose boot argument to see if i could figure out the issue and I am not completely sure what this means. Or what step I missed.
Attachments
Thanks for clarification. Oh well support Mac install and 'dd' it is for now.
And some experimental snapshot cloning of APFS directories for patching.