Re: parted 2.1 crash with (encrypted) Apple Core Storage partition

[Jim Meyering]

Chris Murphy wrote:

> On Feb 8, 2012, at 12:27 PM, Chris Murphy wrote:
>>
>> text output trying to run "parted -l", booted from CentOS 6.2 LiveDVD:
>> address@hidden ~]$ su
>> address@hidden centoslive]# parted -l
>> Backtrace has 14 calls on stack:
>>  14: /lib64/libparted-2.1.so.0(ped_assert+0x31) [0x7f4e6888cfb1]
>>  13: /lib64/libparted-2.1.so.0(ped_geometry_read+0x80) [0x7f4e688949d0]
>>  12: /lib64/libparted-2.1.so.0(hfsplus_probe+0x279) [0x7f4e688b05f9]
>>  11: /lib64/libparted-2.1.so.0(ped_file_system_probe_specific+0x5c)
>> [0x7f4e6888e57c]
>>  10: /lib64/libparted-2.1.so.0(ped_file_system_probe+0xa5) [0x7f4e6888eb25]
>>  9: /lib64/libparted-2.1.so.0(+0x4253f) [0x7f4e688bd53f]
>>  8: /lib64/libparted-2.1.so.0(ped_disk_new+0x75) [0x7f4e68894165]
>>  7: parted() [0x40692c]
>>  6: parted() [0x4077cd]
>>  5: parted() [0x409764]
>>  4: parted() [0x40a95f]
>>  3: parted(main+0x2c) [0x40aa6c]
>>  2: /lib64/libc.so.6(__libc_start_main+0xfd) [0x7f4e68094cdd]
>>  1: parted() [0x404f49]
>> Aborted (core dumped)
>> address@hidden centoslive]#
>
> The identical sequence (except for some of the numbers in []'s) still
> occurs after changing the two Apple produced partitions (core storage
> and recovery hd) that have relatively new partition type GUIDs, to the
> basic data partition type GUID
> EBD0A0A2-B9E5-4433-87C0-68B6B72699C7. So it seems like despite not a
> single partition type GUID announcing an hfs+ volume, there's still
> hfsprobing occurring, and I'm going to guess the problem is with the
> scanning of the content of one or more partitions.

Right.  An FS-probe usually looks for the "magic number" of each
FS type it knows about (sometimes with a few other constraints).
So my recipe is incomplete, since it would have you zero out all
FS data.  If you can zero out all data and leave an HFS+ signature
in each partition, or maybe a bare HFS+ file system in each partition,
*then* I should be able to reproduce.