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 
out was missing from my previous email (see
https://lists.debian.org/debian-sparc/2019/04/msg00057.html for the updated



Reply via email to