cannot access ext4 partitions on an HP ProBook 450 G2

[Alexandru Cristea]

Hello everybody.

The notebook came pre-installed with FreeDOS. The pre-boot environment (64bit) accepts a custom efi boot manager, which I configured to be EFI\refind\refind_x64.efi. I installed Arch linux, ext4 rootfs on /dev/sda3, ESP on /dev/sda1. The OS installation went smoothly, but refind did not see the Arch installation. Booting to the EFI shell via refind I found out that the ext4 driver is loaded:

187 00000010 ? - - - - rEFInd 0.8.5 ext4 File System Drive EFI\refind\drivers

but no corresponding fs#: in the map command output (only fs0:). I suppose the '?' in the output above tells us that something is not ok.

I've also tried:
- some EFI commands: connect, map -r
- some other versions of the ext4 driver (0.8.4, 0.8.3, etc)
- the ext2, ext3 drivers
- HP firmware (BIOS) upgrade
- an usb stick with an ext4 partition on it
but the situation remained the same: no ext4 access.

The only way to boot Arch linux using refind was to copy the linux boot files (the kernel + ramdisk images + refind_linux.conf) to the ESP. Of course I updated the kernel package and forget to update the ESP files :) Managed that using some rescue usb stick.

What else should I do to solve the problem?

Thank you,
Alexandru

[Roderick W. Smith]

I've got an HP 6470b that exhibits the same symptom: Filesystem drivers load but can't detect filesystems. This appears to be a bug in the EFI; when the driver registers itself, the firmware doesn't tell the driver about volumes the way other EFIs do.

The Clover boot loader, which is partially derived from rEFIt (just as is rEFInd), manages better, and I've found references in its source code comments to this problem and to a workaround within Clover. I've tried copying over the relevant bits, but to no positive effect, so obviously I'm missing something -- maybe there's some other subtle difference between the code bases. I'm sure I'll investigate this further in the future, but for the moment I've set that problem aside.

In the meantime, my recommendation is to use a FAT partition as /boot. Many Arch users like to use the ESP for this purpose, so you might try that; or you can use a separate FAT /boot partition. This works fine with Arch.

[Alexandru Cristea]

Hello again.

The reason why the ext4 refind driver can not access the ext4 partitions is in the HP firmware: the HP partition driver opens the DiskIO protocol of all the partitions handles except the FAT type partitions with the option BY_DRIVER, despite the fact that it adds no obvious functionality. The side effect is that no other driver can open the partition DiskIO protocol BY_DRIVER in order to provide filesystem functionality.
I've tested this scanario on my 450 G2 notebook and on an 470 G1. It is also documented on the refit/clover code (clover-master/rEFIt_UEFI/refit/main.c - see function DisconnectInvalidDiskIoChildDrivers()). The refit workaround is to:

• DisconnectInvalidDiskIoChildDrivers()
• install their drivers as highest priority using EFI_PLATFORM_DRIVER_OVERRIDE_PROTOCOL.

My workaround is to:

• boot to an efi shell
• configure startup.nsh (located on the ESP root directory) to:

  1. load the refind ext4 driver;
  2. disconnect the partition driver from the /boot ext4 partition handle;
  3. connect the ext4 driver to the /boot partition handle;
  4. launch refind.
  

When booting, I have 5 seconds to press Esc and remain in the shell. If not, the shell will launch refind WITH ext4 access IF the proper handles are provided to the startup.nsh commands. I know it's an ugly hack, which requires some familiarity with the efi shell too. It is only a way to spot the fault and not an user-friendly solution.

I wonder what could be the reason for the HP efi partition driver behaviour. The firmware provides ESP filesystem access indeed (by their FAT driver), but why block other filesystem type access? Are there some non-obvious functionality the partition driver provides or it is simply a bug?

[Alexandru Cristea]

It's almost an year since you solved the problem, in the 0.10.2 release of this great software. I found out yesterday, unfortunately... It's time to make a habit from reading the NEWS file :)

I upgraded to 0.10.5 (from 0.8.5) and there is no need for hacks anymore.

Thank you for your good work! Keep it up!

[Roderick W. Smith]

I'm glad you found the fixed version, Alexandru. Sorry for not flagging it for you when I implemented that fix; sometimes these long-standing problem reports get buried and I don't do a good job of notifying people when they're fixed.

FWIW, my interpretation is that this is a bug in HP's old EFI implementation; however, I've not spoken to HP's firmware people, so I don't know their take on it. It's a moot question, though, since rEFInd now incorporates a fix. It's based on that Clover workaround I mentioned earlier, but I had to tweak it because Clover and rEFInd had diverged in different ways from their shared ancestor, rEFIt.