From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Thomas Schmitt" Subject: Re: ISO installer image: GPT versus MBR partitions Date: Sun, 21 Apr 2019 11:35:49 +0200 Message-ID: <452567273172162940@scdbackup.webframe.org> References: <20190421075847.ka4aeseg6kgfufz4@pelzflorian.localdomain> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([209.51.188.92]:52574) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hI8qu-0005Ij-29 for guix-devel@gnu.org; Sun, 21 Apr 2019 05:33:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hI8qs-0006Na-Vp for guix-devel@gnu.org; Sun, 21 Apr 2019 05:33:36 -0400 In-Reply-To: <20190421075847.ka4aeseg6kgfufz4@pelzflorian.localdomain> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: bug-xorriso@gnu.org Cc: guix-devel@gnu.org Hi, i wrote: > > with the Guix EFI partition image in > > partition 2 of the USB stick and > > dd if=3D/dev/zero bs=3D1 count=3D16 seek=3D446 of=3D/dev/sdc2 Florian Pelz wrote: > Yes, this fixes the issue. I really had a good feeling with that theory. :)) =2D---------------------------------------------------------------------- Ok, now for the last experiment. Just for curiosity, as i believe it is not a good solution (and mformat -k isn't either): Does start LBA 1 of partition 1 prevent the endless loop, too ? So please write to byte 446 (dec) to 461 (dec) of the FAT image: 80 00 02 00 01 01 12 4f 01 00 00 00 3f 0b 00 00 In the FAT image treated by the "dd" above, these bytes are all 00. In the original FAT image they are: 80 00 01 00 01 01 12 4f 00 00 00 00 40 0b 00 00 =3D=3D =3D=3D =3D=3D =3D=3D If this works, then we can blame a bug in the Macbook's EFI which is too stupid to avoid endless recursion when exploring a potential tree of partition tables. (If it does not work, then we only have a heuristic indication that a partition table entry in the EFI partition is bad for the Macbook.) Nevertheless, start LBA 1 is less desirable than no partition table entry at all, because LBA 1 causes a partition that is not mountable. So an option for mformat would be of interest, which writes an MBR (other than with -k) but does not create a partition entry. Alternatively, the Guix ISO production could apply above zeroizing dd run to the EFI image by help of a pseudo-xorriso wrapper under grub-mkrescue. This wrapper would learn the EFI image file address from the xorriso options, patch that file, and then run xorriso with the arguments given by grub-mkrescue. (I will give my grub-mkrescue-sed.sh wrapper such a feature as addon-on to its other manipulation offers.) =2D--------------------------------------------------------------------- Reading UEFI 2.4, 12.3.1 "System Partition" i do not find statements about partition tables inside that partition, but only: "A System Partition supports backward compatibility with legacy systems by reserving the first block (sector) of the partition for compatibilit= y code. On legacy systems, the first block (sector) of a partition is loaded into memory and execution is transferred to this code. EFI firmware does not execute the code in the MBR. The EFI firmware contains knowledge about the partition structure of various devices, and can understand legacy MBR, GPT, and =E2=80=9CEl Torito.=E2=80=9D So an MBR-like start block of the partition is explicitely encouraged. "understand"ing partitioning offers a wide range of interpretation. So the behavior of the Macbook is not totally against specs. It is just not overly stable and helpful. "I am not crazy. Don't call me crazy. I...I'm just not user friendly." Roberto, Futurama. Have a nice day :) Thomas