From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.61]) by mx.groups.io with SMTP id smtpd.web10.2999.1593682937458412601 for ; Thu, 02 Jul 2020 02:42:17 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Gl0FOcBj; spf=pass (domain: redhat.com, ip: 205.139.110.61, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1593682936; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=s3PsF+wjVx0nx6AR61SExSLMTxSvb+37jGB9whiXde4=; b=Gl0FOcBjz0YH2E47ovW36YjnzSddLx0ETvDv4L9UkMYCZwVPdqYAM9Cwz1epCyCLYCyUPX dpGoDMBL0II+Q46kXyvIoCK/HqeFB9yGK1TzawHstE2KY3aWBCDGPsxrjlwzvahze+RirM 0A6m5+wiqrzdB0ePmT7fHFw9oZ5FJIM= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-430-1mV3o4cSMzGlX2b1MXR41Q-1; Thu, 02 Jul 2020 05:42:15 -0400 X-MC-Unique: 1mV3o4cSMzGlX2b1MXR41Q-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id C37A418A8223; Thu, 2 Jul 2020 09:42:13 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-113-177.ams2.redhat.com [10.36.113.177]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4D0092B4BA; Thu, 2 Jul 2020 09:42:12 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH] MdeModulePkg/PartitionDxe: Seperate the Udf handler To: "Gao, Zhichao" , "Ni, Ray" , "devel@edk2.groups.io" Cc: "Wu, Hao A" , "Wang, Jian J" , "Gao, Liming" References: <20200624055610.13984-1-zhichao.gao@intel.com> <734D49CCEBEEF84792F5B80ED585239D5C5D1BBB@SHSMSX104.ccr.corp.intel.com> <2f85dc90-41ae-0b51-4512-d65dbdd143b5@redhat.com> <734D49CCEBEEF84792F5B80ED585239D5C5D2639@SHSMSX104.ccr.corp.intel.com> From: "Laszlo Ersek" Message-ID: Date: Thu, 2 Jul 2020 11:42:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lersek@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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.