macOS 11 Big Sur on Unsupported Macs Thread

[Alex-Microsmeta]

Someone here was saying that BigSur Public beta was not still available... Why? I have read that finally it is imminent.

macOS Monterey public beta release date

The macOS developer beta gets relased at WWDC, but if you're wondering when the macOS Monterey public beta will show up you're not alone!

www.macworld.co.uk

 

[MacPeet]

ps Have you tried booting your kc with broken LegacyUSB in 'Cmd-S; exit'? Does that bring the legacy usb support back?

I can only boot with cmd-s and exit. Otherwise no keyboard.

Kmutil delivers all tests in S / L / E:

... LegacyUSBInjector.kext ... (mach-o UUID changed from <unknown> to <unknown>) #(no UUID)

Trials in L / E:

macOS wants to load Kext's automatically from L / E





with kmutil load ... so far no success


This attempt breaks the AuxiliaryKernelExtensions.kc (KP at boot):

Last login: Mon Jul 27 16:41:32 on console
peet@Pro-von-Peet ~ % sudo -s
Password:
root@Pro-von-Peet ~ # sudo mount -uw /
root@Pro-von-Peet ~ # killall Finder
root@Pro-von-Peet ~ # cd /Library/Extensions
root@Pro-von-Peet Extensions # sudo chmod -R 755 AAAMouSSE.kext
root@Pro-von-Peet Extensions # sudo chown -R root:wheel AAAMouSSE.kext
root@Pro-von-Peet Extensions # sudo chmod -R 755 LegacyUSBInjector.kext
root@Pro-von-Peet Extensions # sudo chown -R root:wheel LegacyUSBInjector.kext
root@Pro-von-Peet Extensions # sudo chmod -R 755 LegacyUSBVideoSupport.kext
root@Pro-von-Peet Extensions # sudo chown -R root:wheel LegacyUSBVideoSupport.kext
root@Pro-von-Peet Extensions # sudo touch /System/Library/Extensions && sudo touch /Library/Extensions && sudo kextcache -u /
Executing: /usr/bin/kmutil install --volume-root / --check-rebuild
rebuilding local auxiliary collection
kmutil done
root@Pro-von-Peet Extensions # kmutil install --update-all
checking collections...
updated extension 'com.softraid.driver.SoftRAID' found in collection 'auxiliary kext collection' (mach-o UUID changed from <unknown> to 58844C00-8FB7-3DE4-84CC-F023DAD09DC6)
updated extension 'com.Areca.ArcMSR' found in collection 'auxiliary kext collection' (mach-o UUID changed from <unknown> to 05FBCBFC-1AE6-3BF9-BD0F-7655CC822E34)
updated extension 'com.promise.driver.stex' found in collection 'auxiliary kext collection' (mach-o UUID changed from <unknown> to AE253556-66D8-38D2-B9D1-179B78F29153)
updated extension 'com.CalDigit.driver.HDPro' found in collection 'auxiliary kext collection' (mach-o UUID changed from <unknown> to 7AB5C9DC-46D9-2868-5660-CE03CD4950C7)
updated extension 'com.ATTO.driver.ATTOExpressSASHBA2' found in collection 'auxiliary kext collection' (mach-o UUID changed from <unknown> to 6B01EE8B-9786-614A-7E03-D14C16EE2646)
updated extension 'com.Accusys.driver.Acxxx' found in collection 'auxiliary kext collection' (mach-o UUID changed from <unknown> to 105F22C2-A690-33E0-BEB2-F65D14857FC3)
updated extension 'com.ATTO.driver.ATTOCelerityFC8' found in collection 'auxiliary kext collection' (mach-o UUID changed from <unknown> to C88E0E7A-8F11-57D8-10EB-D83BD64E529E)
updated extension 'com.highpoint-tech.kext.HighPointIOP' found in collection 'auxiliary kext collection' (mach-o UUID changed from <unknown> to 2795A2E4-27BC-333B-BE4D-EA04D25270EE)
updated extension 'com.highpoint-tech.kext.HighPointRR' found in collection 'auxiliary kext collection' (mach-o UUID changed from <unknown> to A0C06D9F-5C9F-39E2-BA85-8720A8FF5BA6)
updated extension 'com.ATTO.driver.ATTOExpressSASRAID2' found in collection 'auxiliary kext collection' (mach-o UUID changed from <unknown> to 09E2D3CD-9959-56F9-15D9-620C7B7CCCE1)
rebuilding release collections: boot, system
rebuilding release collections:
boot kernel collection
system kext collection
rebuilding local auxiliary collection
kmutil done
root@Pro-von-Peet Extensions # kcditto
Copying deferred prelinked kernels in /...
Copying KCs in /...
System Volume UUID: 04B4AE28-DBBC-4688-B059-478B82368A04
Volume Group UUID: D43F0965-5761-46C2-803B-EC0B3E597476
Preboot disk: /dev/disk7s2
Preboot volume: /System/Volumes/Preboot
Copying: /System/Library/KernelCollections/BootKernelExtensions.kc.elides -> /System/Volumes/Preboot/D43F0965-5761-46C2-803B-EC0B3E597476/boot/System/Library/KernelCollections
Copying: /System/Library/KernelCollections/BootKernelExtensions.kc -> /System/Volumes/Preboot/D43F0965-5761-46C2-803B-EC0B3E597476/boot/System/Library/KernelCollections
Copying: /System/Library/PrelinkedKernels/immutablekernel -> /System/Volumes/Preboot/D43F0965-5761-46C2-803B-EC0B3E597476/System/Library/PrelinkedKernels
Copying: /System/Library/PrelinkedKernels/prelinkedkernel -> /System/Volumes/Preboot/D43F0965-5761-46C2-803B-EC0B3E597476/System/Library/PrelinkedKernels
root@Pro-von-Peet Extensions # exit
peet@Pro-von-Peet ~ %

 

[TimothyR734]

I'm still unable to install beta 3, csrutil is disabled,csrutil authenticated-root is disabled yet the install stalls at 12 minutes and then constantly reboots beta 2 no problems this one at the moment is a no bueno ?

which Mac are you trying to install Big Sur to that kind of info would be useful

 

[TimothyR734]

I wonder if this would be useful in Big Sur https://github.com/ProfileCreator/ProfileCreator

 

[iamprabhuantony]

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:

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 .

When to do this? Right before stage 1?

 

[jackluke]

When to do this? Right before stage 1?

Yes, before the stage1 of the USB BigSur Installer that is the "Install macOS" from recovery menu, maybe is also doable from its single user mode, but I am not sure.

 

[jhowarth]

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:

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 .

Those files are on the macOS base volume that is mounted instead of the 'Image Volume'. Anyway, this doesn't work because the installer copies over the existing Basesystem.dmg to use in the second stage of the install so those changes will be lost before they can be used in stage 3 of the installation.

 

[ASentientBot]

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:

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 .

At least in DP2, the seal/snapshot is actually done by ramrod in the ramdisk. Have you confirmed that this method works?

If it does, this is an awesome find and I'll have to reconsider some things I thought I knew...

 

[jackluke]

At least in DP2, the seal/snapshot is actually done by ramrod in the ramdisk. Have you confirmed that this method works?

If it does, this is an awesome find and I'll have to reconsider some things I thought I knew...

Premise that all your methods from patched boot.efi to apfs_systemsnapshot for me worked, the fact is that to unseal volume and disable snapshot sometimes I mix too many methods (example delete snapshot with tmutil or diskutil apfs), but I also checked in BigSur beta 3 BaseSystem.dmg and it's present in this path /Image Volume/usr/libexec/ramrod/ so maybe also moving the ramrod folder to ramrod2 , could skip the snapshot sealing . I guess I'll make another test on next beta 4 .

 

[GSXB]

which Mac are you trying to install Big Sur to that kind of info would be useful

cMP 4.1/5.1
I’ve tried numerous times and it fails three minutes into the the first part of the install then reboots continually
Csrutil is disabled
Csrutil authenticated -root is disabled
My installer is parrotgeek patched
Still no joy

 

[jhowarth]

Premise that all your methods from patched boot.efi to apfs_systemsnapshot for me worked, the fact is that to unseal volume and disable snapshot sometimes I mix too many methods (example delete snapshot with tmutil or diskutil apfs), but I also checked in BigSur beta 3 BaseSystem.dmg and it's present in this path /Image Volume/usr/libexec/ramrod/ so maybe also moving the ramrod folder to ramrod2 , could skip the snapshot sealing . I guess I'll make another test on next beta 4 .

Just to be clear, have you actually used this approach to do an unsealed installation or is this all speculation at this point? I ask because I was thinking we might want to replace the apfs_sealvolume and apfs_systemsnapshot copies with simple scripts that returned 0 as if they had succeeded when called so that the installer exits more gracefully.

 

[TimothyR734]

cMP 4.1/5.1
I’ve tried numerous times and it fails three minutes into the the first part of the install then reboots continually
Csrutil is disabled
Csrutil authenticated -root is disabled
My installer is parrotgeek patched
Still no joy

if you MacBook Pro is a duo core it might need the legacyusb.injector as I think the USB ports are not working

 

[GSXB]

if you MacBook Pro is a duo core it might need the legacyusb.injector as I think the USB ports are not working

It’s a cMP tower not a MacBook
I’ve used the usb installer and used a 20GB partition for an installer all of which fail at the same
part of the process

 

[jhowarth]

if you MacBook Pro is a duo core it might need the legacyusb.injector as I think the USB ports are not working

I believe this is supposed to mean a MacPro 4.1 which has been flashed to the 5.1 firmware.

 

[GSXB]

Yes that’s correct
I’ve installed beta 2 no problems at all
Even got the wireless working
Beta 3 has me stumped

 

[jackluke]

Those files are on the macOS base volume that is mounted instead of the 'Image Volume'. Anyway, this doesn't work because the installer copies over the existing Basesystem.dmg to use in the second stage of the install so those changes will be lost before they can be used in stage 3 of the installation.

With Big Sur installation after the stage1 installer apple scripts copy the BaseSystem.dmg to this path: /Volumes/BigSurLabel Data/macOS Install Data/ , so eventually should be replaced that path with the patched BaseSystem.dmg .

While stage2 copies some other packages to the Preboot BigSur UUID "com.apple.installer" folder.

I guessed that copied the same "Image Volume" to that path, anyway I don't tested directly this method, but eventually on next beta 4 .

 

[TimothyR734]

Yes that’s correct
I’ve installed beta 2 no problems at all
Even got the wireless working
Beta 3 has me stumped

run this in the maOS Big Sur parrot geek's patcher and try I used it but I only have my SIP disabled and nvram boot-args="-no_compat_check" and I install without issues

 

[GSXB]

run this in the maOS Big Sur parrot geek's patcher and try I used it but I only have my SIP disabled and nvram boot-args="-no_compat_check" and I install without issues

Do you mean drag this file into terminal space then drag the installer into terminal and press enter ?

 

[jhowarth]

With Big Sur installation after the stage1 installer apple scripts copy the BaseSystem.dmg to this path: /Volumes/BigSurLabel Data/macOS Install Data/ , so eventually should be replaced that path with the patched BaseSystem.dmg .

While stage2 copies some other packages to the Preboot BigSur UUID "com.apple.installer" folder.

I guessed that copied the same "Image Volume" to that path, anyway I don't tested directly this method, but eventually on next beta 4 .

Ah, so we really don't know how the installer will react to the absence of those two binaries at all.

 

[TimothyR734]

Do you mean drag this file into terminal space then drag the installer into terminal and press enter ?

No just run it in terminal if you made the usb using the parrot geek method

 

[Barry K. Nathan]

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.

I think @testheit also was able to boot with a modified BaseSystem.dmg (post #1760), but my attempts with beta 2 failed. Maybe I copied ASentientBot's 0xffffffff patched boot.efi to the wrong place or some similar mistake, but I was never able to disable root DMG authentication. Even converting BaseSystem.dmg to read-write then back to compressed is enough to make the authentication fail.

I'll try again soon, but I'm not sure if that will be later this week or if it'll be next week. I first want to finish and release v0.0.17 of my patcher (with a fix for the beta 3 Ethernet problems), and after that, I might work on fixing various issues with my patcher (for another release later in the week) before returning to the issue of disabling root DMG authentication.

 

[jhowarth]

I decided to give Hax3 a try. I went into the Source subdirectory, opened HaxWrapper.applescript in the Script Editor to have the line that launches the bundle as...

set libName to "HaxLib.dylib"
set targetBundle to "Install macOS Big Sur Beta.app"

to crash(message)
    display dialog message with icon stop with title "Error" buttons {"Stop"} default button 1 cancel button 1
end crash
to warn(message)
    display dialog message with icon caution with title "Warning" buttons {"Stop", "Continue"} default button 1 cancel button 1
end warn

do shell script "csrutil status"
if result does not contain "disabled" then
    warn("SIP seems to be enabled.")
end if

set bootArgs to (do shell script "nvram boot-args")
if bootArgs does not contain "-no_compat_check" then
    warn("-no_compat_check doesn't seem to be set.")
end if

if bootArgs does not contains "amfi_get_out_of_my_way" then
    warn("amfi_get_out_of_my_way doesn't seem to be set.")
end if

try
    do shell script "open -b " & targetBundle
on error
    crash("Can't open the installer app.")

However, when I execute Build.tool and copy the resulting Hax3.app into the Applications directory along side the full installer for Beta 3 named "Install macOS Big Sur Beta", clicking on the Hex3 app produces an error "Can't open the installer app.". What am I missing here?

Update: It appears that using...

set targetBundle to "Install\\ macOS\\ Big\\ Sur\\ Beta.app"

and

do shell script "open -a " & targetBundle

works. Still waiting for the install to complete to confirm the resulting volume is unsealed.

 

[ggyenyen]

I'm still unable to install beta 3, csrutil is disabled,csrutil authenticated-root is disabled yet the install stalls at 12 minutes and then constantly reboots beta 2 no problems this one at the moment is a no bueno ?

I managed to install beta 3 on my macpro 5,1 (flashed 4,1 mid 2009) using parrot geeks method. Didn’t have to use any terminal commands and just let the installer do it’s own thing. Worked a dream. Everything works as it should.

 

[RogueB]

Just an update on Big Sur Beta 3 installation on MacBook Pro 5,2 (Penryn C2D). Most of the "fixes" used to install Big Sur beta3 were courtesy of jackluke and Asentientbot, but there are many other individuals involved in this endeavor.

Reinstalled Big Sur beta 3 on the internal drive of my machine (from separate partition on same internal drive). I applied all the necessary modification, as noted in this thread, with near-total success.

WiFi is fully functional
Sound and microphone are functional.
Frame buffer appears to be active.
"light" mode works; all icons on right side of menu-bar are visible.

However, the modified NVDA drivers do not appear to load; there is no brightness control, nor do function keys allow for change in light intensity. The display control panel has a generic "look" and no visible controls.

I tried to manually to insert a modified NVDAResmanTesla.kext directly into extension folder, using jackluke's method, as described in post 1781 (page 72), but on reboot a kernel panic occurred; trace back showed the NVDAResmanTesla to be the part of the problem. I had to reinstall the Big Sur 3.

Currently:

kextstat | grep NVDA output:

118 0 0xffffff7f8441f000 0x3000 0x3000 com.apple.nvidia.NVDAStartup (16.0.0) B7E8FE3A-5A44-3EA0-9A3B-345B583BFF31 <13 5 3>

The "prelinkedkernel" =26 MB

Is there a pathway to resurrect display control panel, including brightness control?

Thank you for any pointers.

 

[Barry K. Nathan]

Just noticed that on BigSur beta 3 Siri changed the wave animation (it's a vortex now) for Metal GPU, so it doesn't work more on non-Metal GPU (I know it's weird but Siri.app requires some kind of video acceleration to work properly), but Siri till BigSur beta 2 worked on non-Metal GPU because she used the previous wave animation, now the issue are to replace Siri coreservices or frameworks, but where are the Siri frameworks unix exec ? On frameworks and privateframeworks there are only aliases for them.

It's that thing again where all the frameworks are lumped into a single dyld cache. (Even for people who have seen this blog post already, there have been some links added to it, including one earlier today, so it may be worth looking at again.)

Michael Tsai - Blog - Reverse Engineering macOS 11.0