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

["Gao, Zhichao" <zhichao.gao@intel.com>]

> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Laszlo Ersek
> Sent: Thursday, July 2, 2020 5:42 PM
> To: Gao, Zhichao <zhichao.gao@intel.com>; Ni, Ray <ray.ni@intel.com>;
> devel@edk2.groups.io
> Cc: Wu, Hao A <hao.a.wu@intel.com>; Wang, Jian J <jian.j.wang@intel.com>;
> Gao, Liming <liming.gao@intel.com>
> Subject: Re: [edk2-devel] [PATCH] MdeModulePkg/PartitionDxe: Seperate the Udf
> handler
> 
> 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.

UEFI can boot ElTorito image because it has a FAT file system. And UEFI would load the bootable image in the FAT. If the block device has FAT file system in them. It should be shown in the UEFI shell. For the above Linux ISO images, they have.

> 
> >
> > 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).

Why I mention the *ConnectAll*, because the UEFI binding driver would be ran thru this function. That means the partition driver would run serval times. First time it runs, it would pass the MBR check. Second time it would failed the MBR because the same block already installed, and it would continue to check UDF (ElTorito compatible).

So the connect behavior should be run at least twice. Otherwise, the ElTorito image would be missed. This is an incorrect behavior mention below.

The USB hot plug handle would only connect the USB device only once. So the hot plug of USB CD ROM under shell would only show the MBR block info. If you run platform with USB CD ROM plugin all the time or hot plug USB CD ROM and run 'reconnnect -r', the CD block with FAT will appear.

> 
> > 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.

Sorry for the unclear description. The UDF I mentioned is ElTorito compatible. There is one commit to merge the ElTorito into the UDF. See 01a68fd37e79c6c7e2f342d7d2c1349325110e99.

> 
> ... down-thread, Ray says,
> 
> > It sounds like a bug in partition driver that the second UDF check
> > succeeds.
> 
> And I think I agree.

I didn't aware this is a bug before. I make the patch to do the MBR and UDF check at one connect operation. Now I plan to add the check for the MBR table check to skip the one added for windows compatibility. And fix the bug: if one partition check return already started, it would continue to check next routine partition check.

Thanks,
Zhichao

> 
> 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.
> 
> 
>