Anyone else with this bug? When I choose BS wallpapers I get Catalina ones
BIErrorDomain error 3
message) and at boot time with the ? prohibitory symbol. The former can be bypassed with OpenCore (which I know very little about, but @jackluke is an expert) or my installer hack here (or the older version). The latter is avoided with -no_compat_check
, either set in NVRAM or the Preboot volume. I think these issues have been largely solved.APFS_INCOMPAT_SEALED_VOLUME
flag, see here). My latest installer hack turns off sealing (but not snapshots, which is why it failed to fix error 66
for most people). There doesn't seem to be any way to fully unseal a volume once it's been sealed: snapshots and verification can be turned off, but it will never mount on an older OS since that flag is still present. So the install-time disabling seems like a must.error 66
when trying to remount the system volume, since /
actually points to a read-only snapshot, not the modifiable "live" version. No install-time patch is known for this yet (I've worked on some things, but with little success -- the snapshot is created by ramrod/patchd
in the ramdisk and there isn't a nice flag to disable it like with sealing). My previous hack (based on @mac_4eva's post) sometimes changes it to boot from the live volume, but not reliably, for some reason. I've found that the best workaround is to use diskutil apfs deletesnapshot
to remove all snapshots (thank you to @libneko for this idea). However one sticking point is that diskutil
will sometimes refuse to remove the most recent one. One workaround I've found is to perform this step from an older OS (I used High Sierra) but @libneko has reported it working on the BS install disk too. I've never managed to do that though, since I get an error referring to it being tagged for booting.This will never be an insurmountable problem on our Macs, since there's no full secure boot chain -- nothing verifies the signature onYou miss the point. Currently Big Sur already requires SIP to be disabled in order to allow unsupported legacy kernel extensions to load. If that gets removed by Apple, one would likely have to hack code that loads very early and which probably has some serious signing requirements imposed upon it. Good luck with that.
boot.efi
. Without a signature check at the lowest level, we can just patch out each subsequent check. The whole system falls apart.Awesome @ASentientBot you are the Big Sure Hero keep hope n fighting as always, best of luck man!Alright, these last couple days have been extremely frustrating and confusing, but I think I'm finally getting a handle on how to reliably create a patchable installed Big Sur volume. I owe you all an apology for the partial and/or incorrect info I've shared previously, and I hope this will clear some things up.
I'm going to try to list the issues and solutions in an organized fashion so we can try to get on the same page. It might be useful to move this to the wikipost so we can keep it updated and fix any mistakes that I've made; what do you think?
Hardware checks
These are present both in the installer (theBIErrorDomain error 3
message) and at boot time with the ? prohibitory symbol. The former can be bypassed with OpenCore (which I know very little about, but @jackluke is an expert) or my installer hack here (or the older version). The latter is avoided with-no_compat_check
, either set in NVRAM or the Preboot volume. I think these issues have been largely solved.
Volume sealing
This is the means by which the boot volume is cryptographically signed and modifications are detected. It also seems to be the reason why BS system volumes cannot be mounted under Catalina or older (specifically due to theAPFS_INCOMPAT_SEALED_VOLUME
flag, see here). My latest installer hack turns off sealing (but not snapshots, which is why it failed to fixerror 66
for most people). There doesn't seem to be any way to fully unseal a volume once it's been sealed: snapshots and verification can be turned off, but it will never mount on an older OS since that flag is still present. So the install-time disabling seems like a must.
Snapshots
This causes the notoriouserror 66
when trying to remount the system volume, since/
actually points to a read-only snapshot, not the modifiable "live" version. No install-time patch is known for this yet (I've worked on some things, but with little success -- the snapshot is created byramrod/patchd
in the ramdisk and there isn't a nice flag to disable it like with sealing). My previous hack (based on @mac_4eva's post) sometimes changes it to boot from the live volume, but not reliably, for some reason. I've found that the best workaround is to usediskutil apfs deletesnapshot
to remove all snapshots (thank you to @libneko for this idea). However one sticking point is thatdiskutil
will sometimes refuse to remove the one that's flagged for booting. One workaround I've found is to perform this step from an older OS (I used High Sierra) but @libneko has reported it working on the BS install disk too.
SIP note
The new authenticated-root (ARV) option needs to be disabled for some of the above stuff, and general SIP should always be.
Process
I've reliably gotten a modifiable system a few times in a row using my "Hax2" patch and then booting into High Sierra to delete the snapshots, as described above. This reliably eliminates both sealing and snapshots. But please share any alternative methods and/or tell me if you still can't get it working. I'd like to finally get to the bottom of this so we can move on to the things that really matter.
One thing I'm still not clear on why sealing/snapshots seem to arbitrarily... just not happen... on some installs. But since ramrod is designed to plow past many errors without stopping, it's likely that those steps simply failed for whatever reason but didn't halt the install. Still weird though.
Sorry for the text wall. I hope this is helpful.
[automerge]1593139324[/automerge]
This will never be an insurmountable problem on our Macs, since there's no full secure boot chain -- nothing verifies the signature onboot.efi
. Without a signature check at the lowest level, we can just patch out each subsequent check. The whole system falls apart.
But that doesn't mean it won't be a pain!
Alright, these last couple days have been extremely frustrating and confusing, but I think I'm finally getting a handle on how to reliably create a patchable installed Big Sur volume. I owe you all an apology for the partial and/or incorrect info I've shared previously, and I hope this will clear some things up.
I'm going to try to list the issues and solutions in an organized fashion so we can try to get on the same page. It might be useful to move this to the wikipost so we can keep it updated and fix any mistakes that I've made; what do you think?
Hardware checks
These are present both in the installer (theBIErrorDomain error 3
message) and at boot time with the ? prohibitory symbol. The former can be bypassed with OpenCore (which I know very little about, but @jackluke is an expert) or my installer hack here (or the older version). The latter is avoided with-no_compat_check
, either set in NVRAM or the Preboot volume. I think these issues have been largely solved.
Volume sealing
This is the means by which the boot volume is cryptographically signed and modifications are detected. It also seems to be the reason why BS system volumes cannot be mounted under Catalina or older (specifically due to theAPFS_INCOMPAT_SEALED_VOLUME
flag, see here). My latest installer hack turns off sealing (but not snapshots, which is why it failed to fixerror 66
for most people). There doesn't seem to be any way to fully unseal a volume once it's been sealed: snapshots and verification can be turned off, but it will never mount on an older OS since that flag is still present. So the install-time disabling seems like a must.
Snapshots
This causes the notoriouserror 66
when trying to remount the system volume, since/
actually points to a read-only snapshot, not the modifiable "live" version. No install-time patch is known for this yet (I've worked on some things, but with little success -- the snapshot is created byramrod/patchd
in the ramdisk and there isn't a nice flag to disable it like with sealing). My previous hack (based on @mac_4eva's post) sometimes changes it to boot from the live volume, but not reliably, for some reason. I've found that the best workaround is to usediskutil apfs deletesnapshot
to remove all snapshots (thank you to @libneko for this idea). However one sticking point is thatdiskutil
will sometimes refuse to remove the most recent one. One workaround I've found is to perform this step from an older OS (I used High Sierra) but @libneko has reported it working on the BS install disk too. I've never managed to do that though, since I get an error referring to it being tagged for booting.
SIP note
The new authenticated-root (ARV) option needs to be disabled for some of the above stuff, and general SIP should always be.
Process
I've reliably gotten a modifiable system a few times in a row using my "Hax2" patch and then booting into High Sierra to delete the snapshots, as described above. This reliably eliminates both sealing and snapshots. But please share any alternative methods and/or tell me if you still can't get it working. I'd like to finally get to the bottom of this so we can move on to the things that really matter.
One thing I'm still not clear on is why sealing/snapshots seem to arbitrarily... just not happen... on some installs. But since ramrod is designed to plow past many errors without stopping, it's likely that those steps simply failed for whatever reason but didn't halt the install. Still weird though.
Sorry for the text wall. I hope this is helpful.
[automerge]1593139324[/automerge]
This will never be an insurmountable problem on our Macs, since there's no full secure boot chain -- nothing verifies the signature onboot.efi
. Without a signature check at the lowest level, we can just patch out each subsequent check. The whole system falls apart.
But that doesn't mean it won't be a pain!
Awesome Asentientbot you are the Big Sure Hero keep hope n fighting as always, best of luck man!
Sure man you must have right to edit wikipost
Thanks guys, I appreciate all the positivity even after I've spent the last couple days mostly being confused. And yes I'm able to edit the wikipost, but I didn't want to unilaterally decide to stuff a bunch of possibly-incorrect text in there before it was checked over a bit.I just want to say thank you for all that you do to keep our old Macs alive. Your hard work is appreciated by us all.
Someone told me this online- doesn’t need a patch just an opencore boot loader efi on a usb installer with all booted quirks turned off and a spoofed smbios of imacpro 1,1 after the install it’s no longer needed just need -no_compat_check in nvram. I don’t know if this helps?This thread will be used to discuss advancements in getting macOS 11.0 Big Sur running on unsupported Macs.
---
Compatibility List:
Macs officially compatible with macOS Big Sur:
Macs officially compatible with macOS Catalina but have been dropped from official support in macOS Big Sur:
- 2015 and later MacBook
- 2013 and later MacBook Air
- Late 2013 and later MacBook Pro
- 2014 and later iMac
- 2017 and later iMac Pro
- 2014 and later Mac mini
- 2013 and later Mac Pro
- These Macs so far are capable of running Big Sur properly, but Wifi support is currently broken. See FAQ for more information.
*Not officially supported in macOS Catalina, but are fully capable of running both Catalina and Big Sur with a Metal-compatible GPU and upgraded Wifi/BT card.
- 2012 and Early 2013 MacBook Pro
- 2012 MacBook Air
- 2012 and 2013 iMac
- 2012 Mac mini
- 2008-2012 Mac Pro*
Macs capable of being patched to run macOS Catalina properly and potentially can be patched to run macOS Big Sur:
- These Macs so far can boot Big Sur, but do not currently feature Wifi or graphical acceleration support. See FAQ for more information.
*Not officially supported in macOS Catalina, but are fully capable of running both Catalina and Big Sur with a Metal-compatible GPU and upgraded Wifi/BT card.
- Early-2008 or newer Mac Pro, iMac, or MacBook Pro:
- MacPro3,1*
- MacPro4,1*
- MacPro5,1*
- iMac8,1
- iMac9,1
- iMac10,x
- iMac11,x (systems with AMD Radeon HD 5xxx and 6xxx series GPUs were almost unusable when running Catalina and will be under Big Sur as well.)
- iMac12,x (systems with AMD Radeon HD 5xxx and 6xxx series GPUs were almost unusable when running Catalina and will be under Big Sur as well.)
- MacBookPro4,1
- MacBookPro5,x
- MacBookPro6,x
- MacBookPro7,x
- MacBookPro8,x
- Late-2008 or newer MacBook Air or Aluminum Unibody MacBook:
- MacBookAir2,1
- MacBookAir3,x
- MacBookAir4,x
- MacBook5,1
- Early-2009 or newer Mac Mini or white MacBook:
- Macmini3,1
- Macmini4,1
- Macmini5,x (systems with AMD Radeon HD 6xxx series GPUs were almost unusable when running Catalina and will be under Big Sur as well.)
- MacBook5,2
- MacBook6,1
- MacBook7,1
- Early-2008 or newer Xserve:
- Xserve2,1*
- Xserve3,1*
Macs that WILL NOT BE SUPPORTED in any capacity:
- 2006-2007 Mac Pros, iMacs, MacBook Pros, and Mac Minis:
- MacPro1,1
- MacPro2,1
- iMac4,1
- iMac5,x
- iMac6,1
- iMac7,1
- MacBookPro1,1
- MacBookPro2,1
- MacBookPro3,1
- Macmini1,1
- Macmini2,1
- — The 2007 iMac 7,1 is compatible with Catalina and potentially Big Sur if the CPU is upgraded to a Penryn-based Core 2 Duo, such as a T9300.
- 2006-2008 MacBooks:
- MacBook1,1
- MacBook2,1
- MacBook3,1
- MacBook4,1
- 2008 MacBook Air (MacBookAir 1,1)
- All PowerPC-based Macs
---
FAQ:
Q: Why did Apple drop support for my perfectly capable Mac?
A: Only Apple can give a definite answer to this. However there is evidence that it is based upon the CPUs being used in the now-unsupported Macs, which was the case last year with the Mac Pro 4,1/5,1. Intel decided to stop releasing firmware security fixes for Ivy Bridge and previous-generation CPUs. While they are technically compatible and supported in Big Sur, Apple has decided it is not worth the risk to continue supporting CPUs that have permanently unpatched security holes, putting users at risk.
While this is also not confirmed, another possibility could be that some of the excluded Macs feature Wifi chips that are no longer deemed fit for the next major release. This decision could be based on the previously mentioned security issues as well. The presence of graphics drivers for some of these newly unsupported Macs in Big Sur Beta 1 suggests this.
Q: Will my unsupported Mac get macOS 11.0 Big Sur?
A: If your Mac had official support in macOS Catalina, they will likely be able to be patched to run Big Sur with minimal issues. As of writing, only WiFi appears to be broken.
If your Mac was unsupported before the release of macOS Catalina, support remains to be seen as graphics acceleration may not be feasible at this time. While Catalina still supported OpenGL (former macOS graphical API) and even used it as a fallback software render mechanism, Big Sur officially drops support and shifts to Apple's Metal API entirely.
Q: When will my unsupported Mac receive macOS 11.0 Big Sur? / ETA when?
A: This is a community driven effort to try and restore support for various unsupported Macs. Community members are working as hard as they can, often in their spare time, to try and add back stable support for these Macs. Based upon changes in macOS Big Sur, it may be possible some Macs that were previously patchable in Mojave, Catalina, and other previous releases of macOS may not be patchable under Big Sur. Please do not harass the patch developers to go faster, release the patcher, etc. Please do not clog up the thread with useless posts asking if your specific Mac will be patchable. Big Sur was only just released in its initial beta form and a lot is still subject to change before the final release. Rest assured, the dedicated community of developers working on these patches are doing everything that they can to re-add support for as many Macs as possible.
Q: Where/how can I download macOS 11.0 Big Sur?
A: For legal purposes, the only official way to obtain a copy of macOS Big Sur is to be a registered Apple Developer and pay a yearly $99 fee to become eligible for downloading beta software. According to Apple, a public beta which does not require a registered Developer account will be released at some point in July and will be free to sign up for. Please remember it is highly suggested that you do not install beta software on your main devices, overwriting any stable releases. Beta software can cause irreparable hardware damage or irrecoverable data loss and should be used at one's own risk.
Apple and all patch developers are not responsible for any potential damage or data loss caused by using pre-release software or unofficial support patches. Please use at your own risk.
You are the man Asentientbot will everything you do to help us keep or old Mac's up and running . you and may others here are just awesome and hope one day soon pkouame will be onboard as wellAlright, these last couple days have been extremely frustrating and confusing, but I think I'm finally getting a handle on how to reliably create a patchable installed Big Sur volume. I owe you all an apology for the partial and/or incorrect info I've shared previously, and I hope this will clear some things up.
I'm going to try to list the issues and solutions in an organized fashion so we can try to get on the same page. It might be useful to move this to the wikipost so we can keep it updated and fix any mistakes that I've made; what do you think?
Hardware checks
These are present both in the installer (theBIErrorDomain error 3
message) and at boot time with the ? prohibitory symbol. The former can be bypassed with OpenCore (which I know very little about, but @jackluke is an expert) or my installer hack here (or the older version). The latter is avoided with-no_compat_check
, either set in NVRAM or the Preboot volume. I think these issues have been largely solved.
Volume sealing
This is the means by which the boot volume is cryptographically signed and modifications are detected. It also seems to be the reason why BS system volumes cannot be mounted under Catalina or older (specifically due to theAPFS_INCOMPAT_SEALED_VOLUME
flag, see here). My latest installer hack turns off sealing (but not snapshots, which is why it failed to fixerror 66
for most people). There doesn't seem to be any way to fully unseal a volume once it's been sealed: snapshots and verification can be turned off, but it will never mount on an older OS since that flag is still present. So the install-time disabling seems like a must.
Snapshots
This causes the notoriouserror 66
when trying to remount the system volume, since/
actually points to a read-only snapshot, not the modifiable "live" version. No install-time patch is known for this yet (I've worked on some things, but with little success -- the snapshot is created byramrod/patchd
in the ramdisk and there isn't a nice flag to disable it like with sealing). My previous hack (based on @mac_4eva's post) sometimes changes it to boot from the live volume, but not reliably, for some reason. I've found that the best workaround is to usediskutil apfs deletesnapshot
to remove all snapshots (thank you to @libneko for this idea). However one sticking point is thatdiskutil
will sometimes refuse to remove the most recent one. One workaround I've found is to perform this step from an older OS (I used High Sierra) but @libneko has reported it working on the BS install disk too. I've never managed to do that though, since I get an error referring to it being tagged for booting.
SIP note
The new authenticated-root (ARV) option needs to be disabled for some of the above stuff, and general SIP should always be.
Process
I've reliably gotten a modifiable system a few times in a row using my "Hax2" patch and then booting into High Sierra to delete the snapshots, as described above. This reliably eliminates both sealing and snapshots. But please share any alternative methods and/or tell me if you still can't get it working. I'd like to finally get to the bottom of this so we can move on to the things that really matter.
One thing I'm still not clear on is why sealing/snapshots seem to arbitrarily... just not happen... on some installs. But since ramrod is designed to plow past many errors without stopping, it's likely that those steps simply failed for whatever reason but didn't halt the install. Still weird though.
Sorry for the text wall. I hope this is helpful.
[automerge]1593139324[/automerge]
This will never be an insurmountable problem on our Macs, since there's no full secure boot chain -- nothing verifies the signature onboot.efi
. Without a signature check at the lowest level, we can just patch out each subsequent check. The whole system falls apart.
But that doesn't mean it won't be a pain!
Edit: Oh, I guess you meant contributions to acceleration. Whoops, I misread your message, sorry. Edit-edit: Or did I read it right the first time? I don't know. I think I need to take a break.Hoping to finally make some progress on acceleration over the next few days, now that the worst of the install BS (lol) is dealt with. But it's certainly going to be tricky. If anyone else (looking at you, @pkouame, @testheit and @parrotgeek1, among others) has some ideas or contributions, they will be more than welcome. I'm feeling way out of my depth haha.
I get what your saying. But iv been doing hackintoshes and unsupported Mac stuff for years. I don't know how many times iv seen people fret over things that Apple has done that could potentially stop that stuff. Yet....here we are lolYou miss the point. Currently Big Sur already requires SIP to be disabled in order to allow unsupported legacy kernel extensions to load. If that gets removed by Apple, one would likely have to hack code that loads very early and which probably has some serious signing requirements imposed upon it. Good luck with that.
Thanks a lot for all the time you put into this. Keep up the great work man!Alright, these last couple days have been extremely frustrating and confusing, but I think I'm finally getting a handle on how to reliably create a patchable installed Big Sur volume. I owe you all an apology for the partial and/or incorrect info I've shared previously, and I hope this will clear some things up.
I'm going to try to list the issues and solutions in an organized fashion so we can try to get on the same page. It might be useful to move this to the wikipost so we can keep it updated and fix any mistakes that I've made; what do you think?
Hardware checks
These are present both in the installer (theBIErrorDomain error 3
message) and at boot time with the ? prohibitory symbol. The former can be bypassed with OpenCore (which I know very little about, but @jackluke is an expert) or my installer hack here (or the older version). The latter is avoided with-no_compat_check
, either set in NVRAM or the Preboot volume. I think these issues have been largely solved.
Volume sealing
This is the means by which the boot volume is cryptographically signed and modifications are detected. It also seems to be the reason why BS system volumes cannot be mounted under Catalina or older (specifically due to theAPFS_INCOMPAT_SEALED_VOLUME
flag, see here). My latest installer hack turns off sealing (but not snapshots, which is why it failed to fixerror 66
for most people). There doesn't seem to be any way to fully unseal a volume once it's been sealed: snapshots and verification can be turned off, but it will never mount on an older OS since that flag is still present. So the install-time disabling seems like a must.
Snapshots
This causes the notoriouserror 66
when trying to remount the system volume, since/
actually points to a read-only snapshot, not the modifiable "live" version. No install-time patch is known for this yet (I've worked on some things, but with little success -- the snapshot is created byramrod/patchd
in the ramdisk and there isn't a nice flag to disable it like with sealing). My previous hack (based on @mac_4eva's post) sometimes changes it to boot from the live volume, but not reliably, for some reason. I've found that the best workaround is to usediskutil apfs deletesnapshot
to remove all snapshots (thank you to @libneko for this idea). However one sticking point is thatdiskutil
will sometimes refuse to remove the most recent one. One workaround I've found is to perform this step from an older OS (I used High Sierra) but @libneko has reported it working on the BS install disk too. I've never managed to do that though, since I get an error referring to it being tagged for booting.
SIP note
The new authenticated-root (ARV) option needs to be disabled for some of the above stuff, and general SIP should always be.
Process
I've reliably gotten a modifiable system a few times in a row using my "Hax2" patch and then booting into High Sierra to delete the snapshots, as described above. This reliably eliminates both sealing and snapshots. But please share any alternative methods and/or tell me if you still can't get it working. I'd like to finally get to the bottom of this so we can move on to the things that really matter.
One thing I'm still not clear on is why sealing/snapshots seem to arbitrarily... just not happen... on some installs. But since ramrod is designed to plow past many errors without stopping, it's likely that those steps simply failed for whatever reason but didn't halt the install. Still weird though.
Sorry for the text wall. I hope this is helpful.
[automerge]1593139324[/automerge]
This will never be an insurmountable problem on our Macs, since there's no full secure boot chain -- nothing verifies the signature onboot.efi
. Without a signature check at the lowest level, we can just patch out each subsequent check. The whole system falls apart.
But that doesn't mean it won't be a pain!
Thats good info to know. But that is only going to get it installed. There still has to be patches made to fix acceleration and brightness controls (among other things). But using open core may be a better option for people having a problem getting it installed. at least until there is an install tool from this great group of peopleSomeone told me this online- doesn’t need a patch just an opencore boot loader efi on a usb installer with all booted quirks turned off and a spoofed smbios of imacpro 1,1 after the install it’s no longer needed just need -no_compat_check in nvram. I don’t know if this helps?
InstallAssistant.pkg
file and installed the package sudo defaults write /Library/Preferences/com.apple.security.libraryvalidation.plist DisableLibraryValidation -bool true
command (for disabling Library Validation)launchctl setenv DYLD_INSERT_LIBRARIES $PWD/Hax.dylib
commandInstall macOS Beta.app
fileSomeone told me this online- doesn’t need a patch just an opencore boot loader efi on a usb installer with all booted quirks turned off and a spoofed smbios of imacpro 1,1 after the install it’s no longer needed just need -no_compat_check in nvram. I don’t know if this helps?
If you're getting "crossed circle", then:Hello everyone, I've just
1. Disabled SIP from Recovery Mode
2. Downloaded theInstallAssistant.pkg
file and installed the package
3. Downloaded the ASentientBot "really simple installer hack" file
4. ransudo defaults write /Library/Preferences/com.apple.security.libraryvalidation.plist DisableLibraryValidation -bool true
command (for disabling Library Validation)
5. ranlaunchctl setenv DYLD_INSERT_LIBRARIES $PWD/Hax.dylib
command
6. OpenedInstall macOS Beta.app
file
7. Selected Macintosh HD as installation disk
The installer automatically rebooted my mac (Macbook Pro 15, Mid 2010) and booted the installer partition, but when Apple logo shows up the system crashes and reboots, crashing again.
What can I do?
(I'm running macOs Catalina now)
No, there is no crossed circle, I can see the Apple logo for 2/3 seconds, but after this time the installer crashesIf you're getting "crossed circle", then:
sudo nvram boot-args="-no_compat_check"
Penryn?No, there is no crossed circle, I can see the Apple logo for 2/3 seconds, but after this time the installer crashes
In niccoloboano's case (MBP 15" 2010) it's Arrandale, not Penryn, but either way it's pre-Sandy Bridge, so I wouldn't be surprised if it's the telemetry plugin.Penryn?
something kind of stupid. But I kinda hope that have a ssd pic for ssd drive
View attachment 927839
Hello everyone, I've just
1. Disabled SIP from Recovery Mode
2. Downloaded theInstallAssistant.pkg
file and installed the package
3. Downloaded the ASentientBot "really simple installer hack" file
4. ransudo defaults write /Library/Preferences/com.apple.security.libraryvalidation.plist DisableLibraryValidation -bool true
command (for disabling Library Validation)
5. ranlaunchctl setenv DYLD_INSERT_LIBRARIES $PWD/Hax.dylib
command
6. OpenedInstall macOS Beta.app
file
7. Selected Macintosh HD as installation disk
The installer automatically rebooted my mac (Macbook Pro 15, Mid 2010) and booted the installer partition, but when Apple logo shows up the system crashes and reboots, crashing again.
What can I do?
(I'm running macOs Catalina now)
So there's no method to boot Big Sur from my computer or there are some fixes?Arrandale cpu i5 (and I guess i7 too) on BigSur either USB Installer or installation causes a kernel panic at early boot due to:
AppleACPICPU , AppleACPIPlatform and maybe any other *ACPI* related kext
Arrandale cpu till Catalina can use the stock telemetry.plugin so it's not the case to remove it.
Currently Arrandale cpu are not able to boot BigSur kernel, while instead a Penryn Core2Duo cpu can.
Not totally sure if this early kernel panic after BigSur kernel initialization is related also to the Dual GPUs, but I'd exclude, rather I guess it's the Arrandale architecture the issue for booting BigSur.