Jump to content

OpenCore General Discussion

dgsga

By dgsga,
in OpenCore

 Share
8755 posts in this topic

Recommended Posts

miliuco
miliuco
Posted
Posted (edited)
17 minutes ago, 5T33Z0 said:

I didn't translate this. I am the author of this guide! This doesn't exist in the original repo.

Sorry!!! I was wrong. I was thinking you were the author of a translated version. Sorry again.  🙏

Edited by miliuco
joevt
joevt
Posted
Posted
1 hour ago, MacNB said:

 

Great job 👍

 

Did not work for me though. 

 
macnb@DG-MacBook-Pro DiskUtil % source diskutil.sh
macnb@DG-MacBook-Pro DiskUtil % convert_label .disk_label my_test_label.tiff
tr: Illegal byte sequence
macnb@DG-MacBook-Pro DiskUtil %

It created my_test_label.tiff file but it's just black background.

Source label attached.

Destination tiff attached.

 

.disk_label 785 B · 0 downloads my_test_label.tiff 320 B · 0 downloads

Fixed. Needed LANG=C since tr is translating bytes that are not utf-8.

  • Like 1
  • Thanks 1
deeveedee
deeveedee
Posted
Posted (edited)
19 hours ago, miliuco said:

@tonyx86

Although your problem is solved, look at what I’ve found on the OpenCore configuration pdf:

 

How do I customise boot entries?

OpenCore follows standard Apple Bless model and extracts the entry name from .contentDetails and .disk_label.contentDetails files in the booter directory if present. These files contain an ASCII string with an entry title, which may then be customised by the user.

It is precisely this OpenCore doc and the text that you posted that made me think I needed to install the files in /Volumes/EFI/EFI/BOOT here.  For a novice like me, the term "booter directory" in the documentation is ambiguous. Why create the new term "booter directory?"  Thanks to you, @antuneddu and @MacNB, I now understand that the OpenCore reference to "booter directory" is the Preboot directory (which is only exposed as writeable when SIP is disabled) and not the /EFI/BOOT directory.  I found other references with this same confusion, so I don't think I'm alone.  In my opinion, the OpenCore docs should explicitly state Preboot instead of assuming that the reader understands the Apple Bless model and can extrapolate "booter directory" to Preboot.

 

EDIT: Maybe the OpenCore docs should explicitly state /System/Library/CoreServices to be consistent with the Apple developer docs instead of creating the new term "booter directory?"  Not sure - above my pay grade.

Edited by tonyx86
  • Like 3
miliuco
miliuco
Posted
Posted
1 hour ago, tonyx86 said:

... EDIT: Maybe the OpenCore docs should explicitly state /System/Library/CoreServices to be consistent with the Apple developer docs instead of creating the new term "booter directory?"  Not sure - above my pay grade.

You are right, this can create some confusion. When I read your first post on this matter, I also thought in EFI/BOOT as booter directory but, after reading OC pdf, I saw that there is referred to CoreServices in Preboot volume.

Preboot as booter directory is just how Apple sees it. Sometimes we forget that OpenCore tries to look as close to macOS on a real Mac as possible.

I think like you, a clarification in this text in the pdf would be welcome.

 

Apart from that, thinking about disable SIP, I would like to add 2 things that may be useful:

  • Misc >> Security >> AllowToggleSip when true enables Toogle SIP tool in the picker, this tool switch SIP enabled to disabled and vicecersa with a single click and makes it very easy to boot once with SIP disabled without modifying csr-active-config in config.plist.
  • I wrote csr-active-config to FF0F0000 to disable SIP but there is another value that can also be used, 6F020000, this value is applied by OpenCore when running the Toogle SIP or CsrUtil.efi tools.

I have observed that csrutil status, when you set csr-active-config = 0xFFF (FF0F0000 in config.plist) returns unknown state but, when you set csr-active-config = 0x26F (6F020000 in config.plist), returns disabled.

  • Like 2
Stefanalmare
Stefanalmare
Posted
Posted
On 7/14/2021 at 3:22 PM, Stefanalmare said:

Does anybody know how to extract bluetoth keys from Monterey to use in Windows?

Some time ago I asked how can we use Bluetooth devices in dual boot computers after Monterey came, without reconnect them each time. Today I found this but since beta 10 killed my bluetooth on Probook 4540s, I can't test it. Maybe somebody can tell us if it is working.

https://libredd.it/r/hackintosh/comments/p5ost3/macos_monterey_and_windows_bluetooth_pairing/

Stefanalmare
Stefanalmare
Posted
Posted
16 hours ago, Stefanalmare said:

Some time ago I asked how can we use Bluetooth devices in dual boot computers after Monterey came, without reconnect them each time. Today I found this but since beta 10 killed my bluetooth on Probook 4540s, I can't test it. Maybe somebody can tell us if it is working.

https://libredd.it/r/hackintosh/comments/p5ost3/macos_monterey_and_windows_bluetooth_pairing/

It works, but need to read also: https://unix.stackexchange.com/questions/255509/bluetooth-pairing-on-dual-boot-of-windows-linux-mint-ubuntu-stop-having-to-p

After changing key in windows, off/on bluetooth.

  • Like 1
Guest 5T33Z0
Guest 5T33Z0
Posted
Posted

Since I updated to windows 11 on my Lenovo T530, I can no longer boot Windows from within OpenCore. I get a blue screen (well, it's actually black now) about an ACPI error. But the same config worked fine for WIndows 10. It's working fine with clover, too. Same patches and .aml files.

Stefanalmare
Stefanalmare
Posted
Posted
2 hours ago, 5T33Z0 said:

Since I updated to windows 11 on my Lenovo T530, I can no longer boot Windows from within OpenCore. I get a blue screen (well, it's actually black now) about an ACPI error. But the same config worked fine for WIndows 10. It's working fine with clover, too. Same patches and .aml files.

Did you change the ResizeGpuBars from -1 to another value?

Henties
Henties
Posted
Posted

A bios upgrade is available for the GA-Z490 Vision G mobo to address problems with Window 11. I am not planning to install Window 11 on my Vision G rigs so I am quite content staying on bios version F20 for this mobo, at least until Monterey is working the way it should.

A new bios at this juncture would just introduce another unnecessary source for errors making troubleshooting potential problems with

Monterey rather more difficult than need be at this early stage in the life of Monterey. 

Just my 2 cents worth.

 

Greetings Henties

ghost8282
ghost8282
Posted
Posted (edited)

Hi, it seems I have an issue with keyboard/mouse in picker not working if a mac os installer is plugged into one of my usb ports.

I opened an issue in the bugtracker and it seems it's not a configuration issue, so a real bug, mhaeuser thinks about a memory corruption somewhere.

Mike asked me to try to find a scanpolicy value which works with the usb installer plugged in.

 

Before trying different scanpolicy value, it is not clear to me what these 2 bits are:

OC_SCAN_FILE_SYSTEM_LOCK
OC_SCAN_DEVICE_LOCK

 

Both seem to restrict the scanning to the filesystems specified in scanpolicy (OC_SCAN_FILE_SYSTEM_LOCK) and to device types specified in scanpolicy (OC_SCAN_DEVICE_LOCK)

 

So, for example OC_SCAN_FILE_SYSTEM_LOCK + OC_SCAN_DEVICE_LOCK + OC_SCAN_ALLOW_FS_APFS + OC_SCAN_ALLOW_DEVICE_SATA:

means scanning only for apfs filesystem only in sata drives.

 

My question: what does oc scan if the scanpolicy is only OC_SCAN_ALLOW_FS_APFS + OC_SCAN_ALLOW_DEVICE_SATA without the 2 locks?

Will oc scan also for hfs/esp/linux root/linux data/ext boot loader and for sas/scsi/nvme/atapi/usb/firewire/sdcard/virtio but it will not show these results in the picker?

 

Thank you

Edited by ghost8282
SavageAUS
SavageAUS
Posted
Posted
A bios upgrade is available for the GA-Z490 Vision G mobo to address problems with Window 11. I am not planning to install Window 11 on my Vision G rigs so I am quite content staying on bios version F20 for this mobo, at least until Monterey is working the way it should.
A new bios at this juncture would just introduce another unnecessary source for errors making troubleshooting potential problems with
Monterey rather more difficult than need be at this early stage in the life of Monterey. 
Just my 2 cents worth.
 
Greetings Henties

New bios is most likely just setting tpm on by default. At least that’s what it was with my x570.


Sent from my iPhone using Tapatalk
oldman20
oldman20
Posted
Posted
On 10/15/2021 at 3:02 AM, Stefanalmare said:

Some time ago I asked how can we use Bluetooth devices in dual boot computers after Monterey came, without reconnect them each time. Today I found this but since beta 10 killed my bluetooth on Probook 4540s, I can't test it. Maybe somebody can tell us if it is working.

https://libredd.it/r/hackintosh/comments/p5ost3/macos_monterey_and_windows_bluetooth_pairing/

 

On 10/15/2021 at 7:35 PM, Stefanalmare said:

It works, but need to read also: https://unix.stackexchange.com/questions/255509/bluetooth-pairing-on-dual-boot-of-windows-linux-mint-ubuntu-stop-having-to-p

After changing key in windows, off/on bluetooth.

Is it can be trick for make AR3011 working?

 

 

On 10/13/2021 at 8:16 PM, tonyx86 said:

It is precisely this OpenCore doc and the text that you posted that made me think I needed to install the files in /Volumes/EFI/EFI/BOOT here.  For a novice like me, the term "booter directory" in the documentation is ambiguous. Why create the new term "booter directory?"  Thanks to you, @antuneddu and @MacNB, I now understand that the OpenCore reference to "booter directory" is the Preboot directory (which is only exposed as writeable when SIP is disabled) and not the /EFI/BOOT directory.  I found other references with this same confusion, so I don't think I'm alone.  In my opinion, the OpenCore docs should explicitly state Preboot instead of assuming that the reader understands the Apple Bless model and can extrapolate "booter directory" to Preboot.

 

EDIT: Maybe the OpenCore docs should explicitly state /System/Library/CoreServices to be consistent with the Apple developer docs instead of creating the new term "booter directory?"  Not sure - above my pay grade.

 

OMG, i cant find OpenCore doc 0.7.4, how can follow to have latest update?

 

Stefanalmare
Stefanalmare
Posted
Posted
53 minutes ago, oldman20 said:
On 10/14/2021 at 11:02 PM, Stefanalmare said:

Some time ago I asked how can we use Bluetooth devices in dual boot computers after Monterey came, without reconnect them each time. Today I found this but since beta 10 killed my bluetooth on Probook 4540s, I can't test it. Maybe somebody can tell us if it is working.

https://libredd.it/r/hackintosh/comments/p5ost3/macos_monterey_and_windows_bluetooth_pairing/

 

On 10/15/2021 at 3:35 PM, Stefanalmare said:

It works, but need to read also: https://unix.stackexchange.com/questions/255509/bluetooth-pairing-on-dual-boot-of-windows-linux-mint-ubuntu-stop-having-to-p

After changing key in windows, off/on bluetooth.

Is it can be trick for make AR3011 working?

No! For sure my English is very, very bad.

  • Haha 1
oldman20
oldman20
Posted
Posted (edited)
1 hour ago, eSaF said:

https://dortania.github.io/builds/?product=OpenCorePkg&viewall=true

no, i mean this:

https://dortania.github.io/OpenCore-Install-Guide/

It's official but current at 0.7.2, not 0.7.4 like tonyx86's post

Edited by oldman20
miliuco
miliuco
Posted
Posted

@ghost8282

I had read you in the bug tracker. Keyboard and mouse are working well in my hack even changing ScanPolicy to other values.

About your doubt, I've seen that, disabling the 2 first bits (OC_SCAN_FILE_SYSTEM_LOCK and OC_SCAN_DEVICE_LOCK), OpenCore works as before since it can scan all kind of file systems or device types, not only those marked in the other bits. I think that, leaving those 2 bits unchecked, the other bits are irrelevant, don't you?  

  • Like 2
ghost8282
ghost8282
Posted
Posted (edited)

Thanks @miliuco

the issue seems to be specifically related to FL1100 usb chipset + USB 3.0 bootable device directly attached to a usb 3.0 port of the usb controller.

Issue should be in the XhciDxe driver, and it's quite an old bug, I'm reading reports back from 2018.., the issue on bugtracker has been updated with more info, "unfortunately" not related to oc but to edk2/ovmf. "Unfortunately" because most probably if it was directly related to oc it had been fixed in a couple of days max :D

I also opened a bug in edk2 bugtracker, maybe it will be read in the next 2 years..

 

Thanks for the explanation about the bits.

Edited by ghost8282
  • Like 3
  • 3 weeks later...
 Share
Go to topic listing
×
×
  • Create New...