Unable to Recognize File System Label at First Volume Scan

[Chenx Dust]

Recently, I installed rEFInd 0.14.2 on my Surface Pro 8, and I used XBOOTLDR partition, which was FAT32 format, to store kernels. Here is its blkid result:

/dev/nvme0n1p5: LABEL_FATBOOT="XBOOTLDR" LABEL="XBOOTLDR" UUID="38DA-3621" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="Extended Boot Loader Partition" 
/dev/nvme0n1p1: LABEL_FATBOOT="SYSTEM" LABEL="SYSTEM" UUID="BCBC-6E4A" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="0d5cfd50-f12c-4484-b7af-516e0d8ad6bb"
... (Other irrelevant partitions)

I added an OS stanza like below:

menuentry "Arch Linux" {
    volume   XBOOTLDR
    ...
}

It was weird that rEFInd could not find this volume. But if I load any filesystem driver or manually reload (press Esc) in main menu, it worked as expected.

And I modify the source code of efi_main function in refind/main.c like below:

   ScanVolumes();
   ReadConfig(GlobalConfig.ConfigFilename);
   if (GlobalConfig.LogLevel > 0) {
       StartLogging(FALSE);
       LogBasicInfo();
   }
   LOG(3, LOG_LINE_NORMAL, L"GlobalConfig.DontScanFiles is '%s'", GlobalConfig.DontScanFiles);
   MokProtocol = SecureBootSetup();
   if (LoadDrivers())
       ScanVolumes();

+    // for debug print inital volume info
+    for (i = 0; i < VolumesCount; i++) {
+        TempStr = GuidAsString(&(Volumes[i]->PartGuid));
+        LOG(4, LOG_LINE_NORMAL, L"Volume %d: PartName: %s, VolName: %s, FsName: %s, FSType: %d, PartGuid: %s",
+            i, Volumes[i]->PartName, Volumes[i]->VolName, Volumes[i]->FsName, Volumes[i]->FSType, TempStr);
+        MyFreePool(TempStr);
+    }

I got log like this:

12:06:11 - Volume 0: PartName: (null), VolName:  whole disk volume, FsName: (null), FSType: 1, PartGuid: 00000000-0000-0000-0000-000000000000
12:06:11 - Volume 1: PartName: EFI system partition, VolName: SYSTEM, FsName: SYSTEM, FSType: 2, PartGuid: 0D5CFD50-F12C-4484-B7AF-516E0D8AD6BB
...
12:06:11 - Volume 5: PartName: Extended Boot Loader Partition, VolName: Extended Boot Loader Partition, FsName: (null), FSType: 2, PartGuid: 0C061771-16EA-48F3-A17F-D9E459C16F06

The null result of FsName caused this problem, which indicates that it cannot read filesystem label at the time.
If I added ConnectAllDriversToAllControllers() before ScanVolumes(), I got correct result:

12:14:54 - Volume 0: PartName: (null), VolName:  whole disk volume, FsName: (null), FSType: 1, PartGuid: 00000000-0000-0000-0000-000000000000
12:14:54 - Volume 1: PartName: EFI system partition, VolName: SYSTEM, FsName: SYSTEM, FSType: 2, PartGuid: 0D5CFD50-F12C-4484-B7AF-516E0D8AD6BB
12:14:54 - Volume 5: PartName: Extended Boot Loader Partition, VolName: XBOOTLDR, FsName: XBOOTLDR, FSType: 2, PartGuid: 0C061771-16EA-48F3-A17F-D9E459C16F06

I'm not sure whether it is a general bug or device specific. Could anyone help me reproduce this bug on any other device? Thank you!

[dakanji]

@chnex-dust
Temporarily replace the rEFInd efi file with RefindPlus and see if you get the same outcome.
See here for how to: https://sf.net/p/refind/discussion/general/thread/4d2754f090/#5d5f

Thanks

[Chenx Dust]

Cool. RefindPlus managed to find my XBOOTLDR partition. BTW, RefindPlus cannot boot after simply replacing grubx64.efi when boot with shim. I replaced shimx64.efi and successfully booted.

[dakanji]

RefindPlus managed to find my XBOOTLDR partition

RefindPlus follows a different logic path to rEFInd in that area as follows:
- Device handles are always reconnected and not only when drivers are found
- The second volume scan run is always done and not only when drivers are found
- The first volume scan is purely for setting the SelfVolume variable and halted once set

Item 1, always running ConnectAllDriversToAllControllers, is why things worked:
https://github.com/dakanji/RefindPlus/blob/cd67424349ef3150aa5509bb5b4d11a6819578f3/BootMaster/driver_support.c#L895-L899

This was done to close a coverage gap in the RefindPlus implemention of a graphics handling improvement item developed by @joevt (https://github.com/joevt/joevtApps#reloadpcirom) but the root issue that device handles must be emunerated and reconnected to close a coverage gap was the same in your case. I had thought it was only needed for the GOP handling thing. Good to know closing the coverage gap serves other purposes and is a general improvement.

RefindPlus cannot boot after simply replacing grubx64.efi when boot with shim

Yes, RefindPlus binaries up to the current v0.14.1.AA release do not have SBAT sections and can therefore not be signed for UEFI Secure Boot. You have to disable secure boot, as you presumably did, or add the section yourself and then sign. The next release will have SBAT sections already added ready for signing.

---

PS: You should be able to get things working with rEFInd if you add at least one driver to be loaded so as to force ConnectAllDriversToAllControllers to be run.

I created a driver that doesn't do anything as a work around for this once:
https://github.com/dakanji/RefindPlus/issues/17#issuecomment-765236639

You will presumably need to sign the driver before use in a secure boot setup.

Alternatively, you could try using "Extended Boot Loader Partition" in your stanza:

menuentry "Arch Linux" {
    volume "Extended Boot Loader Partition"
    ...
}