guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#27661] ISO-9660 image working and ready


From: Danny Milosavljevic
Subject: [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
address@hidden (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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]