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: >> [centoslive@livedvd ~]$ su >> [root@livedvd 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) >> [root@livedvd 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.