From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 0BFFC21962338 for ; Tue, 20 Jun 2017 09:45:50 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 466277CE0C; Tue, 20 Jun 2017 16:47:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 466277CE0C Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=lersek@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 466277CE0C Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-150.phx2.redhat.com [10.3.116.150]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9A4AB6A301; Tue, 20 Jun 2017 16:47:11 +0000 (UTC) To: Heyi Guo , "edk2-devel@lists.01.org" References: <30c8ed8a-9ed5-0472-acbe-1d8b17fb38fb@linaro.org> From: Laszlo Ersek Message-ID: <46cef850-9a4f-b521-a379-037dae1d1a2b@redhat.com> Date: Tue, 20 Jun 2017 18:47:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <30c8ed8a-9ed5-0472-acbe-1d8b17fb38fb@linaro.org> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Tue, 20 Jun 2017 16:47:12 +0000 (UTC) Subject: Re: How can we identify an ISO file is an EFI bootable ISO image? X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 16:45:50 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 06/20/17 14:34, Heyi Guo wrote: > Is there any simple tool to parse ISO images (El Torito partition) and > identify whether it is EFI bootable? $ dumpet --iso Fedora-Server-dvd-aarch64-25-20161015.n.0.iso Validation Entry: Header Indicator: 0x01 (Validation Entry) PlatformId: 0xef (EFI) <---------- [1] ID: "" Checksum: 0x66aa Key bytes: 0x55aa Boot Catalog Default Entry: Entry is bootable Boot Media emulation type: no emulation <---------- [2] Media load address: 0 (0x0000) System type: 0 (0x00) Load Sectors: 9208 (0x23f8) Load LBA: 2456 (0x00000998) The source for dumpet is at . > I think EFI bootable image should contain a FAT volume so that EFI can > load bootxx.efi file from the file system. For a large Wiki page on this, I can recommend: . For a short summary, these are the commands you need, to format an EFI-bootable (and EFI-only) CD-ROM: (1) Create a non-partitioned FAT image in a file, with "mkdosfs -C", and populate it with the "mtools" utilities. For a heavier-weight (but also a lot more feature-ful) toolset, you can also use libguestfs / guestfish. (2) Generate the ISO image like this: genisoimage -input-charset ASCII -J -rational-rock \ -efi-boot "$FAT_IMAGE_FILE" -no-emul-boot \ -o "$ISO_IMAGE" -- "$FAT_IMAGE_FILE" So what you do is, create an ISO9660 filesystem with the FAT image file copied into it as a normal file (simply to the root directory). You can enable Joliet and/or RockRidge extensions if you want to, but those aren't necessary. Then, you set the EFI boot image name with "-efi-boot" [1], and also specify that the boot image is a "no emulation" [2] image . > Several tools like mount in Linux will show all files together > including EFI/BOOT directory, That directory, displayed as part of the ISO9660 filesystem that was written to the ISO image / CD-ROM, is entirely irrelevant when it comes to UEFI-bootability. I doesn't even need to exist, and if it does, it's likely there only for convenience reasons (so that people don't have to run "dumpet" or similar tools to extract the FAT image first, and then the EFI binaries second, if they want to investigate the EFI binaries). For UEFI boot, only the ElTorito image matters. > so if an ISO image contains such files but not organizes the data in a > FAT sub-volume as EFI requires, I can't see any difference. In order to extract the ElTorito image(s), use "dumpet --dumpdisks", and then work on the extracted files with guestfish or mtools. For example: $ MTOOLS_SKIP_CHECK=1 mdir -i extracted.iso.0 -/ :: Thanks Laszlo