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:
> [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?
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)
