No apfs partition listed for NVME drive

[DreamSeason]

Hi, below is my nvme partition info. I can not see the two apfs partition in the picker. I could only see the "META" partition of HFS type. My nvme drive is HP EX920 1TB with latest OpenCore. Btw, I can see one apfs partition named "LJ" for my SATA drive.

/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_APFS Container disk1 300.0 GB disk0s2 3: Apple_HFS META 212.0 GB disk0s3 4: Apple_APFS Container disk2 511.9 GB disk0s4

My apfs settings are as followed. `APFS

EnableJumpstart GlobalConnect HideVerbose JumpstartHotPlug MinDate -1 MinVersion -1 ` Here's the debug log. [opencore-2021-05-12-034004.txt](https://github.com/acidanthera/bugtracker/files/6464245/opencore-2021-05-12-034004.txt)

[vit9696]

I see at least the Recovery for macOS Catalina being found on an NVMe drive (possibly needs space press to show due to auxiliary). Works as designed, check your drive:

PciRoot(0x0)/Pci(0x1D,0x0)/Pci(0x0,0x0)/NVMe(0x1,00-00-00-00-00-00-00-00)/HD(2,GPT,D245761A-AA99-419D-A5A4-D7B3A3169851,0x64800,0x22ECB258)/VenMedia(BE74FCF7-0B7C-49F3-9147-01F4042E6842,FF02A340B8108640A266035E09140A54)/\16BB40ED-15DE-44E6-8C8A-2B5B6F937B80\
09:643 00:013 OCB: Trying to get label from \16BB40ED-15DE-44E6-8C8A-2B5B6F937B80\.contentDetails
09:651 00:007 OCB: Trying to get label from \16BB40ED-15DE-44E6-8C8A-2B5B6F937B80\.disk_label.contentDetails
09:662 00:011 OCB: Trying to get recovery from \16BB40ED-15DE-44E6-8C8A-2B5B6F937B80\SystemVersion.plist
09:670 00:008 OCB: Registering entry Recovery 10.15.6 (T:4|F:1|G:0|E:0) - PciRoot(0x0)/Pci(0x1D,0x0)/Pci(0x0,0x0)/NVMe(0x1,00-00-00-00-00-00-00-00)/HD(2,GPT,D245761A-AA99-419D-A5A4-D7B3A3169851,0x64800,0x22ECB258)/VenMedia(BE74FCF7-0B7C-49F3-9147-01F4042E6842,FF02A340B8108640A266035E09140A54)/\16BB40ED-15DE-44E6-8C8A-2B5B6F937B80\

[DreamSeason]

Just to make sure, I installed Big Sur onto the last apfs partition of my nvme drive in Catalina 10.15.7. In the past, I would see this partition in clover boot selection to continue the so called "second stage" installtion. But I am not able to find the partition in the info. Is this the way OC supposed to behave?

[vit9696]

I think the installation you created did not reach the bless stage, i.e. it was not written on the Preboot volume. Since OpenCore works exactly like Apple Mac EFI firmware, it will not see it. So yes, the behaviour is correct.

[DreamSeason]

I think the installation you created did not reach the bless stage, i.e. it was not written on the Preboot volume. Since OpenCore works exactly like Apple Mac EFI firmware, it will not see it. So yes, the behaviour is correct.

Thanks for your clarification. But I want to point out that after I manually put apfs.efi from clover into the uefi driver folder, I can see the partition in OC picker. The os paritition UUID is 03DA4C17-E741-4C7B-9EED-702B72D6A062. I understand that OC successfully recognized the recovery partition for this apfs container. But I was quite curious why it would fail to recognize the os paritition in the same apfs container. And with the help of explicit apfs.efi driver, the os patition in the apfs container did show up.

[vit9696]

When blessing happens apfs.efi driver is embedded into the container. Afterwards the firmware (OpenCore for hackintosh) is supposed to open the container, and use the driver exclusively for this container. Since your container with Big Sur was not blessed, there is no apfs.efi driver, and OpenCore is not allowed to use e.g. Catalina apfs.efi driver for Big Sur.

Explicitly loading the apfs.efi driver via Drivers section (and it is not from Clover, but actually from /usr/standalone directory from macOS) applies the apfs.efi driver on all containers, and thus partly workarounds the lack of blessing stage. I will not guarantee there will be no issues with such a setup, but this is a workaround if you really need to use the operating system. It might fix itself when installing an update, but I would not guarantee that either.

[1alessandro1]

@DreamSeason If you installed Catalina with bless support, ensure you have kept the same ApECID if you have two drives or two partitions and only one ESP. Usually, if you install BigSur directly from Catalina to the new drive, you are going to inherit the same 64 bit string used for Catalina

Otherwise, my approach usually is to have separate ESP for separate drives, hence booting Big Sur or anything else other than the first blessed volume with a new ApECID value (or 0) can be possible. To do that, you must use your motherboard boot menu to choose which ESP to use beforehand

[DreamSeason]

@DreamSeason If you installed Catalina with bless support, ensure you have kept the same ApECID if you have two drives or two partitions and only one ESP. Usually, if you install BigSur directly from Catalina to the new drive, you are going to inherit the same 64 bit string used for Catalina

Otherwise, my approach usually is to have separate ESP for separate drives, hence booting with a new ApECID value (or 0) can be possible

Well, your input is well appreciated. I do forget to mention that I was using the esp of my sata drive for OC. Will it stop OC listing the boot partition in the NVME drive?

Usually, if you install BigSur directly from Catalina to the new drive, you are going to inherit the same 64 bit string used for Catalina

What I did is just as you've said, using the installer app in catalina to install to a new apfs container in the same nvme drive. The problem is booting OC from my sata drive, neither my catalina apfs container nor the newly not-fully-installed big sur shows in the picker.

[DreamSeason]

When blessing happens apfs.efi driver is embedded into the container.

I'd like to know if the following installation procedure would do the blessing. I double clicked the install big sur app from my catalina OS and installed it onto a completely new apfs container in the same nvme drive. ( not adding an new volume in the same afps container but a completely new apfs container)

[1alessandro1]

@DreamSeason have you tried to mount BigSur's ESP from Catalina and copy the EFI from Catalina's ESP?

[DreamSeason]

@DreamSeason have you tried to mount BigSur's ESP from Catalina and copy the EFI from Catalina's ESP?

I have not done it yet. Really surprised for me to know that OC relies on the esp location to show boot partitions. I'll try booting OC directly from the nvme drive where my catalina and big sur lies on. I'll report back minutes later.

[vit9696]

ESP contents do not matter, and the partition is outside the container anyway. Reinstalling Big Sur from OpenCore should work.

[vit9696]

Also, I do not think you need GlobalConnect. It usually breaks things.

[DreamSeason]

ESP contents do not matter, and the partition is outside the container anyway. Reinstalling Big Sur from OpenCore should work.

@DreamSeason have you tried to mount BigSur's ESP from Catalina and copy the EFI from Catalina's ESP?

I copied my OC EFI folder from SATA drive to my NVME drive and remove the explicit afps.efi driver then booted from NVME directly. I can see all bootable partitions now. @vit9696 Just as you said, the EFI contents are nearly identical but different locations do affect which boot partitions you can see in the picker.

[vit9696]

Are you sure that it is still broken with GlobalConnect disabled? GlobalConnect effectively uses first found apfs.efi driver on all the containers on all disks. If this driver is incompatible (e.g. Catalina driver trying to mount Big Sur), no APFS volumes will show on that container.

Changing the ESP may affect the order in which apfs containers and thus embedded drivers are read.

[DreamSeason]

Are you sure that it is still broken with GlobalConnect disabled?

First of all, with globalConnect = false , no explicit apfs.efi driver and booting OC directly from NMVE drive, I can see all my boot partitions in the picker, ie Catalina and Big Sur on my nvme drive , Catalina on my SATA drive. Following is the process how I tried to solve the problem. At the beginning globalConnect = false, but I was booting oc from sata drive and no boot partition on nvme drive showed up in the picker. So after searching answers for this problem, I changed globalConnect to true hoping it would help me solve the problem. But it's not working.

Changing the ESP may affect the order in which apfs containers and thus embedded drivers are read.

ESP APFS1(CATALINA)
HFS
APFS2(Big Sur)
this is my partition map for my NVME drive. Booting OC from the nvme drive, which apfs container would be chosen to be the source of apfs driver?

[vit9696]

Unfortunately, it all quite depends on the firmware really. For a proper firmware it should be the one that is on the container, and multiple drivers should coexist. But if the firmware is anyhow broken, the situation will be random. Most likely this is the case of yours. It is a bit unusual on ASUS, but there are not many setups with multiple operating systems, so I cannot be objective.

[DreamSeason]

Unfortunately, it all quite depends on the firmware really. For a proper firmware it should be the one that is on the container, and multiple drivers should coexist. But if the firmware is anyhow broken, the situation will be random. Most likely this is the case of yours. It is a bit unusual on ASUS, but there are not many setups with multiple operating systems, so I cannot be objective.

I don't really get it. I think it's the responsibility of OC to obtain apfs driver from apfs container, isn't it? If so, OC is the one who choose which afps container to get apfs driver from.

[vit9696]

The algorithm is as follows.

OC obtains the lists of containers (the order is determined by the firmware), then for every container:

1. OC finds apfs.efi driver
2. OC loads apfs.efi driver
3. OC asks the firmware to connect this driver to the container

(1) and (2) happen correctly, yet (3) is subject to firmware bugs. E.g. you see multiple lines saying 01:336 00:427 OCJS: Cannot connect, already handled, which mean that your firmware connected the driver not just to the container requested but also to some other container, so the next driver can no longer connect to its own container.

This is why I asked you about GlobalConnect. If the log was made with GlobalConnect enabled it may make sense to see the logs with it disabled when booting from both SATA and NVMe.

[DreamSeason]

The algorithm is as follows.

OC obtains the lists of containers (the order is determined by the firmware), then for every container:

1. OC finds apfs.efi driver
2. OC loads apfs.efi driver
3. OC asks the firmware to connect this driver to the container

(1) and (2) happen correctly, yet (3) is subject to firmware bugs. E.g. you see multiple lines saying 01:336 00:427 OCJS: Cannot connect, already handled, which mean that your firmware connected the driver not just to the container requested but also to some other container, so the next driver can no longer connect to its own container.

This is why I asked you about GlobalConnect. If the log was made with GlobalConnect enabled it may make sense to see the logs with it disabled when booting from both SATA and NVMe.

The log attached at the beginning was made with GlobalConnect = true. Now I changed it to false , deleted the explicit apfs.efp driver and booted with OC in my SATA drive, all bootable partitions showed up. I used to boot OC with the same config but bootable partitions in NVME do not show up. Not sure what caused this change and I can not come up with the same error again. After all, thanks for you guys' effort. :D