[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.
- [bug#27661] ISO-9660 image working and ready, (continued)
- [bug#27661] ISO-9660 image working and ready, Marius Bakke, 2017/07/13
- [bug#27661] ISO-9660 image working and ready, Danny Milosavljevic, 2017/07/14
- [bug#27661] ISO-9660 image working and ready, Ludovic Courtès, 2017/07/17
- [bug#27661] ISO-9660 image working and ready, Danny Milosavljevic, 2017/07/17
- [bug#27661] ISO-9660 image working and ready, Danny Milosavljevic, 2017/07/17
- [bug#27661] ISO-9660 image working and ready, Ludovic Courtès, 2017/07/18
- [bug#27661] ISO-9660 image working and ready, Danny Milosavljevic, 2017/07/18
- [bug#27661] ISO-9660 image working and ready, Ludovic Courtès, 2017/07/18
- [bug#27661] ISO-9660 image working and ready, Danny Milosavljevic, 2017/07/14
- [bug#27661] ISO-9660 image working and ready, Ludovic Courtès, 2017/07/17
- [bug#27661] ISO-9660 image working and ready,
Danny Milosavljevic <=
- [bug#27661] ISO-9660 image working and ready, Danny Milosavljevic, 2017/07/20