macOS 11 Big Sur on Unsupported Macs Thread

[macsba]

I think on the previous page I posted an update patch installer try that

Yep, tried your patch but failed. I got the same error as before. Then I tried the sudo command without the the "," and got this error message: "zsh: command not found: sudo,"

This is strange.

 

[TimothyR734]

Yep, tried your patch but failed. I got the same error as before. Then I tried the sudo command without the the "," and got this error message: "zsh: command not found: sudo,"

This is strange.

Are you following the guide on parrotgeek’s website

 

[macsba]

Are you following the guide on parrotgeek’s website

I am.

Will try again tomorrow. Getting tired now. Thank you.

 

[PeterHolbrook]

Then I tried the sudo command without the the "," and got this error message: "zsh: command not found: sudo,"

This is strange.

It depends on the context where you issue "sudo". It the context is, per se, that of an administrator, "sudo" doesn't work, since it isn't needed. For instance, if you boot up using the Recovery HD partition and you launch Terminal, there's no "sudo".

 

[jackluke]

Fantastic catch. Removing LegacyUSBInjector.kext and patching IOUSBHostFamily.kext/Contents/Info.plist instead solved the problems that I was having building prelinkedkernels under snapshots using chroot. Attached is my current recipe for doing that.

Disable authenticated-root in nvram using csrutil from Big Sur from the root level of a patched Catalina usb installer with..

sudo csrutil2 authenticated-csr disable

Also make sure to set...

sudo nvram boot-args="-no_compat_check"

Install Big Sur on an external drive from a supported machine. Attach this drive under Catalina mount it's Preboot volume.

cd /Volumes/Preboot/*/System/Library/CoreServices/
curl https://github.com/jacklukem/BigSurfixes/raw/master/prelinkedkernel%20fix/com.apple.Boot.plist --progress-bar -L -o /private/tmp/com.apple.Boot.plist
sudo cp -a /private/tmp/com.apple.Boot.plist .
curl "https://raw.githubusercontent.com/jacklukem/BigSurfixes/master/legacy%20usb%20prelinkedkernel%20beta1/prelinkedkernel?raw=true" --progress-bar -L -o /private/tmp/prelinkedkernel
sudo mv PlatformSupport.plist PlatformSupport.plist2
sudo cp -a /private/tmp/com.apple.Boot.plist .
cd ../PrelinkedKernels
sudo cp -a /private/tmp/prelinkedkernel .

Attach a usb memory stick with Kext-droplet.dmg and the following kexts files

from Catalina Patchers kext)
AppleHDA.kext
AppleIntelPIIXATA.kext

(from 10.15.5)
IO80211Family.kext

AAAMouSSE.kext v0.93
telemetrap.kext v0.22

Download and uncompress https://forums.macrumors.com/attachments/iousbhostfamily-info-plist-zip.932079/ as IOUSBHostFamily-Info on /Volumes/Untitled

*** commands below remove the incompatible kext ****

mkdir /Users/howarth/mntpoint
sudo mount -o nobrowse -t apfs /dev/disk7s5 /Volumes/BigSur/Users/howarth/mntpoint
cd /Volumes/BigSur/Users/howarth/mntpoint/System/Library/Extensions
sudo rm -fr IO80211Family.kext
sudo rm -fr AppleHDA.kext
sudo ditto /Volumes/Untitled/IO80211Family.kext IO80211Family.kext
sudo ditto /Volumes/Untitled/AppleHDA.kext AppleHDA.kext
sudo chmod -R 755 IO80211Family.kext
sudo chmod -R 755 AppleHDA.kext
sudo chown -R root:wheel IO80211Family.kext
sudo chown -R root:wheel AppleHDA.kext

**** patch LegacyUSBInjector Info.list changes directly into IOUSBHostFamily.kext ***
cd IOUSBHostFamily.kext/Contents
sudo patch -p0 < /Volumes/Untitled/IOUSBHostFamily-Info/Info.plist.diff

cd /Volumes/BigSur/Users/howarth/mntpoint/Library/Extensions
sudo ditto /Volumes/Untitled/telemetrap.kext telemetrap.kext
sudo chmod -R 755 telemetrap.kext
sudo chown -R root:wheel telemetrap.kext

*** commands to rebuild and move new prelinkedkernel to /System/Library/PrelinkedKernels for kcditto to find ***

*** add missing directory ***
sudo mkdir /Volumes/BigSur/Users/howarth/mntpoint/Library/Apple/System/Library/PrelinkedKernels
*** add missing symlink for kextcache -system-prelinked-kernel
sudo ln -s /System/Library/Caches /Volumes/BigSur/Users/howarth/mntpoint/Library/Apple/System/Library/Caches

sudo chroot /Volumes/BigSur/Users/howarth/mntpoint mount -uw /
sudo touch /Volumes/BigSur/Users/howarth/mntpoint/Library/Extensions/
sudo chroot /Volumes/BigSur/Users/howarth/mntpoint kextcache -i /

cd /Volumes/BigSur/Users/howarth/mntpoint/System/Library/PrelinkedKernels
sudo cp /Volumes/BigSur/Users/howarth/mntpoint/Library/Apple/System/Library/PrelinkedKernels/prelinkedkernel prelinkedkernel
sudo cp /Volumes/BigSur/Users/howarth/mntpoint/Library/Apple/System/Library/PrelinkedKernels/prelinkedkernel immutablekernel
cd ~
sudo chroot /Volumes/BigSur/Users/howarth/mntpoint kcditto
sudo bless --folder /Volumes/BigSur/Users/howarth/mntpoint/System/Library/CoreServices --bootefi --create-snapshot

*** reboot to make modified snapshot active root ***

Jakeluke, now that LegacyUSBInjector.kext can be dropped, I wonder if the KCs that kcditto installs along side the prelinkedkernel can be used to boot instead. Any idea how your com.apple.Boot.plist would be changed to use the installed KC instead?

To those who want to remove my "prelinkedkernel fix" and return to the BigSur BootKernelExtensions.kc (or to your updated one) , just use the attached file.

 

[macsba]

It depends on the context where you issue "sudo". It the context is, per se, that of an administrator, "sudo" doesn't work, since it isn't needed. For instance, if you boot up using the Recovery HD partition and you launch Terminal, there's no "sudo".

I'm not booting up in the Recovery partition. I'm in the regular Catalina drive. I'm using the Terminal under Catalina. I'm trying to create a bootable USB drive following ParrotGeek's instructions found here: https://parrotgeek.com/bigsur/

I'll be trying again tomorrow. I'm tired.

 

[vobele]

Updated my unsupported rMBP early 2013 with this patch from BS Beta1 to Beta2! You have to solve the WiFi issue again, if you had it after Beta1 installation.

GitHub - barrykn/big-sur-micropatcher: A primitive USB patcher for installing macOS Big Sur on unsupported Macs

A primitive USB patcher for installing macOS Big Sur on unsupported Macs - barrykn/big-sur-micropatcher

github.com

 

[jackluke]

I think I found a fix for the LegacyUSBInjector flakiness. At least, it worked on my MacBook6,1 -- if I use this instead of the LegacyUSBInjector, then it reliably works, whether I'm using prelinkedkernels or kernelcollections.

Basically, take the Info.plist.new in this zip file and use it to replace /System/Library/Extensions/IOUSBHostFamily.kext/Contents/Info.plist, then rebuild your prelinkedkernel or kernelcollections as usual. (It feels early to call any of this "usual" but hopefully you get the idea.) The zip archive also has a diff file (so it can be applied as a patch against later betas, using the patch command) and a copy of IOUSBHostFamily.kext's unmodified Info.plist from beta 2 (although this was redundant in retrospect, because you can just take the new Info.plist and apply the diff in reverse to get the original).

What I did, essentially, was to inject the injector into IOUSBHostFamily. It's really just a copy-and-paste of ParrotGeek's LegacyUSBInjector for Catalina -- but I figured that embedding it into IOUSBHostFamily would more or less eliminate the chance that it would not get included in the prelinkedkernel or kernelcollection, or the chance that it would not get loaded. It's always possible that my theory is wrong, but on my own MacBook6,1 it seems to be working out so far...

Edit: Oops, accidentally attached the file twice so I deleted one of the duplicates.

Great work in using the "LegacyUSBInjector" with kmutil for a BootKernelExtensions.kc (or KernelCollections), with the MacBook6,1 since it has an Nvidia GeForce Tesla, could you try to add framebuffer video (as you done for IntelHD3000) to your patcher ?

While about your patched IOUSBHostFamily.kext , I have some clues how to attempt to make an USB BigSur Installer with legacy USB (or non-APFS mac), you should override (or instead its BaseSystem's Preboot) the /Volumes/USBInstallerBigSur/Library/Preferences/SystemConfiguration/com.apple.Boot.plist as for example with this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Kernel Cache</key>
    <string>System\Library\KernelCollections\BootKernelExtensions.kc</string>
    <key>Kernel Flags</key>
    <string>root-dmg=file:///BaseSystem/BaseSystem.dmg -no_compat_check cs_enforcement_disable=1 cs_debug=1 amfi_allow_any_signature=1 amfi_get_out_of_my_way=1</string>
</dict>
</plist>

then copy yours patched in /Volumes/USBInstallerBigSur/System/Library/KernelCollections/BootKernelExtensions.kc
(keep a backup of it, current size is 66,7 MB, while the patched one is 75 MB or more)

and also copy in /Volumes/USBInstallerBigSur/System/Library/CoreServices/boot.efi

the ASentientBot BigSur patched boot.efi : https://forums.macrumors.com/thread...unsupported-macs-thread.2242172/post-28604525

edit:
Note: for more matching you might replace also BootKernelExtensions.kc and boot.efi on the BaseSystem.dmg's Preboot , apple assigned to it this unique common UUID: 3CA070CB-E179-47AF-BF9C-CB668ABD57CE

If you need to add to the BigSur BaseSystem.dmg the "patched IOUSBHostFamily.kext" for matching (mach-o UUID) to its SLE folder, you could use this method: https://forums.macrumors.com/thread...unsupported-macs-thread.2242172/post-28626835

I already tested and worked for APFS HighSierra Mac with recent IOUSB (I attach two funny pictures of a patched BigSur BaseSystem.dmg), while from my attempt to use it on non-APFS Mac (legacy USB) it stuck on "IOConsoleUsers: gIOScreenLockState" verbose message or IO80211Family loaded driver.

My "prelinkedkernel fix" doesn't worked for an USB BigSur Installer (or Recovery).

 

[testheit]

@jackluke you could also force to include the LegacyUSBInjector in the BootKernelExtensions.kc with kmutil and the "bundle-path" option:
kmutil create -n boot --boot-path /PATH/TO/BOOT.KC --kernel /PATH/TO/KERNEL --volume-root /BS/ROOT/VOL --bundle-path /PATH/TO/LegacyUSBInjector.kext

 

[testheit]

@jackluke, @ASentientBot, @dosdude1
in case you didn't know, you need just four files to boot from the BaseSystem.dmg:
- BaseSystem.dmg
- boot.efi (Version from @ASentientBot)
- prelinkedkernel
- com.apple.Boot.plist

Content of the plist file:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Kernel Cache</key>
    <string>\prelinkedkernel</string>
    <key>Kernel Flags</key>
    <string>root-dmg=file:///BaseSystem.dmg -no_compat_check amfi_get_out_of_my_way=1</string>
</dict>
</plist>

The "prelinkedkernel" could be the legacy prelinkedkernel or a .kc file. The System doesn't care about the naming and architecture, only the name has to match with the "Kernel Cache" string value in the com.apple.Boot.plist file.

Copy these four files to a USB stick and select the "boot.efi" file as boot-entry -> System successfully boots from BaseSystem.dmg (I could boot with the LegacyUSBInjector successfully loaded, but stuck with CORPSES...)

[automerge]1594289893[/automerge]
The BaseSystem.dmg also has a separate BaseSystemCollection.kc file...
That's what I get with the modified kernel collection created from BS. There are some differences with the included one in BaseSystem.dmg. Not only the LegacyUSBInjector

 

[jackluke]

@testheit I also noticed that BaseSystem.dmg can boot with prelinkedkernel, till CMD+S correctly with legacy usb, but after "exit" then it has many "kext not found" instances, I guess it's not possible to boot the BigSur BaseSystem.dmg using prelinkedkernel because it has its own Preboot Volume (common UUID 3CA070CB-E179-47AF-BF9C-CB668ABD57CE) and it's an APFS container that needs to mount in ramdisk its APFS "Image Volume" that is not the "macOS Base System" from which is booting before the BaseSystem.dmg is loaded in RAM.

So I guess only using BootKernelExtensions.kc could allow a booting with legacy usb, and also in its "macOS Base System"/System/Library/KernelCollections/BaseSystemCollection.kc

this additional kernelcollection makes even harder to use a patched legacy prelinkedkernel .

 

[testheit]

You could also extract the missing binaries of the BaseSystem kexts (/S*/L*/Extensions) from the prelinkedkernel file in the BaseSystem.dmg (with ./lzvn -d <path/to/prelinkedkernel> kexts, search GitHub for lzvn). But it's a pain in t* a* to merge them back to valid .kext files.
You have to copy each extracted binary to the equivalent .kext in /S*/L*/E*. Maybe someone with bash-skills could do the job...
Maybe if we use these kexts to rebuild the kernel cache for the BaseSystem? @jackluke
[automerge]1594290897[/automerge]
but in theory we could edit the BaseSystem.dmg (therefore we have the patched boot.efi from @ASentientBot). So we could also modify the Preboot volume in the BaseSystem.dmg, there should be no problem and I already done it for some testing purposes...

 

[jackluke]

You could also extract the missing binaries of the BaseSystem kexts (/S*/L*/Extensions) from the prelinkedkernel file in the BaseSystem.dmg (with ./lzvn -d <path/to/prelinkedkernel> kexts, search GitHub for lzvn). But it's a pain in t* a* to merge them back to valid .kext files.
You have to copy each extracted binary to the equivalent .kext in /S*/L*/E*. Maybe someone with bash-skills could do the job...
Maybe if we use these kexts to rebuild the kernel cache for the BaseSystem? @jackluke
[automerge]1594290897[/automerge]
but in theory we could edit the BaseSystem.dmg (therefore we have the patched boot.efi from @ASentientBot). So we could also modify the Preboot volume in the BaseSystem.dmg, there should be no problem and I already done it for some testing purposes...

I knew also the pikeralpha lzvn to decompress a prelinkedkernel, but I don't know how to rebuild a kextcache for BaseSystem.dmg SLE kext .

 

[testheit]

@jackluke I don't get these "kext not found" messages if I remember correctly, only the above shown corpses.
[automerge]1594291212[/automerge]

I knew also the pikeralpha lzvn to decompress a prelinkedkernel, but I don't know how to rebuild a kextcache for BaseSystem.dmg SLE kext .

If you try to rebuild kextcache with the /S*/L*/E* path from the BaseSystem it does not work, because the binaries are missing in the kexts (just take a look at some, all the MacOS/binary_file are missing) BUT they are in the prelinkedkernel file. So my theory: If someone extract the binaries from the prelinkedkernel (described above) and would copy each binary to its correct place in /S*/L*/E* from the BaseSystem, we should be able to recreate the original prelinkedkernel from BaseSystem
[automerge]1594291406[/automerge]
And as I said, there should also be no problem in modifying the Preboot volume of the BaseSystem.dmg. Just mount it, modify it, and save it as a new BaseSystem.dmg, same progress as modifying the "on-board" Preboot volume on your HDD/SSD. With the patched boot.efi it should load.

 

[jackluke]

@jackluke I don't get these "kext not found" messages if I remember correctly

I meant when using prelinkedkernel these messages: unable to determine realpath /path/something.kext failing

and then it also fails to do this: /sbin/mount_tmpfs -s ramsize /System/Volumes/Data/

this issue doesn't occur with BootKernelExtensions.kc .

 

[testheit]

I think we need a kernel cache with the kexts from the BaseSystem. All methods we tested so far are using an installation of BS to rebuild the cache. And as the kexts on the BaseSystem are "broken" (missing binary), we could not use these. But if we fix them, we should be able

 

[jackluke]

[automerge]1594291406[/automerge]
And as I said, there should also be no problem in modifying the Preboot volume of the BaseSystem.dmg. Just mount it, modify it, and save it as a new BaseSystem.dmg, same progress as modifying the "on-board" Preboot volume on your HDD/SSD. With the patched boot.efi it should load.

There is no problem to edit the BaseSystem.dmg's Preboot I already done that even from HighSierra, but I guess we should use the BootKernelExtensions.kc , I consider very hard to use a prelinkedkernel for a BigSur BaseSystem.dmg .
[automerge]1594291680[/automerge]

I think we need a kernel cache with the kexts from the BaseSystem. All methods we tested so far are using an installation of BS to rebuild the cache. And as the kexts on the BaseSystem are "broken" (missing binary), we could not use these. But if we fix them, we should be able

I guess even making a BaseSystem prelinkedkernel it could not work, because from Catalina the BaseSystem ramdisk tmpfs is totally changed.

 

[testheit]

Sorry for the bad image but I don't get an error with mount_tmpfs ...

[automerge]1594292091[/automerge]

There is no problem to edit the BaseSystem.dmg's Preboot I already done that even from HighSierra, but I guess we should use the BootKernelExtensions.kc , I consider very hard to use a prelinkedkernel for a BigSur BaseSystem.dmg .
[automerge]1594291680[/automerge]


I guess even making a BaseSystem prelinkedkernel it could not work, because from Catalina the BaseSystem ramdisk tmpfs is totally changed.

We could also use the .kc file, my experiences are also better with these. But that should also be possible, if we fix the kexts as described above. We could use kmutil and point it to the path with the fixed kexts. At the moment the .kc gets broken if we use the "unfixed" /S*/L*/E* folder as the kexts don't include any binary

 

[Bravo2zero]

i'm following the Big Sur to USB guide and i'm stuck on step 10.

10. Type sudo, a space, and then drag patch_installer.sh into terminal again, then drag in the newly created installer partition, then press Enter.

Is this the USB ? The guide only asks to create a partition on the USB.

 

[jackluke]

Sorry for the bad image but I don't get an error with mount_tmpfs ...

View attachment 932149
[automerge]1594292091[/automerge]

We could also use the .kc file, my experiences are also better with these. But that should also be possible, if we fix the kexts as described above. We could use kmutil and point it to the path with the fixed kexts. At the moment the .kc gets broken if we use the "unfixed" /S*/L*/E* folder as the kexts don't include any binary

Then you should try to restore the BigSur Basesystem.dmg (with its own Preboot) to an APFS container (I guess 4 GB partition is suffice), and try to make your BaseSystem prelinkedkernel (or BootKernelExtensions.kc) booting from that "restored macOS Base System APFS volume" single user mode.

 

[testheit]

And don't get confused if I always write "prelinkedkernel" you could just replace it in your mind with "BootKernelCollection.kc", but it's longer so I just continue to name it prelinkedkernel 😂.
As I sind, the system does not care about the naming, it just has to match with the entry in "com.apple.Boot.plist"
[automerge]1594292488[/automerge]

Then you should try to restore the BigSur Basesystem.dmg (with its own Preboot) to an APFS container (I guess 4 GB partition is suffice), and try to make your BaseSystem prelinkedkernel (or BootKernelExtensions.kc) booting from that "restored macOS Base System APFS volume" single user mode.

Sorry, I don't get why I should do it? Is there a problem with mine?
[automerge]1594292856[/automerge]
@jackluke
Right now I'm stuck here:
I think the problem could be the lines with "KextLog" (UUID of the loaded KC does not match with the load request)

 

[testheit]

I use the original unmodified BaseSystem.dmg by the way. I think it's all a problem of creating the proper kernel cache. Some kexts from the BaseSystem are different than their counter parts from a BS installation (UUIDs not matching)...
My idea is to fix the kexts from the BaseSystem and try those. But this should be done from someone with better bash (or whatever) skills than me otherwise it would just take too long to copy each binary to the right place.

 

[jackluke]

I use the original unmodified BaseSystem.dmg by the way. I think it's all a problem of creating the proper kernel cache. Some kexts from the BaseSystem are different than their counter parts from a BS installation (UUIDs not matching)...
My idea is to fix the kexts from the BaseSystem and try those. But this should be done from someone with better bash (or whatever) skills than me otherwise it would just take too long to copy each binary to the right place.

Of course the BaseSystem SLE kext are different (I called them the forked kext) from a full installation, I meant to restore a BaseSystem.dmg to an empty Volume so in this case if should not use a ramdisk (this worked for Catalina BaseSystem.dmg).

I guess is not simple to make a generalized BootKernelExtensions.kc because of that mach-o UUID , instead a generalised "legacy prelinkedkernel" for some reason worked even with a not matching kextcache UUID.

I am not much skilled on bash, zsh and any unix shell console usage.

 

[testheit]

Of course the BaseSystem SLE kext are different (I called them the forked kext) from a full installation, I meant to restore a BaseSystem.dmg to an empty Volume so in this case if should not use a ramdisk (this worked for Catalina BaseSystem.dmg).

I guess is not simple to make a generalized BootKernelExtensions.kc because of that mach-o UUID , instead a generalised "legacy prelinkedkernel" for some reason worked even with a not matching kextcache UUID.

I am not much skilled on bash, zsh and any unix shell console usage.

Okay, get the point 😉
But I think you could also mount the ramdisk as rw from Single user mode and then get somehow a similar behavior after typing exit. Because then the recovery disk is also allowed to write, as it would with a „extracted to disk“ dmg

 

[Cococollector]

Aside from the system diggings: In MBP 4,1 (Early 2008) ac WiFi/ BT 4.0 can be made possible with mCard from Quickertek. I have Mojave running successfully running on this machine including WiFi and HandOff. It's quite some bucks, though.
Maybe that fact is worth mentioning in the initial post (High Sierra, Mojave and Catalina as well)