From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1hXVJu-0001jT-Rr for mharc-grub-devel@gnu.org; Sun, 02 Jun 2019 14:35:02 -0400 Received: from eggs.gnu.org ([209.51.188.92]:58295) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hXVJs-0001j0-Rg for grub-devel@gnu.org; Sun, 02 Jun 2019 14:35:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hXVJn-0007Dz-PI for grub-devel@gnu.org; Sun, 02 Jun 2019 14:35:00 -0400 Received: from mout.gmx.net ([212.227.15.19]:46643) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hXVJn-00076y-4t for grub-devel@gnu.org; Sun, 02 Jun 2019 14:34:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1559500483; bh=Ge2O8WgAQUPtj4v4OGtD6eMaKWpNlYL6OdVstkRcxpU=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To:Cc; b=C2e3Kw6ZutfSuufvKAujwX8/N3HgmalIOZjbS4viCHw+e8EunU/xIOOHbmjOZqGfA C4SMtwrbeyGpotiPzRy76sSwLgMjshwob8nyYW4kRsIz3qP3apvbbO0KCjq8JFlRhv 3hkTQIPJmToh30blJa6PXHJ4bzmxZQ6OrznoqRQU= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from scdbackup.webframe.org ([84.179.250.52]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MaIPo-1hIBMB2ITA-00JpvU; Sun, 02 Jun 2019 20:34:43 +0200 Date: Sun, 02 Jun 2019 20:34:05 +0200 From: "Thomas Schmitt" To: alain@knaff.lu Subject: Re: Several GNU projects wondering about the reason for mformat partition table Content-Type: text/plain; charset="utf-8" References: In-Reply-To: Cc: Message-Id: <29131676412833610017@scdbackup.webframe.org> X-Provags-ID: V03:K1:a/3aSMsk69VkA13PbX8VP0wFXk55GJ6eKAzydfkeRdcBIgo0a3y ol7q7SSyfxv9ce82oky+9CGLJpsy4b9slZUE240TaQ+H7PWYkKkg5dACyak+inZwM9jghcg +aS2eftZBv43Zncj/1VRSAt8nK4rhxLnSxWdSPpvM1zBaKtK8XS2yjkWi0CWUBtajnD4ETo AZuOjGodt8lEYRAaP9fhw== X-UI-Out-Filterresults: notjunk:1;V03:K0:QhV/WA5o6Fk=:nLeOsBaEpIyTI3e7z+7iHR OMt+OXwd8BqtoG8V7AA/6Ptuk6ONJAwjbHuYo2BKQ5oAiIaxmt1HtlvEJJHr9fuDucPWP6ji7 F0fOfwEoQvTP4mTCrFV81rpO9/aheru7Ts7UYfMI0MIouLf4X78EXLdMUVqreiquPV74hJG9K e6OXIDrFB9TgtGt/l2bNlFeavCnLrB64YEZMv0PZELH2QTsvpd7S0BHAw9Pue8HUyyK2O/rNI JVOuTw/r2M2lQDy+Mvm9NJz4hhX4hAs5Bv8VtcSO3lorzsS6P9QeXSJ2cIYdMyXBuI1RrGaYN Ta7bjLCYJRy+zwUS5grMJ9rG1OYv3BwOzHZB4kKmBlsPSrxOuv+4CTJvetNVk2HUTjyGxi22g UgwixnYUCGhowvTT1kfMNxEiQUXM39mvyhLGjEhArk1rrFCr14p5xoJMFVeqct8apLJMwRSFz 2KW4zqEuHOyoCaULVKwhHadTBZ2ApjO85jqumSsL87GiPPsXk7qVjeMBajabqS22vVSArVPFN ySqZNrohxHBu/j7XrRwHeixkWFKEbKT5lfzCxCdpIIkEiB+r44b5vSC8EEZINWuEDOc7fDt9y yIQfh5UMDhlZchMqTbv2mmk40wy/Prz7TDaecdnGKBHPyfBK/fdui9DkyWkqmLHHf45iM3lA2 WMNthke2C6wNDAo3pGqvf3nB8RCLrRYEFM2ACb0kX8PPdWLmXYBHFKKd4yH6hAbjt+bgfiDif KHvY/8ngNv3c9pBzBVe0A5FuU9i+ZfhY6rJ6q0eoGUT+KJdQSBG9X4qqxgjnOUVIrKX8EfaZr fMdT1W8zY35etqy9nGig7kT9gF6QNv461FoadSjLzm+sJlmis6FkZz6MXrBNHxK/LIqNViLPI 1LFrTD3xqv82H+F0weZ5rKzBTbs7/QD//Y9eZQf6loLxOC/byOaiavEHknl4jGHD+oHoAGEfn Mv8VN8fc8Qp/zRphln2B6NU2YXc+A8V4jme3SypmBD5Y8GuWX/cdh X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.227.15.19 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2019 18:35:02 -0000 Hi, thanks a lot for the background info. Alain Knaff wrote: > A platform that expects the disk to be unpartitioned would just ignore > this mini partition table. The EFI platform encounters the mformat-produced image in a partition. Nearly all implementations indeed ignore the MBR-ish table in the partition. But one wanted to be smart, obviously. (The disk device, a USB stick, was partitioned by GPT.) If you see any other potential problem with using a mformat image as content of a partition, then please tell. > In the next release I'll provide a new option to just skip this > partition table [...] > > If all goes well, I expect to make this new release by the end of the month Good move. ------------------------------------------------------------------------ I assume that grub-mkrescue will have to wait a while before it can unconditionally use a new option of mformat, or that it will need a function like check_xorriso() http://git.savannah.gnu.org/cgit/grub.git/tree/util/grub-mkrescue.c#n316 which is used to look for a five year old option in the help text of xorriso: http://git.savannah.gnu.org/cgit/grub.git/tree/util/grub-mkrescue.c#n608 The three alternatives for grub-mkrescue now look like this: > > - Keep the partition entry because its removal could break some other > > EFI firmware's boot process. No objections are known yet against partition table removal. Its purpose has nothing to do with the use case as EFI System Partition. I am out of ideas whom else to ask for an opinion. So i think grub-mkrescue should dare to choose one of the other two: > > - Overwrite the partition table in bytes 446 to 509 of the mformat result > > by zeros before populating it with files. If i am not mistaken, then this is equivalent to the new option of mformat. grub-mkrescue could anticipate this option by own postprocessing after the mformat run. > > - Use mformat option -k to avoid production of the partition table. Alain Knaff wrote about the new option probably in contrast to -k: > [...] but still initialize the other fields (jump at > beginning of boot sector, mformat "banner", 0xaa55 boot signature, > physdrive, mtools boot code, zeroing out unused bytes) None of the items in this list looks like it would be necessary for a partition image which gets created as new file. I assume that no non-zero bytes can sneak in, if the image file does not exist before it gets written by mformat. Have a nice day :) Thomas