From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Thomas Schmitt" Subject: Re: ISO installer image: GPT versus MBR partitions Date: Fri, 19 Apr 2019 11:01:51 +0200 Message-ID: <2471667296595514572@scdbackup.webframe.org> References: <20190419080341.m47hhg54lxfhan4r@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]:38461) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hHPUR-0000Ck-AN for guix-devel@gnu.org; Fri, 19 Apr 2019 05:07:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hHPN0-0003ZF-8K for guix-devel@gnu.org; Fri, 19 Apr 2019 04:59:43 -0400 In-Reply-To: <20190419080341.m47hhg54lxfhan4r@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: > > this is the xorriso run for producing a layout like "isohybrid --uefi" Florian Pelz wrote: > No, it still gets stuck. :( Then it must be something inside the EFI partition which makes the Macbook firmware dismiss the partition for booting. > The GPT partition GUID is different each time I repeat the process. This can be avoided by setting environment variable SOURCE_DATE_EPOCH to the same value in each production run. (I just tested that this works as expected.) Well, i am out of ideas how the Guix ISO layout or content differs from the stuff in Debian ISOs, so that an EFI implementation dismisses the former and accepts the latter. It really does not look like an issue with partitioning. I don't think that it goes deeper into the boot equipment than the files in the EFI partition. Maybe GRUB experts have ideas what to examine there. After all it is grub-mkrescue which fails to produce a recognizable partition, whereas Debian's effort with (most probably) grub-mkimage can do the trick. grub-mkrescue uses grub-mkimage, too, afaik. So it probably is about some magic ingredient to the production of the EFI start programs or the FAT image file. We could ask at debian-cd mailing list whether the problem rings a bell from a past problem fix. (I am subscribed there and ready to assist with technical details about our findings.) Next mail from Florian: > Boot gets stuck on x86_64 Guix images only, but the one i686 I tried > did not show up in the boot menu. I believe bootx64.efi is run for > x86_64 and is the culprit. This fits into my findings if EFI looks into the EFI partitions and dismisses those without its CPU specific flavor of start program. Can you get EFI to confess that the x86_64 USB stick indeed has a recognizable EFI partition ? > I could try burning a DVD and attempt to boot from it. On DVD the El Torito boot equipment should lead EFI to the same partition image as the partition table should do on USB stick. But a try cannot harm. > It would also be interesting to find out how to change the > bootx64.efi=E2=80=99s code and make it display debug information in some= way. The highest control layer is http://git.savannah.gnu.org/cgit/grub.git/tree/util/grub-mkrescue.c The name "BOOTX64.EFI" appears in http://git.savannah.gnu.org/cgit/grub.git/tree/util/grub-install.c Somewhere inbetween must be its source. :o) =2D----------------------------------------------------------------------- For now i say thanks for three found bugs in my own software, during this discussion: - Environment variable SOURCE_DATE_EPOCH did not affect synthetic files. Thanks to Florian and Ludovic for pointing out the non-reproducibility issue. Fixed by libisoburn 5b62c55 Workaround for Guix and currently released versions of xorriso: Give the ISO root directory fixed atime, mtime, and ctime by xorriso command -alter_date. (Would work with future xorriso versions, too.) - SIGSEGV happened if "-boot_image grub grub2_mbr=3D" was used and no El Torito boot image was defined. This one i found by a bad backslash while testing my xorriso run proposals to Florian. Fixed by libisofs 4b21386 No workaround needed because no usable result can emerge anyways. - I was unable yesterday to get "isohybrid --uefi" layout when using GRUB equipment for BIOS. I thought it was possible. My grub-mkrescue argument filter script falsely promises to do it. Still unresolved. Workaround was to use body parts of a real isohybrid ISO. =2D----------------------------------------------------------------------- Have a nice day :) Thomas