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

[Jim Meyering]

Chris Murphy wrote:
> Since I'm unable to get past the crash to install CentOS, I don't have
> a way to install debug symbols, since I'm booted off install media.
>
> Perhaps an easier way to test this is if I could dd the first XX MB of
> the suspected (encrypted) partition, to an image file (as a backup
> which I could also supply you with). And then dd zero that same number
> of sectors of that partition. Then maybe the fs-probe won't get
> tripped up?
>
> This won't necessarily tell us if the problem is due to an encrypted
> logical volume within that partition, or the unexpected core storage
> structures which are unencrypted (not dissimilar to the LVM2 metadata
> written on an LVM containing partition). To further test, I'd need to
> decrypt that partition and see if the problem remains. A lot of work
> for something that isn't a problem with at least parted 3.0 - mostly
> it sounds like RHEL 6 just needs to move to a newer version of parted,
> I'm not sure which one though.
>
> If the dd routine makes sense, how big of a structure is the fs-probe
> looking for that I need to remove? I'm assuming the probing is at the
> beginning of the partition, but I'm not sure how much data it's
> looking for.

Maybe you can strace it, looking at seeks and single-sector reads?
But it's hard to tell, because it probes for many FS types, not just HFS*.

Unfortunately, (i've just looked), it's not easy to predict
which sectors will be probed for hfs+.  Most probe functions
look only at the first couple sectors, and maybe something
near the end.   Not so with HFS:

These are the two functions in libparted/fs/hfs/probe.c:

  hfs_and_wrapper_probe
  hfsplus_probe

The first read is of sector 2 (relative to start of partition).
But then we might read another sector from a wrapped volume, at a
dynamically calculated offset, looking for another HFSP_SIGNATURE.

Easiest might be if you could make a copy of the disk, mount the
partitions and fill any that might have sensitive data with a single
file filled with zero bytes.  Then sparsify and tar up and post that image.

Now that I think of it, I'll bet this is an instance of that wrapped
partition.  You've probably triggered an excursion into libparted code
that is rarely used, to handle that wrapped/encrypted partition.