On 27/04/2019 17:21, John Paul Adrian Glaubitz wrote: > On 4/27/19 5:35 PM, Mark Cave-Ayland wrote: >>> I set $CDDIR to the source directory which contains core.img? How does the >>> initial >>> bootloader know that it has to boot core.img? >> >> This is the part which Thomas explained: the offset of core.img *as embedded >> within >> the ISO filesystem image* and its size are embedded at byte offsets 552 and >> 560 >> respectively from the start of the image. From what I can see >> boot.S/diskboot.S seek >> to sector 1, read in these values, seek to the start offset and then read the >> relevant number of bytes into memory before finally transferring control. > > But how does genisoimage know that it is supposed to place "core.img" there? > > This is simply what I cannot wrap my head around it. There is some hidden > magic > that knows that it has to put "core.img" there, but the file is never > mentioned > anywhere.
My understanding is that it's the other way around: the location of core.img is extracted from the ISO image itself and then re-injected back into sector 1... > FWIW, it also doesn't boot: > > {0} ok boot cdrom > Boot device: /virtual-devices@100/channel-devices@200/disk@1 File and args: > WARNING: Unsupported bootblk image, can not extract fcode > > WARNING: Bootblk fcode extraction failed > > The file just loaded does not appear to be executable. > {0} ok > > Image here: > https://people.debian.org/~glaubitz/debian-10.0-sparc64-grub-NETINST-1.iso > > Current debian-cd patch attached. ...and the trigger for this is the --grub2-sparc-core parameter that Thomas pointed out was missing from my previous email (see https://lists.debian.org/debian-sparc/2019/04/msg00057.html for the updated add_mkisofs_opt). ATB, Mark.