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

Re: Bug#927892: grub-ieee1275-bin: Please add bootinfo.txt for sparc and sparc64



On 26/04/2019 18:04, Thomas Schmitt wrote:

> Hi,
> 
>> - the first 32K of an ISO9660 is undefined
> 
> That's such a negative word. :))
> It is "reserved for system use" and "not specified" by ISO 9660 / ECMA-119.
> 
> 
>> - boot.S and diskboot.S get built into cdboot.img
> 
> grub-mkrescue opens cdboot.img for reading and the image file for -G
> for writing and truncates it to 0 length. Then it writes 512 zero bytes,
> reads 512 bytes from cdboot.img and writes them to the -G image file.
> 
> 
>> - grub should run xorisso with the following parameters:
>>     -G cdboot.img -B "..." --grub2-sparc-core
>>     /boot/grub/sparc64-ieee1275/core.img
> 
> Actually these are for the mkisofs emulation of xorriso.
>   xorriso -as mkisofs ...options.and.pathspecs...
> 
> (See man xorrisofs for options.)
> 
> Note that
>   -B ','
> as of grub-mkrescue is not totally equivalent to your
>   -B '...'
> 
> Digging in libisoburn's xorriso/emulators.c i see that "," orders two
> appended partitions with empty disk source paths. This will cause no
> partitions to be appended.
> "..." causes 7 partitions copying the partition entry data of the entry
> before them. That would be the entry describing the ISO image as a whole.
> Again no partitions images get appended.
> 
> One should test both and inspect by SUN tools or
>   xorriso -indev $ISOIMAGE -report_system_area plain
> Probably "..." will produce a partition table with 8 entries, and ","
> will produce a table with only one entry.
> 
> 
>> - what this effectively does is:
>>   - Install a sun partition disk label to sector 0 of the ISO image
>>   - Add the ISO9660 image as the first partition (slice)
>>   - Create all 7 remaining partitions after the ISO9660 image
> 
> I expect this too.
> 
>>   - These partitions are all small and just contain cdboot.img
> 
> I expect what can be seen in debian-10.0-sparc64-NETINST-1.iso
> 
>   Volume id    : 'Debian 10.0 sparc64 n'
>   ...
>   System area summary: SUN-SPARC-Disk-Label
>   ISO image size/512 : 284760
>   SUN SPARC disklabel: CD-ROM Disc with Sun sparc boot created by genisoimage
>   SUN SPARC secs/head: 640
>   SUN SPARC heads/cyl: 1
>   SUN SPARC partmap  :   N   IdTag   Perms    StartCyl   NumBlocks
>   SUN SPARC partition:   1  0x0004  0x0010           0      284160
>   SUN SPARC partition:   2  0x0002  0x0010           0      284160
>   SUN SPARC partition:   3  0x0002  0x0010           0      284160
>   SUN SPARC partition:   4  0x0002  0x0010           0      284160
>   SUN SPARC partition:   5  0x0002  0x0010           0      284160
>   SUN SPARC partition:   6  0x0002  0x0010           0      284160
>   SUN SPARC partition:   7  0x0002  0x0010           0      284160
>   SUN SPARC partition:   8  0x0002  0x0010           0      284160
> 
> xorriso command -pvd_info says:
> 
>   App Id       : GENISOIMAGE ISO 9660/HFS FILESYSTEM CREATOR (C) 1993 E.YOUNGDALE (C) 1997-2006 J.PEARSON/J.SCHILLING (C) 2006-2007 CDRKIT TEAM
>   ...
>   Creation Time: 2019012014210500
> 
> You could put cdboot.img in there by naming it in the comma separated
> list of paths after -B. But i guess you should not.
> 
> --------------------------------------------------------------------------
> The following topics are out of my normal scope. So i can only throw in
> text snippets which may be related:
> 
>> 1) How does boot.S/diskboot.S locate core.img?
> 
> man xorrisofs says about -B:
> 
>       The pseudo disk_path  "..."  causes  that  all  empty  partition
>       entries  become  copies of the last non-empty entry. If no other
>       disk_path is given before "..." then all partitions describe the
>       ISO image. In this case, the boot loader code has to be imported
>       by option -G.
> 
> So having no boot images in the partition table is ok, in principle.
> 
>> This means that when the PROM opens the disk in boot.S, it is directly
>> opening the partition containing cdboot.img rather than the start of the
>> whole disk
> 
> It looks like all partitions lead to CD-ROM (where Nero burns).
> 
> 
>> 2) How to launch xorisso with the correct parameters?
> 
> With two "r" and only one "s". :))
> (xorriso = X/Open on Rock Ridge enhanced ISO 9660)
> 
>> grub-mkinstall
> 
> To what package does this belong ?
> Google proposes to search for "grub-install". But i don't think that this
> is for ISO 9600 production.

Hi Thomas,

Thanks again for all the information here, and my apologies for misspelling xorriso.

I've now double checked this against the SILO-based CDROM and I can see that the key
here is that the a.out loader is executed from sector 1 directly, and not the
individual slices. This means as per your partition table above we can set all slices
to the ISO image which also solves my question about how the bootpath lookup in
boot.S can work given that the slice is included.

Adrian: based upon this I think what you need to do is:

- For consistency rename /boot/grub/sparc64.elf to /boot/grub/core.img to match
  the descriptions of the grub components in the documentation

- Confirm that cdboot.img is the a.out executable generated by boot.S and diskboot.S
  (use dd and hexdump to check for the 0x01 0x03 0x01 0x07 signature in the first 4
  bytes)

- In your second patch re-enable the -G/-B options but with -G set to cdboot.img:
     add_mkisofs_opt $CDDIR/../$N.mkisofs_opts "-G cdboot.img -B ..."

Once this is done and the ISO image is generated, the basic setup can be checked as
follows:

- Use fdisk or similar tool to confirm that the Sun disk label exists at the
  start of the .iso with all 8 partitions starting at sector 0 with an end sector
  representing the contents of the whole CDROM image

- Use dd and hexdump to confirm that cdboot.img appears 512 bytes into the .iso
  by checking for the 0x01 0x03 0x01 0x07 signature

- Next check the offset and size of /boot/grub/core.img embedded in sector 1 using
  dd and hexdump. As per Thomas' message you should find the offset in bytes of
  the start of /boot/grub/core.img at offset 552 from the start of the .iso (64-bit
  big endian) and its size at offset 560 from the start of the .iso (32-bit big
  endian)

- If everything is correct then again using dd and hexdump you should be able to
  see the ELF signature for core.img from the offset discovered above.

Assuming all of this looks correct, then I believe that you should end up with a
bootable CDROM image using grub...


ATB,

Mark.


Reply to: