Dell Inspiron 530: Big Sur Installation problem [SOLVED]

[macnb]

@Hervé I looked at your guide here for your Vostro 200 regarding Big Sur installation.

My system is a Dell Inspiron 530 with G33M03 motherboard upgraded with Quad Core Xeon E5450 with nVidia GT730 GPU.

All works great for many many years as an iMac14,2 (Snow Leopard, High Sierra & Catalina) and booting via OpenCore 0.7.2 with emulated NVRAM.

 

I downloaded Big Sur 11.5.2 (using gibMacOS) directly from Apple.

However, when running the Big Sur Installer from booted Catalina 10.15.7 (19H1323), Installer complains "The update cannot be installed on this computer" :

 

All the drives are greyed out.

 

Looking at your config.plist for your Vostro, you use iMac10,1 which also is an unsupported model for Big Sur (just like my iMac14,2).

 

My boot args are set to :

 

-no_compat_check keepsyms=1 dart=0 debug=0x100 npci=0x2000 alcid=1 kext-dev-mode=1

 

-no_compat_check arg does not seem to help.

So how did you manage to install Big Sur ?

Did you patch the installer before hand ?

 

TIA

[Hervé]

-> moved to the Dell desktop support section since this thread is not a guide...

 

Hi @macnb

 

Usually, this error message is returned if the target disk/partition is not of the expected format type; if it's formatted APFS, try to re-format it HFS+ and vice-versa.

 

With regards to the manner in which I installed Big Sur, I believe my Vostro200 guide is crystal clear: I updated my existing Catalina build/partition of the time. No patch of any sort was made to my Big Sur installer. You don't seem to have chosen that specific route so, once you get past the disk/partition format hiccup, I expect you may encounter further problems subsequently like the boot loop known-issue mentioned in my Vostro200 guide.

 

Correct me if I'm wrong but you do not appear to be upgrading your Catalina installation; instead, it looks like you run the Big Sur installation package from Catalina to build a fresh Big Sur installation on a dedicated separate partition. As explained in my Vostro200 guide, this does not work on legacy BIOS systems. You have to actually upgrade an existing Catalina build as detailed in my Vostro200 guide. If you wish to retain your existing Catalina build, I suggest you 1st make a temporary new Catalina installation on your target Big Sur partition and then upgrade that Catalina build to Big Sur.

 

You may install 11.5.2 whilst retaining the SMBIOS of an unsupported iMac alongside the -no_compat_check boot arg. However, you won't be able to subsequently receive Big Sur updates as this requires the SMBIOS of a supported model. I therefore suggest you create a separate config with, say, iMacPro1,1 SMBIOS for the sole purpose of updates. For daily use you may return to iMac14,2 SMBIOS but it's of little/limited use given that OpenCore does not support CPU power management for these kind of Wolfdale/Harpertown C2D/C2Q/Xeon CPUs (no generation of P-States/C-States, unlike Chameleon/Clover). This is the sort of things I do on the Vostro200: SMBIOS iMac10,1 or MacPro3,1 for daily usage and iMacPro1,1 to update Big Sur.

 

You're using old boot arg kext-dev-mode=1; most people still ignore that this was only ever required for Yosemite and has been of absolutely no use in subsequent OS X/macOS versions ever since. You can get rid of this but, of course, this deprecated boot arg causes no harm whatsoever.

[macnb]

Hi @Hervé

Many thanks for the quick reply.

 

First, I indeed installed a fresh copy of Catalina.

Then, I created a new Container. 

I cloned that working Catalina Container to the new Container using CCC. This was so that I could keep Catalina.

The working Catalina drive is called CL-SSD.

The cloned Catalina drive is now called BS-SSD.

 

It's obviously formatted both CL-SSD & BS-SSD as APFS as that's all Catalina does when freshly installed.

Not sure why/how Catalina would work if I reformatted it to HFS+.

If the original partition was HFS+, when yo install Catalina, it will reformat it to APFS as part of the install.

 

Next, I booted cloned drive (called BS-CCD) which works fine and on that booted drive, I am running the Big Sur Installer......i.e. upgrading an existing Catalina build.

So do not understand why BS would complain.

 

4 hours ago, Hervé said:

You may install 11.5.2 whilst retaining the SMBIOS of an unsupported iMac alongside the -no_compat_check boot arg. However, you won't be able to subsequently receive Big Sur updates as this requires the SMBIOS of a supported model. I therefore suggest you create a separate config with, say, iMacPro1,1 SMBIOS for the sole purpose of updates.

 

Yes I am aware of the issues with Updates. Apart from temp iMacPro1,1 SMBIOS config, one could download the complete new BS Update when available and overwrite the existing OS.

 

4 hours ago, Hervé said:

For daily use you may return to iMac14,2 SMBIOS but it's of little/limited use given that OpenCore does not support CPU power management for these kind of Wolfdale/Harpertown C2D/C2Q/Xeon CPUs (no generation of P-States/C-States, unlike Chameleon/Clover). This is the sort of things I do on the Vostro200: SMBIOS iMac10,1 or MacPro3,1 for daily usage and iMacPro1,1 to update Big Sur.

 

Yes power management is not the same as Clover in OpenCore. I used PikerApha's ssdtgen script to create and SSDT for the Xeon E5450.

It's limited to low and High frequencies of 2Ghz and 3Ghz but that's all I got from Clover too.

 

4 hours ago, Hervé said:

You're using old boot arg kext-dev-mode=1; most people still ignore that this was only ever required for Yosemite and has been of absolutely no use in subsequent OS X/macOS versions ever since. You can get rid of this but, of course, this deprecated boot arg causes no harm whatsoever.

 

kext-dev-mode arg is a hangover from the I used to but many different macOS versions.

I recently removed Maverick, Yosemite & El-Capitan and just kept Snow Leopard, High Sierra & Catalina - for nostalgia 

It does not harm however.

 

Anyway, good to know that you did no patching but use vanilla BS Installer.

I just need to figure why my upgrade from Catalina to BS is not working.

[Hervé]

Ok, things are a lot clearer to me now; what you described is 100% Ok and what I had written about the partition format can be ignored, it's obviously irrelevant. The name of your target partition induced me into error and I mistakenly thought you were making a fresh installation on a new "BS-SSD" partition from Catalina running on "CL-SSD".

 

Indeed, having booted a separate Catalina build from the "BS-SSD" partition, I too would have expected the Big Sur installer to proceed as usual, except it may not like/accept your active SMBIOS because it's an upgrade, not a fresh installation. Try switching to a supported SMBIOS before running the Big Sur installer again from Catalina. To be honest, I can't remember doing this when I upgraded to Big Sur but it was version 11.1 back then, not 11.5.2 which may be less tolerant on that front.

 

On the CPU power management front, does a table generated by Pike R Alpha's actually make any change? With Clover, you would probably notice better CPU power management with MacPro3,1 SMBIOS; I certainly do on my Vostro200 with the E8600 (and did too when I ran it with a Xeon X5270).

 

Now that Clover has matured a lot on the Big Sur front, I should probably try and get that old Vostro to boot Big Sur with Clover like several of my other Hacks. 

[macnb]

Yes I think things have changed quite a bit in BS 11.5.2 (and no doubt with the latest 11.6).

Without changing SMBIOS model ID, the only way I could get the Installer to accept the "update" was to set the VMM Flag Bit in the OC config Root::Kernel::Emulate::Cpuid1Data.

That is:

 

This basically tells macOS that it is running in a VM and it's OK to install on that.

 

Install did not go well...lots of hangs & panic...mainly to do with USB.

Then I notice you were using USBInjectAll.kext which I was not as I never needed it on this system.

After installing that in OC, the Install went a bit more smoother and booted fine:

 

BTW, that VMM Flag also enables macOS to detect OTA OS updates. Without it ON, System Preference says that there are no Updates.

With the VMM Flag ON I see:

 

Also, I believe the updates are only the required Delta updates and does not download full blown 12GB+.

That VMM Flag should only used during Installs & updates and turned OFF in normal use as there's a small performance drop (~5%).

 

The biggest issue is USB 1.1 devices.

BS does not recognise any USB 1.1 peripherals when hot plugged.

E.g. for test purposes, plugged in a USB 1.1 Audio dongle and nothing is detected.

If I run IOREGistryExplorer App (or Hackintool), they hang until I unplug the USB 1.1 device.

I have the _isSingleUser kext patch applied to the IOHIDFamily kext.

If the USB 1.1 device (such as a wired mouse) is plugged in before booting, then that device works fine as long as you do not unplug it.

So hot plugging USB 1.1 devices does not work.

USB 2.0 devices work fine.

 

My bluetooth device is an old Apple USB device that is USB 1.1 and that works fine as it is always plugged in.

But...and it's a big but....it breaks sleep. The system does not fully sleep anymore in BS.

Screen goes off and the power light flashes as normal but the fans are still ON.

And, does not wake up on hitting a key on the Apple wireless keyboard or mouse. That implies the USB 1.1 BT device is not detected on wake.

I have a USB 2.0 Apple wired keyboard plugged in and even that cannot wake the system.

 

I booted back into Catalina and used corpnewt's USBMap command to properly I identify all the USB ports and created a USBMap.kext.

This was to replace USBInjectAll.kext as that is only meant to be a temporary kext for identifying the USB ports.

The generated USBMap.kext works well and I can now boot BS everytime. Attached it if you are interested.

 

So the hunt is on to find a Legacy USB 1.1 fix for this rig.

 

USBMap.kext.zip

 

 

On 9/12/2021 at 6:58 PM, Hervé said:

On the CPU power management front, does a table generated by Pike R Alpha's actually make any change? With Clover, you would probably notice better CPU power management with MacPro3,1 SMBIOS; I certainly do on my Vostro200 with the E8600 (and did too when I ran it with a Xeon X5270).

 

I get the same behaviour using Pike R Alpha's SSDT.aml as with Clover's Generate=YES.

With this E5450 Xeon there are not many P-states. I get two: 2Ghz or 3Ghz switching.

 

Running Geekbench 5 on Catalina booted via Clover using Generate = YES:

Running Geekbench 5 on Catalina booted via Clover with Generate=NO and Pike's SSDT.aml power management:

 

 

In both cases, the system idles at 2Ghz as there's low frequency mode on this CPU.

It is the same with OpenCore.