[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:59:37 +0100 |
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.
- parted 2.1 crash with (encrypted) Apple Core Storage partition, Chris Murphy, 2012/02/08
- Re: parted 2.1 crash with (encrypted) Apple Core Storage partition, Chris Murphy, 2012/02/08
- Re: parted 2.1 crash with (encrypted) Apple Core Storage partition, Jim Meyering, 2012/02/08
- Re: parted 2.1 crash with (encrypted) Apple Core Storage partition, Chris Murphy, 2012/02/08
- Re: parted 2.1 crash with (encrypted) Apple Core Storage partition,
Jim Meyering <=
- Re: parted 2.1 crash with (encrypted) Apple Core Storage partition, Chris Murphy, 2012/02/08
- Re: parted 2.1 crash with (encrypted) Apple Core Storage partition, Jim Meyering, 2012/02/09
- Re: parted 2.1 crash with (encrypted) Apple Core Storage partition, Chris Murphy, 2012/02/09
- Re: parted 2.1 crash with (encrypted) Apple Core Storage partition, Jim Meyering, 2012/02/09
- Re: parted 2.1 crash with (encrypted) Apple Core Storage partition, Chris Murphy, 2012/02/09
- Message not available
- Message not available
- Re: parted 2.1 crash with (encrypted) Apple Core Storage partition, Chris Murphy, 2012/02/09
- Re: parted 2.1 crash with (encrypted) Apple Core Storage partition, Chris Murphy, 2012/02/09
- Re: parted 2.1 crash with (encrypted) Apple Core Storage partition, Jim Meyering, 2012/02/09
- Re: parted 2.1 crash with (encrypted) Apple Core Storage partition, Chris Murphy, 2012/02/09
Re: parted 2.1 crash with (encrypted) Apple Core Storage partition, Chris Murphy, 2012/02/09