Re: Switching debian-installer CD images to GRUB
> > [...] 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
uninstall other GRUB targets and then make a minimal grub-mkrescue ISO:
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
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
> 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.
> 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
One would try to generalize the following files or to write new
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.
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
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
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.)
Have a nice day :)