From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 6150221BBC43C for ; Tue, 20 Jun 2017 17:46:40 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id s66so77031812pfs.1 for ; Tue, 20 Jun 2017 17:48:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=nNgGa8c2jWYOoEuiwbK5PR219I4PdLW6XdLTMVdY41U=; b=j+DDE2QIguyJk15bb6TLVGbuzghy9uQPOdxPMHWvgeTUnEtm33DodMKHxn7CB3dLyH AShQkwjfXwaxdRZNkdVhUID+THYjS6S0oa4Mut+KOJY5/DOedEUDqvzohKviW7PtBCor by3A19lMDCahG1ud0Dm1Xc4rWPVGQ76NBzvkY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=nNgGa8c2jWYOoEuiwbK5PR219I4PdLW6XdLTMVdY41U=; b=QbtVr2ys7UjOcp5TukV0JFOvi0UdbMXm75NGb3oaRmhwLC34Pr0uHrj+Goi+fpVR4j ioKjQ41RWJA2iRXh16mVOnkfaxYdbppk/Ns9oO2Vp+ZCFvXlp6xDEzX936Vk3RBdzQ+l onjraItMTV7dDrS4jcK9kO9VKx20X0ksNGkK0r2Nq+GXliaOndsKxWQUhTBEAvQHR0Ri lSfxtjQIM0xREShWr3CezLHJuFUlOGXmlzpEEvM+YqXqbM2k4KzUpeCDCxXkWbbB1cW4 vg1OfQYJORR3oyI7Tc2FmoqEFl4FQcE1ZFfVUeBnGiY2T651b/KKnbhKEXyHrS+Gz70i tSlg== X-Gm-Message-State: AKS2vOw0J8lG7HakC2Ft1uZ/3H1c4PyO1TeRlN1wOruSiNTqtg2rvTZr XqhZVYg26wqJKWGppiOsaQ== X-Received: by 10.99.23.100 with SMTP id 36mr34731460pgx.118.1498006083153; Tue, 20 Jun 2017 17:48:03 -0700 (PDT) Received: from [10.229.36.134] ([119.145.15.121]) by smtp.gmail.com with ESMTPSA id i14sm29317391pgn.14.2017.06.20.17.48.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Jun 2017 17:48:02 -0700 (PDT) To: Laszlo Ersek , "edk2-devel@lists.01.org" References: <30c8ed8a-9ed5-0472-acbe-1d8b17fb38fb@linaro.org> <46cef850-9a4f-b521-a379-037dae1d1a2b@redhat.com> From: Heyi Guo Message-ID: <57011f94-e32e-9fae-6ae5-56329c14b668@linaro.org> Date: Wed, 21 Jun 2017 08:48:00 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <46cef850-9a4f-b521-a379-037dae1d1a2b@redhat.com> 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: Wed, 21 Jun 2017 00:46:40 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thank you so much. I will try that :) Regards, Gary (Heyi Guo) 在 6/21/2017 12:47 AM, Laszlo Ersek 写道: > 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