[Top][All Lists]

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

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

From: Jim Meyering
Subject: Re: parted 2.1 crash with (encrypted) Apple Core Storage partition
Date: Wed, 08 Feb 2012 21:20:31 +0100

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)

reply via email to

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