[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

parted 2.1 crash with (encrypted) Apple Core Storage partition

From: Chris Murphy
Subject: parted 2.1 crash with (encrypted) Apple Core Storage partition
Date: Wed, 8 Feb 2012 12:27:56 -0700

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.

screen shot of crashed anaconda with backtrace, from CentOS 6.0 DVD Install:

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) 
  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]# 

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 

* Core Storage is Apple's logical volume management implementation. The 
partition type GUID for a core storage partition is 


Chris Murphy

reply via email to

[Prev in Thread] Current Thread [Next in Thread]