bug-parted
[Top][All Lists]
Advanced

[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: Thu, 09 Feb 2012 07:41:47 +0100

Chris Murphy wrote:
> On Feb 8, 2012, at 10:44 PM, Jim Meyering wrote:
>> You're right that I may be able to reproduce simply with one
>> of those encrypted partitions.  Can you create a minimal one and send it?
>
>
> I made a small one on a boot stick, moved it to a VM with CentOS 6.2
> running, and cannot reproduce the problem. In fact, parted sees the
> core storage enclosed logical volume's name, even though it doesn't
> identify the file system being used.
>
> I inserted another boot stick, that contains an 'Apple boot' partition
> with a minimum system. This is also new in Lion and is actually used
> as the initial boot partition only when the primary partition has been
> encrypted. When that's inserted, the problem is reproducible - parted
> crashes only upon trying to list the contents of that USB stick (it
> lists the contents for sda just fine).
>
> The problem though, with assuming it's the Apple Boot partition, is
> that I had this working fine two months ago with such an Apple boot
> (this is GUID 426F6F74-0000-11AA-AA11-00306543ECAC). So either some
> Apple update has messed with this partition in some way since then, or
> I did (entirely possible).
>
> So even if I've somehow sabotaged either of the two 620MB Apple Boot
> partition examples I have that cause this problem, I'm thinking it
> might be useful to find out why parted is crashing because it probably
> shouldn't crash. Even though this is pretty obscure. Maybe?

If it makes CentOS6.2's parted abort, then I will be happy to work on
it.  Can you install debug symbols and invoke parted via gdb?

    gdb --args parted <your usual options>

Then type "run".
If it crashes, type "backtrace" (aka "bt") and post the result.
"list" prints a few lines around the point of abort, (not useful
immediately, when failing via abort).  Usually you'll run "up" repeatedly,
until you find the PED_ASSERT line that provoked the failed assertion.
Once there, "list" is useful, and "print" (aka "p VARIABLE_NAME") to
inspect whatever variable values have not been optimized away.



reply via email to

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