macOS 11 Big Sur on Unsupported Macs Thread

[Barry K. Nathan]

Did you fix it??
I also have the same problem as you? (also I did upgrade from catalina to Big Sur beta 1, then update to beta 2 and beta 3)

I have a couple questions for both you and @pfandung. This might give me a better idea of what's going on.

If you boot from a Catalina 10.15.6 installer USB, what happens?
(a) No password prompt?
(b) Still asks for password, but it works again?
(c) Still asks for password, still fails?
(d) Something else?

Also, was Catalina a clean install, or was that an upgrade from Mojave or earlier? And same question for the earlier versions, going back to the most recent one that was a clean install. This question may seem crazy, but there was a similar bug in early versions of Snow Leopard (10.6.0, 10.6.1, 10.6.2) that only happened if the most recent clean install was Jaguar (10.2.x). (Yes, that would mean OS X Jaguar was installed on a PowerPC Mac, then it was upgraded to Panther and/or Tiger, then upgraded to Leopard, then cloned or Time Machine restored to an Intel Mac, then upgraded to Snow Leopard.)

By the way, my current ideas for quick fixes are:
(a) Turn off FileVault
(b) Use a Mojave or earlier (Catalina probably won't work) installer USB to erase the internal hard drive -- then reinstall either Catalina or Big Sur
(c) (Not really a quick fix) Wait for Big Sur beta 4 and see if that fixes it

However, I have not yet done enough testing to know for sure that any of these will actually work.

 

[Barry K. Nathan]

Is there anything in there that is obviously different?

At least for me, kextcache is putting the new prelinkedkernel in /Library/Apple/System/Library/PrelinkedKernels (use the -v 2 option to kextcache to check for yourself), so you may need to sudo cp /Library/Apple/System/Library/PrelinkedKernels/prelinkedkernel /System/Library/PrelinkedKernels/ before the kcditto.

(pretend that this is two different posts being merged together by the MacRumors forum)

An update on my progress with prelinkedkernels and the installser USB:

I noticed that the prelinkedkernel on the installer USB and the prelinkedkernel that is installed in /System/Library/Prelinkedkernels are actually byte-for-byte identical, which made me wonder if prelinkedkernels might be compatible between the full installation and the Recovery environment (installer USB). It turns out that once I do the LZVN extraction and replacement of kexts in BaseSystem.dmg (and it becomes able to boot with the original prelinkedkernel), I can just replace that prelinkedkernel (in /System/Library/PrelinkedKernels on the installer USB itself -- no need to copy the prelinkedkernel onto the BaseSystem Preboot or Basesystem itself) with the prelinkedkernelb3penryn from @jackluke, and I have a patched installer USB with working keyboard, trackpad, and WiFi on my MacBook6,1, with no need to boot with OpenCore.

Results were more mixed with a prelinkedkernel I made on my MacBookPro8,1 -- the installer USB could boot with that prelinkedkernel on the MBP8,1 but it would freeze during boot on the MB6,1 (in verbose boot it looked USB-related). Nonetheless, I can figure that out later. The big thing to me is that the same fix makes both the original prelinkedkernel and jackluke's ones work on the installer USB, and that feels like real progress.

Now I'm wondering if it might be possible to do some kind of fix that involves copying kexts from the full Big Sur installation instead of extracting them using LZVN. I think I'll try that later tonight. (And after I try that, perhaps I'll revisit the issue of why I can't get the installer USB to boot with a custom BootKernelExtensions.kc.)

Edit: I tried decompressing jackluke's prelinkedkernelb3penryn and grepping for "parrotgeek" and "LegacyUSBInjector", and it matched for both. Just wanted to answer that question. (And the same is true for the decompressed version of the prelinkedkernel from my MBP8,1. The prelinkedkernel from my MBP8,1 is several MB smaller than either Apple's original or jackluke's one so there's almost certainly something missing, but I'll revisit it later.)

 

[jackluke]

So I tried USBOpenCoreAPFSloader3b + prelinkedkernel.

On my MacBook6,1 it works! It boots the Big Sur beta 3 USB stick, patched as I previously described to use the prelinkedkernel, and the keyboard and trackpad work! It got as far as the FileVault account prompt (my MacBook6,1 has a FileVault-encrypted Mojave running on the internal drive), but I decided to shut down instead of proceeding further. Unfortunately, it seems like my boot-args and csr-active-config got cleared from nvram. This is my first time trying OpenCore, so I don't know if this is expected. (I tried it a second time and they got cleared a second time, by the way.) So I'll still see if I can get an updated BKE to work on the Big Sur installer USB.

By the way, on my MacBook4,1 (I may not have previously mentioned that I have one), it flashes between the Apple logo and the prohibited sign, and eventually seems to freeze up, before it ever gets to the OpenCore boot menu. (I don't actually care that much about getting my MacBook4,1 to run Big Sur, but I figured I'd give it a quick try. Right now it's still on Lion.)

Yes, boot-args and csr-active-config are cleared after exiting from opencore, it is an expected feature that consists in delete those values to set custom ones (to store boot-args you can use com.apple.Boot.plist), so you should set them again, opencore is very useful also to spoof to a BigSur supporter Mac (and complete a full unpatched installation or OTA update) and I could set also w%09%00%00 for opencore config to boot any patched BaseSystem with a stock boot.efi .

I guess your LZVN extraction and replacement of kexts in BaseSystem.dmg allowed this to work (because if I don't get wrong I tested in replacing the BaseSystem SLE but got stuck on verbose mode IO80211Family channel).

My prelinkedkernelb3penryn should work also for Sandy Bridge and Ivy Bridge Mac , so for a patched BaseSystem could be used that .

Moreover as I already tested you can also use a previous beta1 or beta2 BaseSystem.dmg 740 MB (enough different from the current 884 MB) and this allow to make a BigSur beta3 installer to install BigSur as Beta 3 with a Recovery BaseSystem 884 MB (because the other one in the SharedSupport.dmg is used for stage2 and for APFS Recovery).

 

[Barry K. Nathan]

Yes, boot-args and csr-active-config are cleared after exiting from opencore, it is an expected feature that consists in delete those values to set custom ones (to store boot-args you can use com.apple.Boot.plist), so you should set them again, opencore is very useful also to spoof to a BigSur supporter Mac (and complete a full unpatched installation or OTA update) and I could set also w%09%00%00 for opencore config to boot any patched BaseSystem with a stock boot.efi .

I guess your LZVN extraction and replacement of kexts in BaseSystem.dmg allowed this to work (because if I don't get wrong I tested in replacing the BaseSystem SLE but got stuck on verbose mode IO80211Family channel).

My prelinkedkernelb3penryn should work also for Sandy Bridge and Ivy Bridge Mac , so for a patched BaseSystem could be used that .

Moreover as I already tested you can also use a previous beta1 or beta2 BaseSystem.dmg 740 MB (enough different from the current 884 MB) and this allow to make a BigSur beta3 installer to install BigSur as Beta 3 with a Recovery BaseSystem 884 MB (because the one in the SharedSupport.dmg is used for stage2 and for APFS Recovery).

Thanks for explaining about OpenCore.

The way I did the LZVN kext replacement stuff will only work with the beta 3 BaseSystem.dmg, not beta 1 or 2. It should be possible to do it in a way that would work with beta 1 or 2 but it would be much more complicated. Apple did weird symlink stuff with the beta 1 and 2 BaseSystem.dmg /System/Library/Extensions but they didn't do that with beta 3, and not having to deal with that makes the LZVN kext replacement thing much easier. Whereas if I copy them from a full Big Sur installation I might be able to do something that's reasonably simple but will still work if Apple does the symlink stuff again.

Hopefully by this weekend or early next week (or sooner if possible) I'll have some kind of script, or at least instructions, for fixing prelinkedkernel booting with the Big Sur installer USB.

 

[jackluke]

Thanks for explaining about OpenCore.

The way I did the LZVN kext replacement stuff will only work with the beta 3 BaseSystem.dmg, not beta 1 or 2. It should be possible to do it in a way that would work with beta 1 or 2 but it would be much more complicated. Apple did weird symlink stuff with the beta 1 and 2 BaseSystem.dmg /System/Library/Extensions but they didn't do that with beta 3, and not having to deal with that makes the LZVN kext replacement thing much easier. Whereas if I copy them from a full Big Sur installation I might be able to do something that's reasonably simple but will still work if Apple does the symlink stuff again.

Hopefully by this weekend or early next week (or sooner if possible) I'll have some kind of script, or at least instructions, for fixing prelinkedkernel booting with the Big Sur installer USB.

That's why I can't boot Recovery graphical envinromnet with prelinkedkernel after replaced its SLE (or Prelinkedkernels also on its Preboot), I used beta1 (or beta2) BaseSystem for my "custom USB BigSur Beta3 install.app", then I should try the LZVN kext replacement for beta3 BaseSystem , but as you know LZVN kext are a bit different from full installation kext, I call them the forked kext , I guess they worked for your patched BaseSystem for this reason, they are more similar to Recovery kext .

Also consider that even when using a patched BKE with LegacyUSBInjector embedded you can attempt to boot the USB Installer with CMD+S, this should allow keyboard to work in single user mode, then simply "exit" to continue booting.

 

[jackluke]

By the way, on my MacBook4,1 (I may not have previously mentioned that I have one), it flashes between the Apple logo and the prohibited sign, and eventually seems to freeze up, before it ever gets to the OpenCore boot menu. (I don't actually care that much about getting my MacBook4,1 to run Big Sur, but I figured I'd give it a quick try. Right now it's still on Lion.)

About the fact that USBopencore doesn't worked to boot MacBook4,1 , I guess have an explanation, @Larsvonhier that patched that machine to work with Mojave (and later) could confirm that required many other IOUSB very legacy kext that I don't included (only included the parrotgeek1 LegacyUSBInjector), but opencore can inject only kext not already present on the prelinkedkernel, I guess can't override an already preloaded kext .

So for booting a patched BaseSystem.dmg on MacBook4,1 you should use a patched prelinkedkernel from that target machine.

 

[rickosx]

Please someone help me install it on Mac Pro 3,1 Cant find any guide to do it anywhere and following the parrot geek guide is not booting

 

[jackluke]

I noticed that the prelinkedkernel on the installer USB and the prelinkedkernel that is installed in /System/Library/Prelinkedkernels are actually byte-for-byte identical, which made me wonder if prelinkedkernels might be compatible between the full installation and the Recovery environment (installer USB). It turns out that once I do the LZVN extraction and replacement of kexts in BaseSystem.dmg (and it becomes able to boot with the original prelinkedkernel), I can just replace that prelinkedkernel (in /System/Library/PrelinkedKernels on the installer USB itself -- no need to copy the prelinkedkernel onto the BaseSystem Preboot or Basesystem itself) with the prelinkedkernelb3penryn from @jackluke, and I have a patched installer USB with working keyboard, trackpad, and WiFi on my MacBook6,1, with no need to boot with OpenCore.

I made a stock BigSur Beta 3 createinstallmedia, pointed the com.apple.Boot.plist to the stock prelinkedkernel, done the modification of LZVN extraction on BaseSystem SLE making a patched BaseSystem (about 900 MB at this point) but getting this kp on tmpfs.kext :

panic(cpu 0 caller 0xffffff80044acb9b): "userspace panic: boot task failure: restore-datapartition - exited due to exit(7"@/AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/xnu/xnu-7155.0.0.131.6/bsd/kern/kern_shutdown.c:155

same kp also when using a stock BaseSystem beta3 (884 MB) with its stock prelinkedkernel 26 MB .

Do you replaced any other stuff on BaseSystem Preboot or maybe removed the tmpfs.kext ?

 

[Barry K. Nathan]

I made a stock BigSur Beta 3 createinstallmedia, pointed the com.apple.Boot.plist to the stock prelinkedkernel, done the modification of LZVN extraction on BaseSystem SLE making a patched BaseSystem (about 900 MB at this point) but getting this kp on tmpfs.kext :

panic(cpu 0 caller 0xffffff80044acb9b): "userspace panic: boot task failure: restore-datapartition - exited due to exit(7"@/AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/xnu/xnu-7155.0.0.131.6/bsd/kern/kern_shutdown.c:155

same kp also when using a stock BaseSystem beta3 (884 MB) with its stock prelinkedkernel 26 MB .

Do you replaced any other stuff on BaseSystem Preboot or maybe removed the tmpfs.kext ?

No, I don't remove the tmpfs.kext and I don't replace anything in Preboot.

Using the full installation kexts also works, if you do something to make enough space on BaseSystem (for example, erasing the KCs in /System/Library/KernelCollections on the BaseSystem). In fact, there are hundreds, maybe thousands, of lines of error messages that scroll by during boot with the LZVN kexts that are totally absent with the kexts from the full installation.

I've written a script for doing the replacement using the kexts from the full installation. I'm testing it, and once I'm done testing, I'll post it here. (It should be later tonight. I'll probably edit this post instead of making a new post.)

Given the disk space disparity, the LZVN approach may still be valuable, so I'll try writing a script for that too. After that, I'll try again with beta 2 and see what changes the two scripts need.

I'm writing these kext replacement scripts not really for the purpose of automating this (although it happens to do that too) -- I'm writing them more in order to try to precisely document what I'm doing.

 

[jackluke]

No, I don't remove the tmpfs.kext and I don't replace anything in Preboot.

Using the full installation kexts also works, if you do something to make enough space on BaseSystem (for example, erasing the KCs in /System/Library/KernelCollections on the BaseSystem). In fact, there are hundreds, maybe thousands, of lines of error messages that scroll by during boot with the LZVN kexts that are totally absent with the kexts from the full installation.

I've written a script for doing the replacement using the kexts from the full installation. I'm testing it, and once I'm done testing, I'll post it here. (It should be later tonight. I'll probably edit this post instead of making a new post.)

Given the disk space disparity, the LZVN approach may still be valuable, so I'll try writing a script for that too. After that, I'll try again with beta 2 and see what changes the two scripts need.

I'm writing these kext replacement scripts not really for the purpose of automating this (although it happens to do that too) -- I'm writing them more in order to try to precisely document what I'm doing.

After the LZVN prelinkedkernel extraction to the "macOS Base System" do you copied also the content of this path /kexts/Library/* or only /kexts/System/* ?

I noticed too that on the BaseSystem mounted (macOS Base System) there are 128 MB available space, so it's suffice to replace LZVN kext without removing files .

Probably to prevent the userspace tmpfs.kext kp should use a com.apple.Boot.plist kernel flag to increase Ramdisk allocation on RAM as for example maxmem=4096 ?

Is there a way to point the patched boot.efi from the com.apple.Boot.plist instead of using bless ?

 

[Larsvonhier]

About the fact that USBopencore doesn't worked to boot MacBook4,1 , I guess have an explanation, @Larsvonhier that patched that machine to work with Mojave (and later) could confirm that required many other IOUSB very legacy kext that I don't included (only included the parrotgeek1 LegacyUSBInjector), but opencore can inject only kext not already present on the prelinkedkernel, I guess can't override an already preloaded kext .

So for booting a patched BaseSystem.dmg on MacBook4,1 you should use a patched prelinkedkernel from that target machine.

Exactly true.

 

[jhowarth]

At least for me, kextcache is putting the new prelinkedkernel in /Library/Apple/System/Library/PrelinkedKernels (use the -v 2 option to kextcache to check for yourself), so you may need to sudo cp /Library/Apple/System/Library/PrelinkedKernels/prelinkedkernel /System/Library/PrelinkedKernels/ before the kcditto.

(pretend that this is two different posts being merged together by the MacRumors forum)

An update on my progress with prelinkedkernels and the installser USB:

I noticed that the prelinkedkernel on the installer USB and the prelinkedkernel that is installed in /System/Library/Prelinkedkernels are actually byte-for-byte identical, which made me wonder if prelinkedkernels might be compatible between the full installation and the Recovery environment (installer USB). It turns out that once I do the LZVN extraction and replacement of kexts in BaseSystem.dmg (and it becomes able to boot with the original prelinkedkernel), I can just replace that prelinkedkernel (in /System/Library/PrelinkedKernels on the installer USB itself -- no need to copy the prelinkedkernel onto the BaseSystem Preboot or Basesystem itself) with the prelinkedkernelb3penryn from @jackluke, and I have a patched installer USB with working keyboard, trackpad, and WiFi on my MacBook6,1, with no need to boot with OpenCore.

Results were more mixed with a prelinkedkernel I made on my MacBookPro8,1 -- the installer USB could boot with that prelinkedkernel on the MBP8,1 but it would freeze during boot on the MB6,1 (in verbose boot it looked USB-related). Nonetheless, I can figure that out later. The big thing to me is that the same fix makes both the original prelinkedkernel and jackluke's ones work on the installer USB, and that feels like real progress.

Now I'm wondering if it might be possible to do some kind of fix that involves copying kexts from the full Big Sur installation instead of extracting them using LZVN. I think I'll try that later tonight. (And after I try that, perhaps I'll revisit the issue of why I can't get the installer USB to boot with a custom BootKernelExtensions.kc.)

Edit: I tried decompressing jackluke's prelinkedkernelb3penryn and grepping for "parrotgeek" and "LegacyUSBInjector", and it matched for both. Just wanted to answer that question. (And the same is true for the decompressed version of the prelinkedkernel from my MBP8,1. The prelinkedkernel from my MBP8,1 is several MB smaller than either Apple's original or jackluke's one so there's almost certainly something missing, but I'll revisit it later.)

My installation of Big Sur beta 3 on a supported MacBook Pro 14,1 didn't result in /Library/Apple/System/Library/PrelinkedKernels or /Library/Apple/System/Library/Caches existing. This was from a clean install. Did you do an upgrade install instead and is they why you have /Library/Apple/System/Library/PrelinkedKernels? On my MacPro 3,1, the prelinkedkernel ends up built in /System/Library/PrelinkedKernels and is much larger than jacklukes...

-rw-r--r-- 1 howarth staff 28776140 Jul 29 18:53 prelinkedkernel

How to I decompress the prelinkedkernel to see what is in it?

 

[Barry K. Nathan]

After the LZVN prelinkedkernel extraction to the "macOS Base System" do you copied also the content of this path /kexts/Library/* or only /kexts/System/* ?

I noticed too that on the BaseSystem mounted (macOS Base System) there are 128 MB available space, so it's suffice to replace LZVN kext without removing files .

No, just kexts/System/* -- I figured I could deal with kexts/Library/* later should the need arise.

Here's the script for using the full kexts. I was originally going to attach it, but the MacRumors Forum is telling me that .sh is not an approved file extension or something like that, and the script's pretty short, so I'll just put it in a code block.

This is how things work out for me:

1. I change the com.apple.Boot.plist on the USB stick to boot with a prelinked kernel, and I try booting, and the kernel panic happens. (This is also after replacing the boot.efi with the 0xffffffff boot.efi, using bless.)
2. I convert the BaseSystem.dmg to read-write and mount that.
3. I run the script. (It copies full kexts into the BaseSystem, but only to replace kexts that are already present in the BaseSystem's /S/L/E.)
4. I unmount the read-write BaseSystem.dmg then copy it back onto the USB drive. (I have been leaving it read-write, but I should try making it compressed read-only again and make sure things still work. Edit: UDZO and ULFO both work.)
5. Now the USB stick boots as it should.

#!/bin/bash
# Assumption: read-write BaseSystem.dmg is already mounted

if [ ! -d "/Volumes/macOS Base System" ]
then
    echo "Make sure read-write BaseSystem is mounted!"
    exit 1
fi

# This seems to be necessary, at least sometimes, even though the image
# is already in read-write format.
mount -uw "/Volumes/macOS Base System" || exit 1

# Delete the KernelCollections because we need the disk space!
echo 'Deleting KernelCollections on macOS Base System.'
rm -f "/Volumes/macOS Base System/System/Library/KernelCollections/"*.kc

cd "/Volumes/macOS Base System/System/Library/Extensions" || exit 1
for x in *
do
    # This reuses the same line of console output repeatedly
    # so progress is visible without printing 400+ lines
    echo -n "Removing old $x..."
    rm -rf "$x"
    echo -ne "\033[2K" ; printf "\r"

    echo -n "Copying new $x..."
    cp -r "/System/Library/Extensions/$x" "$x"
    echo -ne "\033[2K" ; printf "\r"
done

chmod -R 755 "/Volumes/macOS Base System/System/Library/Extensions"
chown -R 0:0 "/Volumes/macOS Base System/System/Library/Extensions"

 

[jackluke]

Here's the script for using the full kexts. I was originally going to attach it, but the MacRumors Forum is telling me that .sh is not an approved file extension or something like that, and the script's pretty short, so I'll just put it in a code block.

You should zip the file to attach on MacRumors .

About prelinkedkernel and BaseSystem beta3 I am enough sure that I followed similar steps, I still get a kp on tmpfs.kext , but I used hdiutil attach -owners on BaseSystem.dmg -shadow , so maybe I should try that other different method of mount -uw /Volumes/macOS Base System .

About the ASentientBot patched boot.efi in some post I linked a wrong one 0x867 to use , instead it is this attached (also patched from ASentientBot) to use for booting any patched BaseSystem.dmg without imageboot.c kp .

(but using nvram csr-active-config = w%09%00%00 is also another method that worked with stock boot.efi)

 

[Barry K. Nathan]

My installation of Big Sur beta 3 on a supported MacBook Pro 14,1 didn't result in /Library/Apple/System/Library/PrelinkedKernels or /Library/Apple/System/Library/Caches existing. This was from a clean install. Did you do an upgrade install instead and is they why you have /Library/Apple/System/Library/PrelinkedKernels? On my MacPro 3,1, the prelinkedkernel ends up built in /System/Library/PrelinkedKernels and is much larger than jacklukes...

-rw-r--r-- 1 howarth staff 28776140 Jul 29 18:53 prelinkedkernel

How to I decompress the prelinkedkernel to see what is in it?

No, it was a clean install, but on an unsupported MacBookPro8,1. My prelinkedkernels were ending up in /System/Library/Prelinkedkernels in beta 2 (which was an upgrade from beta 1 if I remember correctly). At some point I'll do another clean install and see how kextcache behaves for me (but that might be after beta 4 comes out).

You can decompress it using LZVN. It's a little buggy for me but still usable. (For instance, when I tried to extract kexts from a prelinkedkernel, it created an empty file called "kexts" then froze up. I had to kill it, remove the empty "kexts" file, create a directory with the same name, then try again, and that worked.)

GitHub - Piker-Alpha/LZVN: C-Style conversion of lzvn_decode

C-Style conversion of lzvn_decode. Contribute to Piker-Alpha/LZVN development by creating an account on GitHub.

github.com

 

[jackluke]

This is the complete output that I am seeing for a prelinkedkernel build which still produces the Bluetooth keyboard dialog instead of usable legacy usb support...

% sudo mount -uw /
% sudo chown -R 0:0 /System/Library/Extensions/
% sudo chmod -R 755 /System/Library/Extensions/
% sudo kextcache -i /
Can't read info dictionary for /Library/Apple/System/Library/Extensions/AppleMobileDevice.kext: IOCFUnserialize: syntax error near line 1.
Can't read info dictionary for /Library/Apple/System/Library/Extensions/AppleMobileDevice.kext: IOCFUnserialize: syntax error near line 1.
Can't read info dictionary for /Library/Apple/System/Library/Extensions/AppleMobileDevice.kext: IOCFUnserialize: syntax error near line 1.
Can't read info dictionary for /Library/Apple/System/Library/Extensions/AppleMobileDevice.kext: IOCFUnserialize: syntax error near line 1.
Can't read info dictionary for /Library/Apple/System/Library/Extensions/AppleMobileDevice.kext: IOCFUnserialize: syntax error near line 1.
Kext with invalid signature (-67062) allowed: <OSKext 0x7f8d1850ef30 [0x7fff83ea5c20]> { URL = "file:///Library/Extensions/LegacyUSBInjector.kext/", ID = "com.parrotgeek.LegacyUSBInjector" }
/System/Library/Extensions/AppleBSDKextStarter.kext doesn't support architecture x86_64; omitting from prelinked kernel.
KernelCache ID: 5D249C976F04F76D5AE9B83505AF8DE7
symlink("../../../PrelinkedKernels/prelinkedkernel", "/Library/Apple/System/Library/Caches/com.apple.kext.caches/Startup/kernelcache") failed 2 (No such file or directory)
Can't read info dictionary for /Library/Apple/System/Library/Extensions/AppleMobileDevice.kext: IOCFUnserialize: syntax error near line 1.
Can't read info dictionary for /Library/Apple/System/Library/Extensions/AppleMobileDevice.kext: IOCFUnserialize: syntax error near line 1.
Can't read info dictionary for /Library/Apple/System/Library/Extensions/AppleMobileDevice.kext: IOCFUnserialize: syntax error near line 1.
Kext with invalid signature (-67062) allowed: <OSKext 0x7fc827af6070 [0x7fff83ea5c20]> { URL = "file:///Library/Extensions/LegacyUSBInjector.kext/", ID = "com.parrotgeek.LegacyUSBInjector" }
Can't read info dictionary for /Library/Apple/System/Library/Extensions/AppleMobileDevice.kext: IOCFUnserialize: syntax error near line 1.
Can't read info dictionary for /Library/Apple/System/Library/Extensions/AppleMobileDevice.kext: IOCFUnserialize: syntax error near line 1.
Can't read info dictionary for /Library/Apple/System/Library/Extensions/AppleMobileDevice.kext: IOCFUnserialize: syntax error near line 1.
% sudo kmutil install --update-all
checking collections...
unable to load existing release kernel collections, forcing rebuild
rebuilding release collections: boot, system
rebuilding release collections:
    boot kernel collection
    system kext collection
rebuilding local auxiliary collection
Error: Error Domain=NSCocoaErrorDomain Code=4097 "connection to service on pid 0 named com.apple.KernelExtensionServer" UserInfo={NSDebugDescription=connection to service on pid 0 named com.apple.KernelExtensionServer}
% sudo kcditto
Copying deferred prelinked kernels in /...
Copying: /Library/Apple/System/Library/PrelinkedKernels/prelinkedkernel -> /System/Library/PrelinkedKernels
Copying KCs in /...
System Volume UUID: CF2D53BB-9152-45FA-BF0E-4E8B2FD8F30F
Volume Group UUID: 13982718-DA24-480A-9EDD-51D4FBB809A5
Preboot disk: /dev/disk8s2
Preboot volume: /System/Volumes/Preboot
Copying: /System/Library/KernelCollections/BootKernelExtensions.kc.elides -> /System/Volumes/Preboot/13982718-DA24-480A-9EDD-51D4FBB809A5/boot/System/Library/KernelCollections
Copying: /System/Library/KernelCollections/BootKernelExtensions.kc -> /System/Volumes/Preboot/13982718-DA24-480A-9EDD-51D4FBB809A5/boot/System/Library/KernelCollections
Copying: /System/Library/PrelinkedKernels/immutablekernel -> /System/Volumes/Preboot/13982718-DA24-480A-9EDD-51D4FBB809A5/System/Library/PrelinkedKernels
Copying: /System/Library/PrelinkedKernels/prelinkedkernel -> /System/Volumes/Preboot/13982718-DA24-480A-9EDD-51D4FBB809A5/System/Library/PrelinkedKernels
%

Is there anything in there that is obviously different?

Same output, anyway I don't understand what's wrong in using my patched prelinkedkernel.

 

[Barry K. Nathan]

Same output, anyway I don't understand what's wrong in using my patched prelinkedkernel.

The more of us who can create prelinkedkernels, the better.

 

[jackluke]

The more of us who can create prelinkedkernels, the better.

I explained how to make a non-APFS legacy USB prelinkedkernel:
https://forums.macrumors.com/thread...unsupported-macs-thread.2242172/post-28679556

The BaseSystem beta3 with prelinkedkernel for me don't worked (the stock BigSur SLE kext are more than 1 GB and won't fit the "macOS Base System"), still getting a kp on tmpfs.kext, at this point I wait for someone that upload it already patched.

 

[pfandung]

I have a couple questions for both you and @pfandung. This might give me a better idea of what's going on.

If you boot from a Catalina 10.15.6 installer USB, what happens?
(a) No password prompt?
(b) Still asks for password, but it works again?
(c) Still asks for password, still fails?
(d) Something else?

Also, was Catalina a clean install, or was that an upgrade from Mojave or earlier? And same question for the earlier versions, going back to the most recent one that was a clean install. This question may seem crazy, but there was a similar bug in early versions of Snow Leopard (10.6.0, 10.6.1, 10.6.2) that only happened if the most recent clean install was Jaguar (10.2.x). (Yes, that would mean OS X Jaguar was installed on a PowerPC Mac, then it was upgraded to Panther and/or Tiger, then upgraded to Leopard, then cloned or Time Machine restored to an Intel Mac, then upgraded to Snow Leopard.)

By the way, my current ideas for quick fixes are:
(a) Turn off FileVault
(b) Use a Mojave or earlier (Catalina probably won't work) installer USB to erase the internal hard drive -- then reinstall either Catalina or Big Sur
(c) (Not really a quick fix) Wait for Big Sur beta 4 and see if that fixes it

However, I have not yet done enough testing to know for sure that any of these will actually work.

Hi, thank you for your efforts. I didn't have a Catalina installer, but I had the Big Sur Beta 2 file, therefore I created a Beta 2 installer, booted into it, arrived to the password prompt, and... the password was not accepted! That's really weird: when I installed Beta 2 three weeks ago I had a password prompt, but my password was accepted and the installation went smoothly. I don't know what to think.

BTW, I can live with this issue, therefore I'll wait for Beta 4 (I hope that I can install it).

F.

P.S.: I started with Lion in 2012, then upgraded to every new release. I never performed a clean install.

 

[Barry K. Nathan]

I explained how to make a non-APFS legacy USB prelinkedkernel:
https://forums.macrumors.com/thread...unsupported-macs-thread.2242172/post-28679556

The BaseSystem beta3 with prelinkedkernel for me don't worked (the stock BigSur SLE kext are more than 1 GB and won't fit the "macOS Base System"), still getting a kp on tmpfs.kext, at this point I wait for someone that upload it already patched.

The script I posted replaces only the kexts which are already in the BaseSystem's /System/Library/Extensions, to keep it (barely) small enough.

Anyway, I'll try to get the LZVN script done later today.

(And right now there's something going wrong for me with making the prelinkedkernel -- but your instructions were still very helpful for me a couple weeks ago when I started looking into prelinkedkernels, and as I think I said several posts ago, I'll look into my own prelinkedkernel problems later.)
[automerge]1596108850[/automerge]

Hi, thank you for your efforts. I didn't have a Catalina installer, but I had the Big Sur Beta 2 file, therefore I created a Beta 2 installer, booted into it, arrived to the password prompt, and... the password was not accepted! That's really weird: when I installed Beta 2 three weeks ago I had a password prompt, but my password was accepted and the installation went smoothly. I don't know what to think.

BTW, I can live with this issue, therefore I'll wait for Beta 4 (I hope that I can install it).

F.

P.S.: I started with Lion in 2012, then upgraded to every new release. I never performed a clean install.

That's helpful information (and actually how I was expecting the Beta 2 installer to behave). Thank you.

(Regarding the Catalina installer, I'm actually less concerned with whether the password is accepted and more concerned with whether it even asks for a password in the first place.)

Also, do you happen to know which OS X release you were running when you turned FileVault on? Was that also Lion or was it a different release? If you don't remember, don't worry about it, but it would be one more helpful piece of information.

 

[jackluke]

The script I posted replaces only the kexts which are already in the BaseSystem's /System/Library/Extensions, to keep it (barely) small enough.

Anyway, I'll try to get the LZVN script done later today.

(And right now there's something going wrong for me with making the prelinkedkernel -- but your instructions were still very helpful for me a couple weeks ago when I started looking into prelinkedkernels, and as I think I said several posts ago, I'll look into my own prelinkedkernel problems later.)

For me currently the stock prelinkedkernel works with stock BaseSystem beta3 but only till single user mode, from where I can type (after "exit" get kp on tmpfs.kext or its command), anyway I noticed that apple launch this during its BKE BaseSystem: /sbin/mount_tmpfs -s ramsize 2*longnumber /System/Volumes/Data/

not sure exactly but I guess that should be minimal 2 GB RAM requirement to boot BigSur (or its Recovery), but maybe is required some manual increasing of the Ramdisk (from tmpfs) to allow an enlarged patched BaseSystem.dmg .

Weirdly I had more working patched BaseSystem with prelinkedkernel when used the 740 MB one from beta1 and beta2 (I guess also @testheit could confirm that).

edit:
It worked, I replaced all the BaseSystem SLE with their equivalent "non forked kext" from a full BigSur Beta 3 installation (they are about 240 kext to replace) and now stock BaseSystem is booting with stock prelinkedkernel, and just this of course already allow to boot USB BigSur Installer with legacyUSB through USBOpenCoreAPFSloader3b.app.zip .

(encountered the colorful beachball during the apple logo, funny)

So I assume to use legacy USB without USBOpenCore, my "legacyusb prelinkedkernel fix" should be replaced also on the BaseSystem /System/Library/Prelinkedkernels/ and maybe also on the BaseSystem Preboot for more kext matching .

 

[Arnomacmini]

I'll try to investigate this when I get a chance.

By the way, does audio over HDMI work under Mojave or Catalina on your Mac Mini?

Yes , my macmini is on a Sony Tv 1080 P and in Catalina , i have in sound : " SONY TV XV "

 

[Barry K. Nathan]

For me currently the prelinkedkernel works with BaseSystem beta3 till single user mode, from where I can type, anyway I noticed that apple launch this during its BKE BaseSystem: /sbin/mount_tmpfs -s ramsize 2048 /System/Volumes/Data/

not sure if exactly 2048, but maybe is required some increasing of the Ramdisk to allow an enlarged patched BaseSystem.dmg .

A similar (if not identical) ramdisk is also created if you use a prelinkedkernel. Only something like 20MB of data is actually stored on that ramdisk, at least in my testing. It's not used for storing the BaseSystem. (Nevertheless, thanks for pointing it out!)

That reminds me, /Library on the BaseSystem is actually a symlink to /System/Volumes/Data/Library, which doesn't exist until sometime after the /System/Volumes/Data ramdisk is set up. That's one reason I didn't bother trying to copy the LZVN-extracted kexts/Library/* onto the BaseSystem.

Now that I'm looking at it more closely, I think after the /System/Volumes/Data ramdisk is initialized during BaseSystem boot, the BaseSystem's /System/Library/Templates/Data gets copied in its entirety to /System/Volumes/Data. For all practical intents and purposes, the BaseSystem's /Library is actually at /System/Library/Templates/Data/Library. And the root user's home directory, when you're running from the BaseSystem (/var/root), is also on this /System/Volumes/Data ramdisk.

Now I'm curious about when Apple started using this ramdisk arrangement. ... Oh, wow, it's completely new for Big Sur. Even Catalina uses a much different ramdisk arrangement.

 

[jhowarth]

Same output, anyway I don't understand what's wrong in using my patched prelinkedkernel.

The point is that we don't seem to have a reliable set of instructions that allow others to reproduce the feat of building prelinked kernels under Big Sur once the seal and the snapshot is removed starting from an installation performed on a supported machine. In particular, it is entirely unclear why 'sudo kextcache -i /' procedures a non-functional prelinkedkernel that is so much larger than yours (when the only additional kext added were AppleIntelPIIXATA.kext at 120,557 bytes and LegacyUSBInjector.kext at 137,715 bytes).

As far as the kc's are concerned, the elide that was produced from kmutil and kcditto seemed to indicate that the original kext required by the MacBook Pro 14,1 were still being bundled rather than those for the MacPro 3,1. I am wondering if that is a side-effect of "Error: Error Domain=NSCocoaErrorDomain Code=4097 "connection to service on pid 0 named com.apple.KernelExtensionServer" UserInfo={NSDebugDescription=connection to service on pid 0 named com.apple.KernelExtensionServer}". Perhaps that com.apple.KernelExtensionServer connection is required for the recognition of the kext that have to be loaded on the unsupported hardware and, in its absence, the kext set is left as those used by the original supported machine.

 

[jackluke]

Now I'm curious about when Apple started using this ramdisk arrangement. ... Oh, wow, it's completely new for Big Sur. Even Catalina uses a much different ramdisk arrangement.

Yes, they completely changed the Ramdisk structure with BigSur, but thanks to your tips I have a bootable stock BaseSystem with stock prelinkedkernel and through USBOpenCoreAPFSloader3b already allow as is to boot the USB BigSur Installer from legacy USB Mac.

I edited my previous post: https://forums.macrumors.com/thread...unsupported-macs-thread.2242172/post-28723098

in few words for using the stock apple BigSur prelinkedkernel on BaseSystem need to replace on BaseSystem SLE the same 243 kext (size about 240 MB) from a full BigSur install, while the forked ones size is 50 MB so they are incomplete of course for the prelinkedkernel.

On a full BigSur installation there are 480 kext (Extensions) or more for about 1,4 GB size, but only 243 (or maybe less) of them are needed to make work the stock prelinkedkernel for a BigSur BaseSystem .

edit:
After replaced the stock installation BigSur 243 kext on the "BaseSystem mounted RW"

to mount BaseSystem RW I used this method: https://forums.macrumors.com/thread...unsupported-macs-thread.2242172/post-28626835

to replace the kext this method (use it directly from BigSur sudo -s): https://forums.macrumors.com/thread...unsupported-macs-thread.2242172/post-28722919

when the BaseSystem is modified and unmounted, is sufficient to copy (outside of the BaseSystem):

replace this: prelinkedkernelb3penryn.zip (using this will enable also Wifi on BigSur Recovery)
here: /USBInstallerBigSur/System/Library/Prelinkedkernels/prelinkedkernel

replace this: recovery bigsur com.apple.Boot.plist.zip
here: /USBInstallerBigSur/Library/Preferences/SystemConfiguration/com.apple.Boot.plist

and replace this ASentientBot boot_0xffffffff.efi.zip (rename to boot.efi)
here: /USBInstallerBigSur/System/Library/CoreServices/boot.efi


Now we have a non-APFS and legacy USB bootable USB BigSur Installer even without USBopencore (already tested from a non-APFS Mac and Wifi too is working), don't tested yet a stage2 installer but I assume it could work too.

I'd upload the patched BaseSystem.dmg but it's 930 MB, I am sure that others will provide more clever scripts to automatize this routine.