Hello Frank!
On 11/7/20 2:44 PM, Frank Scheiner wrote:
> Looks like the new version indeed fixes the problem! Great! :-)
Good to know, will close this issue then now.
The downside of the new version is - at the moment at least - that it does no
longer allow the creation of legacy HFS
Hi again,
On 01.11.20 20:07, John Paul Adrian Glaubitz wrote:
I just uploaded a new upstream release, version 540.1.
Please check whether this version fixes the problem for you.
Looks like the new version indeed fixes the problem! Great! :-)
I was "lucky" and found my HFS partition "dirty"
Hi Adrian,
On 01.11.20 20:07, John Paul Adrian Glaubitz wrote:
I just uploaded a new upstream release, version 540.1.
Great!
Please check whether this version fixes the problem for you.
I will do. I just don't know, how to break my HFS partition, so
`fsck.hfs` has something to fix. But
Hi Frank!
I just uploaded a new upstream release, version 540.1.
Please check whether this version fixes the problem for you.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-
On Tue, Jan 08, 2019 at 10:40:55AM +0100, Frank Scheiner wrote:
> On 1/7/19 22:13, John Paul Adrian Glaubitz wrote:
> > On 1/7/19 10:09 PM, Frank Scheiner wrote:
> > > Program received signal SIGSEGV, Segmentation fault.
> > > 0x000100034be4 in hfs_swap_HFSBTInternalNode (src=0x7fffd3a8,
On 1/17/19 01:11, Frank Scheiner wrote:
On 1/17/19 00:54, John Paul Adrian Glaubitz wrote:
On 1/17/19 12:35 AM, Frank Scheiner wrote:
On 1/7/19 08:23, Mathieu Malaterre wrote:
Submit this email as bug against hfsprogs. It seems the bug can easily
be tracked even from a non-corrupted partition
On 1/17/19 00:54, John Paul Adrian Glaubitz wrote:
On 1/17/19 12:35 AM, Frank Scheiner wrote:
On 1/7/19 08:23, Mathieu Malaterre wrote:
Submit this email as bug against hfsprogs. It seems the bug can easily
be tracked even from a non-corrupted partition (disk?). Thanks
This is now filed as
On 1/17/19 12:54 AM, John Paul Adrian Glaubitz wrote:
> Debian has 332.25 while upstream is already at 593. If the latest upstream
> version doesn't support PowerPC anymore, try anything between 332.25 and
> 593.
Looks like for versions after 557.3.1, i.e. from 572.1.1, fsck_hfs was moved
into
On 1/17/19 12:35 AM, Frank Scheiner wrote:
> On 1/7/19 08:23, Mathieu Malaterre wrote:
>> Submit this email as bug against hfsprogs. It seems the bug can easily
>> be tracked even from a non-corrupted partition (disk?). Thanks
>
> This is now filed as bug [#919532].
I don't think you will have
On 1/7/19 08:23, Mathieu Malaterre wrote:
Submit this email as bug against hfsprogs. It seems the bug can easily
be tracked even from a non-corrupted partition (disk?). Thanks
This is now filed as bug [#919532].
Cheers,
Frank
[#919532]:
On 08/01/2019 18:45, Frank Scheiner wrote:
> On 1/8/19 14:15, Mark Cave-Ayland wrote:
>> Do you see the fsck error on all filesystems or just /dev/sda4?
>
> I only have one HFS (actually /dev/sda2) on the used disk. And the `fsck.hfs`
> errors
> happen with both clean and damaged HFSes.
>
>>
On 1/8/19 14:15, Mark Cave-Ayland wrote:
Do you see the fsck error on all filesystems or just /dev/sda4?
I only have one HFS (actually /dev/sda2) on the used disk. And the
`fsck.hfs` errors happen with both clean and damaged HFSes.
I'd be interested to
do a side-by-side comparison with the
On 08/01/2019 09:40, Frank Scheiner wrote:
> On 1/7/19 22:13, John Paul Adrian Glaubitz wrote:
>> On 1/7/19 10:09 PM, Frank Scheiner wrote:
>>> Program received signal SIGSEGV, Segmentation fault.
>>> 0x000100034be4 in hfs_swap_HFSBTInternalNode (src=0x7fffd3a8,
>>> fcb=0x100081898,
On 1/8/19 10:40, Frank Scheiner wrote:
(gdb) p src
$1 = (BlockDescriptor *) 0x7fffd2f8
(gdb) p srcDesc
$2 = (BTNodeDescriptor *) 0x75c91200
(gdb) p srcOffs
$3 = (uint16_t *) 0x75c913fe
(gdb) p sizeof(uint16_t)
$4 = 2
(gdb) p sizeof(BlockDescriptor)
$5 = 32
(gdb) p
On 1/8/19 10:33 AM, Michel Dänzer wrote:
> On 2019-01-07 10:13 p.m., John Paul Adrian Glaubitz wrote:
>>
>> My wild guess would be that the code uses C types which have different
>> lengths on 32- and 64-bit systems where it should really use type with
>> defined lengths, i.e. "uint32" instead of
On 2019-01-07 10:13 p.m., John Paul Adrian Glaubitz wrote:
>
> My wild guess would be that the code uses C types which have different
> lengths on 32- and 64-bit systems where it should really use type with
> defined lengths, i.e. "uint32" instead of "int".
FWIW, sizeof(int) == 4 on all Linux
On 1/7/19 22:13, John Paul Adrian Glaubitz wrote:
On 1/7/19 10:09 PM, Frank Scheiner wrote:
Program received signal SIGSEGV, Segmentation fault.
0x000100034be4 in hfs_swap_HFSBTInternalNode (src=0x7fffd3a8,
fcb=0x100081898, direction=kSwapBTNodeBigToHost) at hfs_endian.c:883
883
On 1/7/19 10:09 PM, Frank Scheiner wrote:
> Program received signal SIGSEGV, Segmentation fault.
> 0x000100034be4 in hfs_swap_HFSBTInternalNode (src=0x7fffd3a8,
> fcb=0x100081898, direction=kSwapBTNodeBigToHost) at hfs_endian.c:883
> 883 hfs_endian.c: No such file or directory.
I
On 1/7/19 21:57, Mark Cave-Ayland wrote:
On 07/01/2019 19:57, Frank Scheiner wrote:
root@powermac-g5:~# gdb --args /sbin/fsck.hfs -d /dev/sda2
GNU gdb (Debian 8.2-1) 8.2
[...]
Reading symbols from /sbin/fsck.hfs...done.
(gdb) run
Starting program: /sbin/fsck.hfs -d /dev/sda2
[Thread debugging
On 07/01/2019 19:57, Frank Scheiner wrote:
> On 1/7/19 13:10, John Paul Adrian Glaubitz wrote:
>> On 1/7/19 1:09 PM, Frank Scheiner wrote:
$ gdb --args /path/to/hfsprogs --param1 --param2
The "--args" argument to gdb is necessary so that gdb calls the binary with
"--param1
On 1/7/19 13:10, John Paul Adrian Glaubitz wrote:
On 1/7/19 1:09 PM, Frank Scheiner wrote:
$ gdb --args /path/to/hfsprogs --param1 --param2
The "--args" argument to gdb is necessary so that gdb calls the binary with
"--param1 --param2".
Thanks, I'll give that a try and report the results.
On 1/7/19 1:09 PM, Frank Scheiner wrote:
>> $ gdb --args /path/to/hfsprogs --param1 --param2
>>
>> The "--args" argument to gdb is necessary so that gdb calls the binary with
>> "--param1 --param2".
>
> Thanks, I'll give that a try and report the results.
Oh, and once it crashes, type "bt" to
On 1/7/19 13:01, John Paul Adrian Glaubitz wrote:
Hi Frank!
On 1/7/19 12:57 PM, Frank Scheiner wrote:
Can you post a backtrace from a package build with debug symbols? I suspect
this will
be something quite obvious, i.e. using pointers to int/long rather than specific
32-bit types in the HFS
Hi Frank!
On 1/7/19 12:57 PM, Frank Scheiner wrote:
>> Can you post a backtrace from a package build with debug symbols? I suspect
>> this will
>> be something quite obvious, i.e. using pointers to int/long rather than
>> specific
>> 32-bit types in the HFS code.
>
> Sure, if you can provide
On 1/7/19 12:37, Mark Cave-Ayland wrote:
So how do we proceed from here?
Can you post a backtrace from a package build with debug symbols? I suspect
this will
be something quite obvious, i.e. using pointers to int/long rather than specific
32-bit types in the HFS code.
Sure, if you can
On 06/01/2019 20:48, Frank Scheiner wrote:
> Hi Mathieu,
>
> On 1/4/19 08:51, Mathieu Malaterre wrote:
>> On Thu, Jan 3, 2019 at 5:54 PM Frank Scheiner wrote:
>>> On 1/3/19 12:10, Mathieu Malaterre wrote:
The way you describe this bug makes me think of a 64bits vs 32bits
issue. Next
On Sun, Jan 6, 2019 at 9:48 PM Frank Scheiner wrote:
>
> Hi Mathieu,
>
> On 1/4/19 08:51, Mathieu Malaterre wrote:
> > On Thu, Jan 3, 2019 at 5:54 PM Frank Scheiner wrote:
> >> On 1/3/19 12:10, Mathieu Malaterre wrote:
> >>> The way you describe this bug makes me think of a 64bits vs 32bits
>
Hi Mathieu,
On 1/4/19 08:51, Mathieu Malaterre wrote:
On Thu, Jan 3, 2019 at 5:54 PM Frank Scheiner wrote:
On 1/3/19 12:10, Mathieu Malaterre wrote:
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
On Thu, Jan 3, 2019 at 5:54 PM Frank Scheiner wrote:
>
> On 1/3/19 12:10, Mathieu Malaterre wrote:
> > On Sun, Dec 30, 2018 at 9:54 PM Frank Scheiner
> > 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
On 1/3/19 12:10, Mathieu Malaterre wrote:
On Sun, Dec 30, 2018 at 9:54 PM Frank Scheiner 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
On Sun, Dec 30, 2018 at 9:54 PM Frank Scheiner wrote:
>
> Dear all,
>
> I experienced some major problems with hfsprogs on G5 Power Macs.
>
> Once in a while (already seen multiple times on 11,2 and 7,3 type Power
> Macs) the OS refuses to mount the NewWorld boot
Hi Mathieu, all,
On 1/2/19 17:40, Mathieu Malaterre wrote:
On Sun, Dec 30, 2018 at 9:54 PM Frank Scheiner wrote:
I experienced some major problems with hfsprogs on G5 Power Macs.
I vaguely recall also some data corruption when playing with HFS back then:
https://lists.debian.org/debian
On Sun, Dec 30, 2018 at 9:54 PM Frank Scheiner wrote:
>
> Dear all,
>
> I experienced some major problems with hfsprogs on G5 Power Macs.
I vaguely recall also some data corruption when playing with HFS back then:
https://lists.debian.org/debian-powerpc/2016/04/msg00103.html
IS
Dear all,
I experienced some major problems with hfsprogs on G5 Power Macs.
Once in a while (already seen multiple times on 11,2 and 7,3 type Power
Macs) the OS refuses to mount the NewWorld bootstrap - or simply HFS -
partition that hosts the GRUB installation at startup in read-write
mode
34 matches
Mail list logo
