Summary: An Apple laptop containing a single drive, GPT, with 8 partitions, booting CentOS 6.0, anaconda crashes with a backtrace implicating libparted. Running "parted -l" results in a crash as well. This did not happen prior to the creation of a core storage* partition type to encrypt a Mac OS X logical volume (a.k.a. Lion FileVault).
Booting Fedora 16, which uses parted 3.0, "parted -l" works fine on the same drive containing the same core storage partition. I don't know that parted 3.0 actually knows what a core storage partition is, but at least it doesn't crash. Detail: screen shot of crashed anaconda with backtrace, from CentOS 6.0 DVD Install: http://postimage.org/image/lxkze0vi9/ 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]# Questions: Is it clear from either backtrace exactly what the problem is, and if so what is it? Is this explicitly a known problem that has been fixed in newer versions of parted (rather than just coincidentally no longer crashing)? If so, in what version of parted was it fixed, if prior to 3.0? Since this affects CentOS 6.0-6.2, it almost certainly affects RHEL 6.0-6.2 so I'd kinda like to have a better idea what the problem and possible solution is before filing a bug report with either CentOS or RH. Regression: I have not tried either changing the core storage partition's partition type GUID to a bogus (but familiar) GUID, to see if this is merely about the GUID. Nor have I tried wiping that partition to see if it's about parted puking when scanning the content of the core storage partition. Nor have I tested a version of parted between 2.1 and 3.0 to see when parted stopped crashing. * Core Storage is Apple's logical volume management implementation. The partition type GUID for a core storage partition is 53746F72-6167-11AA-AA11-00306543ECAC. Thanks, Chris Murphy
