Re: [edk2-devel] [PATCH] MdeModulePkg/PartitionDxe: Seperate the Udf handler

["Laszlo Ersek" <lersek@redhat.com>]

On 06/29/20 03:47, Gao, Zhichao wrote:
> Hi Laszlo,
> 
> Sorry, I didn't put the detail info about the issue. Let me descript here.
> 
> The issue is not only for Red Hat. I found it with ubuntu 18.02 amd64 and Fedora-20-x86_64 ISO image as well. I didn't view all the linux iso images.

OK. Thanks.

> 
> Here is the issue:
> Using USB CD ROM with the linux ISO DVD. Run the platform and enter UEFI shell -> plug the USB CD ROM with the ISO DVD -> run "map -r". The CD's file system didn't show.

That's right.

And, I've always thought that's by design.

With all the ISO images I've checked in the UEFI shell before, my
experience has been consistent: in the UEFI shell, the ElTorito boot
image contents are *visible*, and the file system that the *OS* would
show is *not* visible.

I've always treated these two content-sets as separate file systems.
When we "mount" the ISO under UEFI, we get the ElTorito boot image. When
we mount the disk under an OS, we get the "real" file system.

What's wrong with that?

UEFI needs to be able to boot off of a UEFI-bootable CD-ROM. That
requires support for the ElTorito boot image. That support exists.

> 
> It works fine with the normal boot (such as F2, F7 and auto boot) because it would run the *connect all* operation.

I think I disagree; ConnectAll is not the reason.

Automatic boot works OK because the ElTorito image is processed
correctly even *without* a ConnectAll, and the ElTorito image is all
that's needed for successfully booting.

I think you may be misled the fact that the ElTorito image and the
OS-visible filesystem on the disk are *similar*. They have similar
contents, but they are not identical. For UEFI booting, the OS-visible
filesystem is completely ignored (and that's how it should be).

> That would run the partition driver serval times. First time the partition driver would install MBR partition info protocol with the device handle and skip the UDF check. The second time, it would fail the MBR check with *already started* and run UDF check next. That means for such ISO the UEFI would install two partition protocol, both MBR and UDF.

I still don't understand how UDF enters the picture. If I loop-mount the
"Fedora-20-x86_64-DVD.iso" image on my laptop, the kernel logs the
following:

> ISO 9660 Extensions: Microsoft Joliet Level 3
> ISO 9660 Extensions: RRIP_1991A

Also, the "mount" and "df" commands report the filesystem on the ISO
image as "iso9660". It's not UDF.

(I do have UDF media too; when I mount it, the kernel logs

> UDF-fs: INFO Mounting volume '...', timestamp ... (...)

and "mount" and "df" report "udf" as file system.)

So I would say that a UDF filesystem should *never* be exposed for
"Fedora-20-x86_64-DVD.iso" specifically, under UEFI.

... down-thread, Ray says,

> It sounds like a bug in partition driver that the second UDF check
> succeeds.

And I think I agree.

Thanks
Laszlo

> 
> But for shell environment, the USB hot plug handle would connect the USB device only once and missing the UDF check.
> 
> I don't know why linux need the MBR info. Maybe for legacy compatible thinking (my opinion, may be wrong).
> 
> If the GPT, MBR and UDF are conflict, then the original logic is fine. But in fact, GPT and MBR are conflict and GPT/MBR and UDF are not conflict.