On 1/3/19 12:10, Mathieu Malaterre wrote:
On Sun, Dec 30, 2018 at 9:54 PM Frank Scheiner <frank.schei...@web.de> wrote:
So one actually cannot repair that issue from a G5 - or maybe not even
any issue with an HFS at all, because the same also happens when trying
to check a clean HFS with `fsck.hfs`. The result is that an existing
GRUB installation can no longer be upgraded on a G5 as soon as someone
hits that problem. Actually I'm also unsure if my HFS problems were
created by an unclean shutdown at all.
One could solve this by recreating the HFS partition from scratch and
restoring the contents (incl. file blessing and file types (i.e.
`tbxi`)). Or maybe by rewriting a `dd`ed image from a clean HFS - if you
have one at hand. Trying to repair the partition with `fsck.hfs` from a
Mac mini G4 (via SATA to USB adapter) worked for me also. But all these
workarounds are unhandy to the least.
The way you describe this bug makes me think of a 64bits vs 32bits
issue. Next time this happen to you, use a foreign powerpc
installation to run ppc32 binary on your G5.
That's a good idea and I think we don't even have to wait for the next
time this issue hits me, as even for a clean HFS the `fsck.hfs`
segfaults. The significance of the result of such a test will not be the
same as for checking a borked HFS, but could show a tendency.
Say, will a powerpc64 kernel from arch ppc64 work with a userland from
arch powerpc or do I need the powerpc64 kernel from arch powerpc? Or are
these kernels actually identical?
Because such a configuration I could setup easily by just changing the
root FS that the machine uses when network booting.
Cheers,
Frank
