Re: Switching debian-installer CD images to GRUB
On 29/04/2019 13:05, Thomas Schmitt wrote:
> Hi,
>
> i wrote:
>>> [...] Fedora HFS image [...]
>>> I think Fedora uses hfsutils to create and populate it.
>
>> My colleague Marcus Schaefer at SUSE told me
>> about this solution. He's the maintainer of SUSE's KIWI image tool (but
>> I think you know that ;)).
>
> I had contact with him last year.
>
>> We could give indeed this solution a try, with EFI replaced with IEEE1275.
>
> But first you should explore whether ppc64 is served by grub-mkrescue's
> way of HFS+. Vladimir must have had some architecture in mind, when he
> contributed that code to libisofs and asked for the xorrisofs options
> to control it.
>
> What happens if you install
> https://packages.debian.org/sid/ppc64/grub-ieee1275-bin/filelist
> uninstall other GRUB targets and then make a minimal grub-mkrescue ISO:
>
> mkdir minimal
> touch minimal/empty-file.txt
> grub-mkrescue -o output.iso minimal
>
> Does output.iso boot to a GRUB console prompt when offered on CD or
> hard-disk-like medium ?
> (Beware: The grub-ieee1275-bin filelists differ from host arch to host
> arch.
> https://packages.debian.org/sid/amd64/grub-ieee1275-bin/filelist
> has files for i386-ieee1275 rather than powerpc-ieee1275.
> But ppc64 and ppc64el look the same.
> )
>
> The mini HFS image approach is probably needed with older powerpc.
> When the HFS+ code in libisofs was young, its then Debian maintainer
> George Danchev tried whether it could substitute for genisoimage's HFS
> on a virtual machine which booted the genisoimage ISO.
> A user rported failure with
> $ qemu-system-ppc -boot d -cdrom repacked.iso -hda linux.img
Do you have any more information on this? As the current maintainer of OpenBIOS and
the QEMU Mac machines I'm not aware of any outstanding issues in this area.
FWIW this is one of the ideal use cases for QEMU since you can prototype the basic
boot process without going anywhere near physical media.
>> as far as I know, 64-bit PowerMacs aren't any different
>> than 32-bit PowerMacs when it comes to the firmware as long as the 32-bit
>> Macs are using NewWorld ROMs.
>
> Hard to say what firmware was used by qemu-system-ppc at the end of 2012.
I would have expected it to be OpenBIOS around that time, but certainly its
predecessor OHW (OpenHackWare) was quite buggy.
>> What about a funding? I would actually be willing to shell out some money
>> for that if someone worked on implementing HFS support.
>
> One could implement it in libisofs as alternative to HFS+.
> This would simplify the inner architectural effort by re-using the
> existing plug-in points of HFS+. (Calls of hfsplus_*() in
> https://dev.lovelyhq.com/libburnia/libisofs/raw/master/libisofs/ecma119.c
> )
> One would try to generalize the following files or to write new
> counterparts:
> https://dev.lovelyhq.com/libburnia/libisofs/raw/master/libisofs/hfsplus.h
> https://dev.lovelyhq.com/libburnia/libisofs/raw/master/libisofs/hfsplus.c
> https://dev.lovelyhq.com/libburnia/libisofs/raw/master/libisofs/hfsplus_case.c
> https://dev.lovelyhq.com/libburnia/libisofs/raw/master/libisofs/hfsplus_classes.c
> https://dev.lovelyhq.com/libburnia/libisofs/raw/master/libisofs/hfsplus_decompose.c
>
> It must look to me like safe code and it must be free of unfriendly
> licenses or copyright holders. (The license must enable derived LGPLv2.
> Foreign copyrights could be isolated in a separate library, like
> was done with libjte.)
>
> If new options are needed, then several more files in libisofs and
> libisoburn will be affected. I would be willing to do this part which
> mainly is about pulling wires through the architecture layers.
As per my last email, if sponsorship is available then possibly this is something we
could collaborate on. But again I would expect HFS+ to work here...
> Maybe a more feasable job would be the Fedora image file approach:
>
> I assume that files from the genisoimage ISO content would have to be
> migrated into a hfsutils made HFS image, which xorriso puts into the
> ISO as data file or appends after the ISO as partition. Then xorriso
> marks it by Apple Partition Map.
>
> Knowledge about the boot procedure of powerpc firmware will surely be
> of help.
>
> One would need to explore grub-mkrescue ISOs and existing powerpc
> ISOs, whether there are machines where genisoimage -hfs ISO succeeds but
> grub-mkrescue's ISO fails.
>
> Then one would try to find out what miracles are done by genisoimage
> options
> --netatalk
> -hfs
> -probe
> -map /home/debian-cd/build/debian-cd.squeeze/data/hfs.map
> -hfs-parms MAX_XTCSIZE=2656248
> -part
> -no-desktop
> -hfs-bless CD1/install
>
> I can make some sense out of the genisoimage man page:
>
> -part causes Apple Partition Map, which would be the job of xorriso if
> a HFS image file is put into the ISO. Like isohybrid --mac for Fedora.
>
> -hfs-bless blesses a directory. grub-mkrescue only blesses the Intel
> Boot file, but not a directory for GRUB_INSTALL_PLATFORM_POWERPC_IEEE1275.
> I assume that genisoimage -hfs-bless applies blessing PPC Bootdir to that
> directory. hfsutils program hattrib option -b looks like that.
>
> -map is probably the other job of hattrib: setting Type and Creator.
> One would have to look for old hfs.map files or use hfsutils program hls
> option -l to learn about attributes in existing genisoimage ISOs.
>
> ------------------------------------------------------------------------
>
>> cdrkit which Debian wants to get rid of as it's unmaintained upstream.
>
> I am sure that Steve McIntyre lights a candle for every architecture ISO
> production which you switch away from genisoimage.
> But chances are that genisoimage will live as long as powerpc needs HFS
> rather than HFS+.
> (And there is -udf, which is needed for DVD video.)
For Old World Macs you'd want quik/iquik which uses %BOOT to extract the next stage
bootloader from a special sector, and for New World Macs the process is effectively
what yaboot does: bless the folder on the filesystem containing the bootloader and
then set the type to TBXI (ToolBoXImage).
ATB,
Mark.
Reply to: