GNU bug report logs - #27661
[PATCH] build: Make ISO-9660 image bootable from USB flash drive.

Previous Next

Full log

Message #40 received at 27661-done <at> debbugs.gnu.org (full text, mbox):

From: Danny Milosavljevic <dannym <at> scratchpost.org>
To: ludo <at> gnu.org (Ludovic Courtès)
Cc: Marius Bakke <mbakke <at> fastmail.com>, 27661-done <at> debbugs.gnu.org
Subject: Re: [bug#27661] ISO-9660 image working and ready
Date: Mon, 17 Jul 2017 11:04:34 +0200

Hi Ludo,

On Mon, 17 Jul 2017 10:25:08 +0200
ludo <at> gnu.org (Ludovic Courtès) wrote:

> It looks like the partition detection code in (gnu build file-systems)
> tries to read beyond the end of disk or something.  Could you try adding
> a few ‘pk’ or ‘format’ calls in there so see what’s going on?

Yeah, it tries to read beyond the end of the partition.  That's because grub-mkrescue creates a tiny fake partition which happens to start where the ISO-9660 filesystem starts and GuixSD mounts it and tries to boot from it (because it has a valid volume id).  As it is going on booting, the system boot wanders off the end of the partition and Linux tells it that it can't do that.

I've posted bug# 27705 which is the minimal set of patches to get it to work.  I just read the root filesystem directly from the whole disk there.

By now, I've also tested the resulting image on the bare metal on a real DVD on a non-EFI, non-Libreboot system.  Works fine :)

Marius, could you also test it on EFI ?

As for fixing the original partitioning problem, I didn't manage to find the place yet.  As far as I can see, grub-mkrescue uses xorriso which uses mkisofs to actually generate the ISO image.  There's a "protective" DOS MBR generated somewhere, but where.  It seems that Xorriso_coordinate_system_area and make_isohybrid_mbr are at least related somehow.  Also, it's questionable whether it's possible to fix it without creating overlapped partitions, see below.

The resulting partition table is:

Disk J: 1.1 GiB, 1137074176 bytes, 2220848 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: F86B53DD-3E7B-4B5E-A4C9-3A1A0AA56D22

Device   Start     End Sectors  Size Type
J1          64   76871   76808 37.5M Microsoft basic data <--- GuixSD tried to use this one as root
J2       76872   82631    5760  2.8M EFI System <-- mounts and reads fine as FAT FS
J3       82632 2220199 2137568    1G Apple HFS/HFS+ <--- can't find valid HFS on there
J4     2220200 2220799     600  300K Microsoft basic data <-- can't mount it

P.S. grub-mkrescue (with EFI) has a surprising number of supported architectures.  It might be that a grub-mkrescue-generated image could also boot on MIPS, Sparc, PowerPC, ARM64.

> Alternately, you could run the same QEMU command line that the
> derivation spawns, so you would get a REPL (and backtrace).  For that
> you can “ps aux | grep qemu” while the derivation is building, and
> copy/paste the QEMU command from there.

Thanks!  Very useful.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.