> On May 29, 2023, at 4:34 PM, Linux User #330250 <linuxuser330...@gmx.net>
> wrote:
>
> On 05/29 2023 13:52 John Paul Adrian Glaubitz wrote:
>
> BTW, a workaround similar to the one yaboot may use would be to only
> have an image of an empty HFS volume (of fixed size) as a package, and
> use the free (now unmaintained, but who cares?) hfsutils hcopy and
> hattrib for the rest. Re-initializing the image would only make it
> necessary to recopy the boot files. All that's missing is mkfs and fsck,
> both are not required if we were to use an image of an empty HFS filesystem.
If I am going this way, I can also just use hformat. But again, this does not
integrate well with the partitioning tool in debian-installer and will confuse
users.
Any code design that does not build on mkfs.hfs or mkfs.hfsplus will be opaque
to users.
>
>> Because I am talking about Apple's »diskdev_cmds« and »hfs« packages, not
>> the ones
>> you mentioned above which are both dead upstream, by the way. Apple's
>> packages are
>> APSL which Debian considers non-free, unfortunately [1].
>
> Thanks. I knew Debian is very restrictive, especially between free and
> non-free, which is why I'm very much in favour of Debian in the first
> place. The PITA on x86 always was the non-free firmware. Seeing how
> Debian moved to include those non-free firmware blobs not very long ago
> makes me wonder if such an exception wouldn't also be possible for
> diskdev_cmds, since this seems quite essential on PowerPCs (just like
> firmware blobs on x86).
> How did Debian include the non-free firmware? Would there be a similar
> way to get diskdev_cmds into the powerpc port?
The problem is that the Debian Ports infrastructure currently does not support
non-free. Plus, debian-installer expects all of its components to be part of
the “main” section.
»hfsprogs-udeb« is the only udeb, i.e. d-i package in non-free and no one had
ever move a udeb to non-free.
If it was that easy, I would have resolved that issue long ago. Unfortunately,
it’s a hard problem.
>> Not by Debian, see [1]. If you feel like convincing the Debian Legal team
>> that
>> APSL is DFSG-compatible, please go ahead. I have given up on this.
>
> Well, reading the discussion about the license makes me be on their
> side. But then, it's like the firmware blobs: in theory we don't want
> them in a free operating system, but in reality we have not much of a
> choice if we want to actually use the hardware...
Well, Apple could just relicense the split-out »hfs« package to MIT or any BSD
license. They have the power to do so.
I could then switch the »hfsprogs« package from the »diskdev_cmds« to the
split-out »hfs« package.
>> hfsutils works like mtools, it doesn't use the kernel's VFS layer. Tools
>> like "fsck"
>> and "mkfs" are still on the TODO list as you can see in the TODO file [2] ...
>
> Thanks, I missed this important detail. hformat is just a stub, it
> doesn't really do anything...
Oh, I wasn’t aware of that.
>> Just having a fully working »hfsprogs« under a DFSG-compatible license
>> available would
>> solve all the problems with the bootloader installation on Apple PowerMac,
>> including
>> making the whole process much more robust and also compliant with the
>> remaining archi-
>> tectures.
>
> Yes.
>
> If I find the time, I'll play a bit with FAT formatted bootstrap
> partitions. Maybe something undocumented actually works. I hate the idea
> though that a NVRAM bootdevice setting would be necessary, I very much
> prefer an out-of-the-box OS Picker compatible way. But since :tbxi is a
> no-go with FAT, I honestly doubt that there is…
Setting the firmware path in NVRAM works but is very fragile. We used it in the
past until I actually learned how the NewWorld firmware finds the bootloader on
disk.
Adrian
