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

[Jim Meyering]

Chris Murphy wrote:
> 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:
> 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]#
>
> 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?

Thanks for the detailed report.

I'd guess it's probably hitting one of these PED_ASSERTs:
(this is from the latest -- may have changed since 2.1)

ped_geometry_read (const PedGeometry* geom, void* buffer, PedSector offset,
                   PedSector count)
{
        PedSector       real_start;

        PED_ASSERT (geom != NULL);
        PED_ASSERT (buffer != NULL);
        PED_ASSERT (offset >= 0);
        PED_ASSERT (count >= 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.

If you can install debug symbols, the backtrace will include
helpful line number information.

> 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.

I would be surprised to learn we have not fixed it.
A lot has changed in the two years since 2.1.

> * Core Storage is Apple's logical volume management
> implementation. The partition type GUID for a core storage partition
> is 53746F72-6167-11AA-AA11-00306543ECAC.

If you would like to pursue this, the best is to make it trivial
for me to reproduce.  To do that, you can make a copy of the disk
and do the following:

 -- zero out whatever parts you don't want to share, other than the first
   and last 17KiB (assuming your backup GPT header is at end of disk)
 -- copy that image with "cp --sparse=always f.img f-sparse.img" (GNU cp)
   on a file system that supports sparse files.
   This should now be a very small file, according to du.
   Finally, use GNU tar to create a small tarball, efficiently:
     tar Svcf - f-sparse.img > f-sparse.img.tar
   and post that file as an attachment.  If you have xz handy,
   do this instead:
     tar Svcf - f-sparse.img |xz -ev > f-sparse.img.tar.xz
   and post the smaller-still .xz file.

With that, I will try to reproduce the problem.

(or alternately, just extract the 17KiB from start and end and post
those, along with the sector size and precise length of your device)