Jump to content

OpenCore General Discussion

dgsga

By dgsga,
in OpenCore

 Share
8,888 posts in this topic

Recommended Posts

Cyberdevs
Cyberdevs
Posted
Posted
41 minutes ago, Download-Fritz said:

Cannot you all read even the Errata doc when tinkering with obviously experimental Betas? You use KC, it is not supported, a workaround is literally spilled out for you in the PDF.

The error I have is not for a preinstalled macOS 11, it's for the USB Installer I'm aware of that workaround for booting into the preinstalled version of BigSur and with those values in the config the installer will end up in a never ending loop of SIGABRT error.

 

24 minutes ago, Synapsis said:

a picture tell 1000 words

or even better one

Or how about you have a little decency and don't get involved in the matters that doesn't concern you?

  • Like 2
Link to comment
Share on other sites
MacNB
MacNB
Posted
Posted
1 hour ago, Cyberdevs said:

No it wasted to 67 (decimal) which is 0x43 (hex) I double checked and even though I changed it to  127 (decimal) 0x7F (hex) the log is the same.

OC won't boot much after: 


14:784 00:239 AAPL: [EB|`LD:LKC] BPDK,!R -> (System\Library\KernelCollections\BootKernelExtensions.kc)
16:866 02:081 OCAK: Failed to locate _xcpm_core_scope_msrs - Not Found

and the system halts there, so I guess there is nothing else to be logged. Correct me if I'm wrong.

 

The config.plist you posted shows:
377890771_Screenshot2020-06-30at15_28_36.thumb.png.93e753dc6b8572c60d15b850dde9c7bb.png

 

Where the target was set to 0x03.

If you have changed it 0x43 or 0x7F then there should be a lot more info in the log than just the Apple log.

Are you sure you are using DEBUG version of OC ?

  • Like 1
Link to comment
Share on other sites
SavageAUS
SavageAUS
Posted
Posted

I don’t want to be o/t here but is the preinstalled method spoken of the one where you install a vm to a physical disk? Or preinstalled on real Mac then transplanted?
Again sorry if o/t.


Sent from my iPhone using Tapatalk

Link to comment
Share on other sites
Cyberdevs
Cyberdevs
Posted
Posted
1 minute ago, MacNB said:

 

The config.plist you posted shows:
377890771_Screenshot2020-06-30at15_28_36.thumb.png.93e753dc6b8572c60d15b850dde9c7bb.png

 

Where the target was set to 0x03.

If you have changed it 0x43 or 0x7F then there should be a lot more info in the log than just the Apple log.

Are you sure you are using DEBUG version of OC ?

I'm using the latest compiled version of the OC (Release not Debug) and the config I posted was from before I managed to get the logging to work so that explains why the value is set to 0x03. I'll give the debug version a try later and see if I can gather more data.

 

Thanks for your help.

  • Like 1
Link to comment
Share on other sites
mhaeuser
mhaeuser
Posted
Posted

@Cyberdevs There is nothing to be seen in the log... KC is not supported for kernel patches (albeit support got slightly extended, hence it dies later now) and that's exactly what you're trying to do as obvious from the XCPM line. It does not work and it did not work before either (albeit it might have ignored instead of error'd a few commits ago). Do not use KC with OC for now, as expressed in the docs.

  • Like 1
Link to comment
Share on other sites
Cyberdevs
Cyberdevs
Posted
Posted
Just now, Download-Fritz said:

@Cyberdevs There is nothing to be seen in the log... KC is not supported for kernel patches (albeit support got slightly extended, hence it dies later now) and that's exactly what you're trying to do as obvious from the XCPM line. It does not work and it did not work before either (albeit it might have ignored instead of error'd a few commits ago). Do not use KC with OC for now, as expressed in the docs.

Yes I figured as much, definitely something has changed in the OC because I was able to boot into the 10.11 installer on my Haswell rig using OC's build from few days back and about 10 minutes after the installation process starts (I assume that's were the installation tries to reboot) the system freezes up so I've been following the latest builds to see if I can boot into the installer again or not. I will produce more information on the working OC if you like later because right now I'm in the middle of something on my Haswell rig right now.

 

Thanks for the explanation anyway.

  • Like 1
Link to comment
Share on other sites
ghost8282
ghost8282
Posted
Posted (edited)
5 minutes ago, Cyberdevs said:

I will produce more information on the working OC if you like later

Unfortunately, as already reported, there's no version of oc that can boot AND install big sur from an installation media on an hackintosh, no workarounds as of today maybe tomorrow :P ?

Edited by ghost8282
  • Like 1
Link to comment
Share on other sites
Cyberdevs
Cyberdevs
Posted
Posted
1 minute ago, ghost8282 said:

Unfortunately, as already reported, there's no version of oc that can boot AND install big sur from an installation media on an hackintosh, no workarounds as of today.

Yes I know, the not being able to boot into the installer part is something that I'm curious to know why I was able to boot into it before. The can't be able to install Big Sur isn't much of surprise because there's a lot of changes under the hood of Big Sur so it'll take some time until they crack it.

Link to comment
Share on other sites
ltooz_audis
ltooz_audis
Posted
Posted

Yesterday I've tried OpenCore on my Desktop Dell Inspiron 3668 i5-7400 Kabylake with Catalina 15.5, I couldn't get any USB port to work, no keyboard or mouse, all physical ports. I did use USBInjectAll.kext, SSDT-USBX.aml, SSDT-EC-USBX.aml, SSDT-PLUG.aml. Even used SSDT-UAIC-ALL.aml from Rehabman and nothing seems to turn on the USB ports. Some tips on what else to try would be greatly appreciated.

Thanks,

Louis

Link to comment
Share on other sites
Synapsis
Synapsis
Posted
Posted
1 hour ago, Cyberdevs said:

The error I have is not for a preinstalled macOS 11, it's for the USB Installer I'm aware of that workaround for booting into the preinstalled version of BigSur and with those values in the config the installer will end up in a never ending loop of SIGABRT error.

 

Or how about you have a little decency and don't get involved in the matters that doesn't concern you?

Dont take stuff literally, especially from meme pictures. If that offends you - I apologize - I meant it like a joke.

 

  • Thanks 1
Link to comment
Share on other sites
luky35
luky35
Posted
Posted

Please OpenCore for my configuration if possible for macOS Big Sur

 

My PC configuration:

PU: Intel Core i5-6500 Codename Skylake5 Socket H4 ( LGA 1151 )

GPU: Intel HD Graphic 530

Motherboard: Lenovo Skylake Chipset Intel Q170 ( Skylake PCH-H )

Network: Intel Ethernet Connection I219-LM Intel Dual band

Wireless-AC 8260 AC 2x2 Wifi Adapter

Audio: Realtec, Intel SKYLAKE PCH-H High Definition Audio Controler

Memory: 2x8GB PC4 DDR4-2400 /PC4-19200

Disk: Samsung 256 GB SSD

 

Thanks a lot in advance.

  • Sad 1
Link to comment
Share on other sites
vit9696
vit9696
Posted
Posted (edited)
18 hours ago, MacNB said:

 

Hi @Rodion2010

 

1. WriteFlash = False. But does not seem to make any difference if I set it to True.

2. nvram 8BE4DF61-93CA-11D2-AA0D-00E098032B8C:Boot0080 does not show different value when switching via Startup disk selection.
    However, nvram efi-boot-device variable does change AFTER Startup Disk selection (just before reboot). It's ASCII (?) and not Base64.

4. When I ran your logouthook manually, it creates nvram.plist but not with the correct Boot0080 value that does not match efi-boot-device  (see attached) logs below.

3. Ok. I ran some more test & boots and attach lots of logs & nvram files (filenames indicates what I did). These are the steps:

It looks like Startup disk selection saved in efi-boot-device and efi-boot-device-data variables are not being "transferred" to Boot0080 variable. I think the original logouthook script attempted that but your modified version does not. 

 

Apologies if there's too much data but I tried to be comprehensive and hope my explanation makes sense. You did ask for more logs :)

CC: @vit9696

 

Thanks

This is definitely not our DuetPkg booting. Our DuetPkg does not create tons of entries like:

01:391 00:002 OCB: MacNB: InternalGetBootOptionData: Post GetVariable2 call. Status == Success
01:393 00:002 OCB: 0 -> Boot0000 = PcieRoot(0x0)/Pci(0x1F,0x2)/Sata(0x4,0x0,0x0)
01:397 00:003 OCB: MacNB: InternalGetBootOptionData: Post GetVariable2 call. Status == Success
01:399 00:002 OCB: 1 -> Boot0001 = PcieRoot(0x0)/Pci(0x1D,0x7)/USB(0x4,0x0)/Unit(0x0)

 

Our DuetPkg will also never ever add PcieRoot entries, will always be PciRoot. You have some Clover garbage here or very older Duet, based on Clover EFI. Furthermore, WriteFlash must be YES if you want preference pane to work.

Edited by vit9696
  • Like 1
  • Thanks 1
Link to comment
Share on other sites
Tiem
Tiem
Posted
Posted (edited)
1 hour ago, vit9696 said:

You have some Clover garbage here or very older Duet, based on Clover EFI.

Hey vit out of curiosity how would you fix this?

Edited by Tiem
Link to comment
Share on other sites
MacNB
MacNB
Posted
Posted (edited)
6 hours ago, Rodion2010 said:

what version of Duet (boot) do you use? is it the newest one?

new files

https://github.com/acidanthera/OpenCorePkg/tree/master/Utilities/LegacyBoot

 

I started by downloading OC Debug Release 0.6.0 and used the the bootinstall.command.

That command ran OK but I could not boot as the OC Boot Picker did not list any SATA drives.

I had to change the boot file in the EFI partition to one from the one you posted here:

I have been using that boot file for the testing so for.

 

Just now, I downloaded OC Debug Release 0.6.0 again and ran BootInstall.command again. Here's the output: 


SR-Mac-530:LegacyBoot MacNB$ sudo ./BootInstall.command
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                  Apple_HFS OSX-SL                  803.3 GB   disk0s2
   3:                  Apple_HFS OSX-SR-HDD              152.8 GB   disk0s3
   4:                 Apple_Boot Recovery HD             650.0 MB   disk0s4
   5:                  Apple_HFS OSX-YS                  42.4 GB    disk0s5
   6:                 Apple_Boot Recovery HD             650.0 MB   disk0s6

/dev/disk1 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *250.1 GB   disk1
   1:                        EFI EFI                     209.7 MB   disk1s1
   2:                  Apple_HFS EVO250                  149.6 GB   disk1s2
   3:                 Apple_Boot Recovery HD             650.0 MB   disk1s3
   4:       Microsoft Basic Data WIN10                   99.1 GB    disk1s4
   5:           Windows Recovery                         506.5 MB   disk1s5

/dev/disk2 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *1.0 TB     disk2
   1:                        EFI EFI                     209.7 MB   disk2s1
   2:       Microsoft Basic Data WIN10                   865.3 GB   disk2s2
   3:           Windows Recovery                         471.9 MB   disk2s3
   4:                  Apple_HFS EC-530-1                133.6 GB   disk2s4
   5:                 Apple_Boot Recovery HD             650.0 MB   disk2s5

Enter disk number to install to:
1
MS-DOS FAT32

	-----------------------------------------------------
	------ ATTENTION - UPDATING MASTER BOOT RECORD ------
	-----------------------------------------------------

Do you wish to write new MBR? [n] y
disk1s1 was already unmounted
1+0 records in
1+0 records out
512 bytes transferred in 0.000317 secs (1614649 bytes/sec)
boot1f32 -> newbs
87+0 records in
87+0 records out
87 bytes transferred in 0.000288 secs (302073 bytes/sec)
14+0 records in
14+0 records out
14 bytes transferred in 0.000060 secs (233017 bytes/sec)
1+0 records in
1+0 records out
512 bytes transferred in 0.000238 secs (2151787 bytes/sec)
Volume EFI on disk1s1 mounted
boot -> /Volumes/EFI/boot
SR-Mac-530:LegacyBoot MacNB$

Disk1 has OC install. But I cannot now boot. I get the error:

BOOT MISMATCH!

BOOT FAIL!

 

So I booted via Clover (which is installed on ANOTHER drive - Disk2) and replaced the OC boot file on the OC ESP with the one by @Rodion2010 (linked above) and now I can boot with OC again.

 

 

6 hours ago, vit9696 said:

This is definitely not our DuetPkg booting. Our DuetPkg does not create tons of entries like:

01:391 00:002 OCB: MacNB: InternalGetBootOptionData: Post GetVariable2 call. Status == Success
01:393 00:002 OCB: 0 -> Boot0000 = PcieRoot(0x0)/Pci(0x1F,0x2)/Sata(0x4,0x0,0x0)
01:397 00:003 OCB: MacNB: InternalGetBootOptionData: Post GetVariable2 call. Status == Success
01:399 00:002 OCB: 1 -> Boot0001 = PcieRoot(0x0)/Pci(0x1D,0x7)/USB(0x4,0x0)/Unit(0x0)

 

Our DuetPkg will also never ever add PcieRoot entries, will always be PciRoot. You have some Clover garbage here or very older Duet, based on Clover EFI. Furthermore, WriteFlash must be YES if you want preference pane to work.

 

I had removed Clover & cleaned up using https://github.com/dortania/OpenCore-Desktop-Guide/tree/master/clover-conversion guide.

Those debug statements in the Log with MacNB: tags were my temporary additions to the OC sources in an effort to debug the problem (I mentioned this to you previously). 

BUT the others entries in the log such as 01:393 00:002 OCB: 0 -> Boot0000 = PcieRoot(0x0)/Pci(0x1F,0x2)/Sata(0x4,0x0,0x0) were by OC (not me) as they have a tag OCB:

 

The question I have, is OpenDuetPkg "encapsulated" within the boot file that bootinstall.command installs ?

If so, why does that boot file not boot ?

What does this mean: "BOOT MISMATCH! - Bootstrap partition signature identification failed. BDS code will try to lookup EFI/OC/OpenCore.efi on any partition in 3 seconds" ??

 

Thanks for your perseverance in helping to fix the issue.

Edited by MacNB
corrected the wrong link.
Link to comment
Share on other sites
vit9696
vit9696
Posted
Posted

@MacNB, yes, you cannot have functional os switching with this ancient DuetPkg. You should have said earlier. The issue with boot failure means that you do not have hardware drives visible to the new Duet. Is this some kind of an nForce chipset or anything exotic?

Link to comment
Share on other sites
MacNB
MacNB
Posted
Posted
4 hours ago, vit9696 said:

@MacNB, yes, you cannot have functional os switching with this ancient DuetPkg. You should have said earlier. The issue with boot failure means that you do not have hardware drives visible to the new Duet. Is this some kind of an nForce chipset or anything exotic?

 

Thanks @vit9696. That's a shame. I did mention that I had used @Rodion2010's old boot file when I first reported the issue here.

The Intel Chipset is G33 with ICH10. In the DSDT, for the SATA Device I have to inject a device-id { 0x81, 0x26, 0x00, 0x00 } (otherwise I get macOS says "Still waiting for root". I think it was known as ESB2 SATA device.

 

If Rodion's old duet boot file sees my SATA drives, what has changed in the OpenDuetPkg to stop it ?

Is there a solution ?

Thanks.

Link to comment
Share on other sites
vit9696
vit9696
Posted
Posted

I must have overlooked this, as this is unsupported, and related logs make no sense afterwards. A lot changed since then, and the SATA driver is now very different. We could try to debug this in private, but I am not yet fully positive when. I will create a PM and will post some test builds sooner or later.

  • Thanks 1
Link to comment
Share on other sites
MacNB
MacNB
Posted
Posted
16 minutes ago, vit9696 said:

I must have overlooked this, as this is unsupported, and related logs make no sense afterwards. A lot changed since then, and the SATA driver is now very different. We could try to debug this in private, but I am not yet fully positive when. I will create a PM and will post some test builds sooner or later.

 

Thanks. You are a Star

Link to comment
Share on other sites
Rodion2010
Rodion2010
Posted
Posted
1 hour ago, MacNB said:

 

Thanks @vit9696. That's a shame. I did mention that I had used @Rodion2010's old boot file when I first reported the issue here.

The Intel Chipset is G33 with ICH10. In the DSDT, for the SATA Device I have to inject a device-id { 0x81, 0x26, 0x00, 0x00 } (otherwise I get macOS says "Still waiting for root". I think it was known as ESB2 SATA device.

 

If Rodion's old duet boot file sees my SATA drives, what has changed in the OpenDuetPkg to stop it ?

Is there a solution ?

Thanks.

my SATA is 00:1f.2 SATA controller [0106]: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA Controller [AHCI mode] [8086:2922] (rev 02) (subsys 1043:8277) and I use device-id <81260000> too, it works Ok

Link to comment
Share on other sites
MacNB
MacNB
Posted
Posted
1 hour ago, Rodion2010 said:

my SATA is 00:1f.2 SATA controller [0106]: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA Controller [AHCI mode] [8086:2922] (rev 02) (subsys 1043:8277) and I use device-id <81260000> too, it works Ok

 

Thanks @Rodion2010. My PCI dumps shows:

 

PCI = [00:1F.2]

Vendor-ID:Device-ID = [8086:2681],

Sub-Vendor:Sub-Device = [1028:020D],

Device Name = [631xESB/632xESB SATA AHCI Controller],

IOReg IO Name = [pci8086,2822] 

 

and I too use device-id <81260000>

 

Is there hope/possibility of adding [8086:2681] to OpenDuet SATA driver ?

 

Link to comment
Share on other sites
pitrysha
pitrysha
Posted
Posted
25 minutes ago, MacNB said:

 

Thanks @Rodion2010. My PCI dumps shows:

 

PCI = [00:1F.2]

Vendor-ID:Device-ID = [8086:2681],

Sub-Vendor:Sub-Device = [1028:020D],

Device Name = [631xESB/632xESB SATA AHCI Controller],

IOReg IO Name = [pci8086,2822] 

 

and I too use device-id <81260000>

 

Is there hope/possibility of adding [8086:2681] to OpenDuet SATA driver ?

 

Maybe you need AHCIPortInjector.kext?

AHCIPortInjector.kext.zip

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...