That only works from the recovery partition which doesn't exist for unsupported machines (or legacy usb). Until that gets solved, it will be hard to properly test 'kmutil' for unsupported machines because 'kmutil install --update-all' looks for the kext that are loaded specifically for that machine. So if you do that from the recovery partition on a supported machine and move the drive over, the resulting kc will have the wrong set of kexts.
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 11 Big Sur on Unsupported Macs Thread
- Thread starter dosdude1
- WikiPost WikiPost
- Start date
-
- Tags
- 10.16 macos unsupported
- Sort by reaction score
- Status
That only works from the recovery partition which doesn't exist for unsupported machines (or legacy usb). Until that gets solved, it will be hard to properly test 'kmutil' for unsupported machines because 'kmutil install --update-all' looks for the kext that are loaded specifically for that machine. So if you do that from the recovery partition on a supported machine and move the drive over, the resulting kc will have the wrong set of kexts.
@jackluke thanks a lot!!
The stage 3 skip during the re-install of beta 3 over a sealed volume worked and inhibited the sealing of the volume.
To prevent the macOS Installer (still on nvram at this point) from sealing the volume on reboot, I selected a different partition in Disk Startup.
As for my other device that got re-sealed from running an APFS TM backup, I followed the apfs_systemsnapshot method you suggested and snapshot booting is now off (I think) as the system booted with a writable root (‘/‘)
Again, thanks!
"kmutil load -p" is how installers install or update kexts when booted into Big Sur.
Installing a Custom Kernel Extension | Apple Developer Documentation
Install kernel extensions using a custom installer package, and help users understand the installation process.
"kmutil load -p" doesn't work well for developing kexts because it only works if the version number changes.
"kmutil load -p" is how installers install or update kexts when booted into Big Sur.
Installing a Custom Kernel Extension | Apple Developer Documentation
Install kernel extensions using a custom installer package, and help users understand the installation process.developer.apple.com
"kmutil load -p" doesn't work well for developing kexts because it only works if the version number changes.
When I try to execute "kmutil load -p' from a normal boot of Big Sur, an error appears that a kernel service couldn't be contacted. My assumption is that the kernel service that it is trying to contact only runs under recovery mode.
Wow... What a complex method! Thanks for the very comprehensive and informative reply.
Yes - for these very old machines it is more complex, and there are fewer install options because of the legacy USB restriction.
On the other hand, some of the steps are needed only once. Once a working BS with user data etc is installed, a new version can be installed over it with Hax3 and prelinkedkernel fix.
Critical are the need to hook the BS disk on SATA for installation, and the lack of full graphics acceleration.
But solutions were found by our heroes in the Catalina case, where it looked unlikely in the beginning. Meanwhile it is running so well and so stable that I could happily keep it for a few more years!
BS is still in a very early phase.
About the "apfs_systemsnapshot" I guess if you remove it, after you have a working "sudo mount -uw /", from /System/Library/FileSystems/apfs.fs/Contents/Resources/
this should prevent any new snapshot tagging for booting .
But I guess I found another way to prevent the apfs_sealvolume without waiting the stage2 or stage3 , since I noticed that annoying exec is only present on a BigSur BaseSystem.dmg (Recovery environment), so making a patched BaseSystem.dmg without it should work to make an USB Big Sur installation unsealed without snapshot booting.
Note: "USB BigSur Installer" currently only work from recent IOUSB APFS firmware machines
Code:
cd /Volumes/USBInstallerBigSur/BaseSystem/
hdiutil attach -owners on BaseSystem.dmg -shadow
Customize (directly from Finder) "BaseSystem.dmg mounted" removing the "apfs_sealvolume" and "apfs_systemsnapshot" unix exec from its path
hdiutil detach /dev/diskX (or eject/unmount the "MacOS Base System" volume from Finder)
hdiutil convert -format UDZO -o BaseSystem2.dmg BaseSystem.dmg -shadow
mv BaseSystem.dmg BaseSystembackup.dmg
mv BaseSystem2.dmg BaseSystem.dmg/Volumes/macOS Base System/System/Library/FileSystems/apfs.fs/Contents/Resources/
(thanks to @ASentientBot for the hint where the BigSur apfs unix exec are located)
renaming that apfs_sealvolume in apfs_sealvolume2
renaming also apfs_systemsnapshot in apfs_systemsnapshot2
and making a patched BaseSystem.dmg should work to make an USB Big Sur installation unsealed without snapshot booting.
for using and booting the patched BaseSystem.dmg (without root dmg verification) is required also the ASentientBot patched boot.efi to replace here: /Volumes/USBInstallerBigSur/System/Library/CoreServices/
this eventually could be a method to make an unsealed BigSur Patcher .
edit:
an alternate method using the stock BigSur BaseSystem.dmg:
https://forums.macrumors.com/thread...unsupported-macs-thread.2242172/post-28713639
Last edited:
That certainly seems more viable than the 'apfs_systemsnapshot' hack which relies on buggy behavior in that program when passed '-r ""'. IMHO, we really want to steer clear of any approach that relies on macOS bugs since that effectively is jailbreaking and those loopholes are certain to be closed.
Last edited:
I try to make installer b3 when i formated usb Stick as an APfS bootable disk using Disk Utility is fail to make installer..? what wrong ?. Can I make installer with Extended Journal like beta 2 ?(pic;process use extended Journal formated)
MBP2012 13"
Attachments
Last edited:
I think that for Macmini2010 (Macmini4,1) Core 2 Duo Penryn AppleHDA.kext ~snapshot workaround to fix internal audio don't work (I fear to retry because now Beta 3 works fine and last time I have broken something and was unable to boot anymore). Is there an alternative from BigSur / Catalina recovery Terminal and a specifically patched AppleHDA.kext to try?
It Says boot 0x867.efi.zip, do i need to rename it as boot.efi???
[automerge]1595847971[/automerge]
It Says boot 0x867.efi.zip, do i need to rename it as boot.efi???
[automerge]1595847971[/automerge]
It Says boot 0x867.efi.zip, do i need to rename it as boot.efi???
Yes, rename to boot.efi .
To have a working patched BaseSystem.dmg don't modify its kext or BootKernelExtensions , and to boot any USB BigSur Installer (with patched BaseSystem.dmg) you need a Mac with recent IOUSB that are: MCP89 Nvidia Chipset, Intel Sandy Bridge and Ivy Bridge architecture.
MCP79 Chipset currently is not supported to boot the USB BigSur Installer due to legacy usb .
You also might need
nvram boot-args="-no_compat_check" (even if I used a patched com.apple.Boot.plist too for that).
Last edited:
OSXBS B3 MBP2012 13" install like parrotgeek success but no wifi when i try failed 66...batery info error...and the macbook pro info is empty..status delete
Do you see this behavior when trying to recreate the BaseSystem.dmg?
Code:
% cd "Install macOS Big Sur Beta"
% cd BaseSystem
% hdiutil attach -owners on BaseSystem.dmg -shadow
Checksumming Protective Master Boot Record (MBR : 0)…
Protective Master Boot Record (MBR :: verified CRC32 $1FDBB1FA
Checksumming GPT Header (Primary GPT Header : 1)…
GPT Header (Primary GPT Header : 1): verified CRC32 $CEBC6AEB
Checksumming GPT Partition Data (Primary GPT Table : 2)…
GPT Partition Data (Primary GPT Tabl: verified CRC32 $9424613B
Checksumming Untitled 1 (Apple_APFS : 3)…
..............................................................................................................................................
Untitled 1 (Apple_APFS : 3): verified CRC32 $EDA3484E
Checksumming GPT Partition Data (Backup GPT Table : 4)…
GPT Partition Data (Backup GPT Table: verified CRC32 $9424613B
Checksumming GPT Header (Backup GPT Header : 5)…
GPT Header (Backup GPT Header : 5): verified CRC32 $EFA128C9
verified CRC32 $B1E22942
/dev/disk5 GUID_partition_scheme
/dev/disk5s1 Apple_APFS
/dev/disk6 EF57347C-0000-11AA-AA11-0030654
/dev/disk6s1 41504653-0000-11AA-AA11-0030654 /Volumes/macOS Base System
/dev/disk6s2 41504653-0000-11AA-AA11-0030654 /Volumes/PrebootAfter removing apfs_sealvolume, I see this warning when ejecting
Code:
% hdiutil detach /dev/disk6
hdiutil: couldn't eject "disk5" - Resource busyThis is for a disk layout that has...
Code:
/dev/disk5 (disk image):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme +2.2 GB disk5
1: Apple_APFS Container disk6 2.2 GB disk5s1
/dev/disk6 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +2.2 GB disk6
Physical Store disk5s1
1: APFS Volume macOS Base System 1.9 GB disk6s1
2: APFS Volume Preboot 131.3 MB disk6s2Yes, that behaviour, try eject the "macOS Base System" from Finder, or maybe use
sudo hdiutil detach /dev/disk6 or diskutil unmount disk6s1 (and disk6s2)or eject those disk images from DiskUtility app .
Maybe if can't eject correctly, retry those steps from Catalina.
This is under Catalina. I've tried both manually ejecting the BaseSystem volume from the Finder as well as 'sudo hdiutil detach /dev/disk6'. The problem seems to be that this leaves the disk5 with the container for disk6 in place as well as the shadow files. If I don't also manually execute 'sudo hdiutil detach /dev/disk5', then when I try to execute 'hdiutil convert -format UDZO -o BaseSystem2.dmg BaseSystem.dmg -shadow' I get an error about a file being present (which I assume is the shadow file).
Also, don't you also need to replace the boot.efi in the Preboot partition of the BaseSystem.dmg?
Last edited:
First make sure you have
csrutil disable , because apple won't let you touch BaseSystem or Preboot volumes otherwise, then delete the shadow file, and retry those commands typing before: sudo -s , after you made the patched BaseSystem.dmg you can delete its shadow file.Hi, thanks for your reply. I solved this issue, which apparently depended on Kaspersky Internet Security (as soon as I uninstalled it, I was able to connect to the Internet again). I am now facing a new problem: when I reboot into the Big Sur installer in order to fix the wifi (step 9 of the procedure), the installer doesn't accept my password and I have to quit. I'm 100% sure that the password is correct (when I reboot into the system I can login with no issue)... any hints?
Last edited:
Has anyone besides jackluke got this to work? I have used 'csrutil disable' and followed the steps to mount BaseSystem.dmg, remove the apfs_sealvolume binary, replace the boot.efi in the mounted Preboot from the original BaseSystem.dmg and recreate it. After also replacing the boot.efi on the usb installer, I am finding that booting the usb installer resulted in a failed boot.
Try replacing also the boot.efi on the Preboot of the BaseSystem.dmg and on the macOS Base System/System/Library/CoreServices/ and /usr/standalone/i386/
also set on /Volumes/USBInstallerBigSur/Library/Preferences/SystemConfiguration/com.apple.boot.plist
Code:
<key>Kernel Flags</key>
<string>root-dmg=file:///BaseSystem/BaseSystem.dmg -no_compat_check amfi_get_out_of_my_way=1 cs_enforcement_disable=1</string>Anyway I made that patched BaseSystem.dmg directly from BigSur, so maybe it manages differently those APFS Ramdisk volumes.
Last edited:
Thanks for the patcher tool. Worked perfectly on my late 2013 iMac i7. Even seems to have working wifi. Great work!
To those who attempted to make a custom BigSur BaseSystem.dmg to remove the apfs_sealvolume and can't boot from BaseSystem (BigSur Recovery environment), then try this other method, using the stock BigSur BaseSystem.dmg , boot from the USB Big Sur Installer, then open a recovery terminal and type:
This should skip the system sealing and snapshot booting, because if I don't get wrong that "Image Volume" (that is the BaseSystem.dmg mounted) is also used for the stage2 com.apple.installer .
Code:
mount -uw /
cd /Volumes/Image\ Volume/
cd System/Library/Filesystems/apfs.fs/C*/R*/
mv apfs_sealvolume apfs_sealvolume2
mv apfs_systemsnapshot apfs_systemsnapshot2
close terminal, and continue the installer .This should skip the system sealing and snapshot booting, because if I don't get wrong that "Image Volume" (that is the BaseSystem.dmg mounted) is also used for the stage2 com.apple.installer .
Last edited: