Bug 1039724 - RFE libblkid should be able to identify ID_FS_TYPE contained within Apple Core Storage partitiontypeGUID partitions
Summary: RFE libblkid should be able to identify ID_FS_TYPE contained within Apple Cor...
Keywords:
Status: ASSIGNED
Alias: None
Product: Fedora
Classification: Fedora
Component: util-linux
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Karel Zak
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1033778
TreeView+ depends on / blocked
 
Reported: 2013-12-09 21:02 UTC by Chris Murphy
Modified: 2017-12-08 00:03 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-12-10 11:55:50 UTC
Type: Bug


Attachments (Terms of Use)
acs_encr.sparse.img.xz (1022.70 KB, application/x-xz)
2013-12-13 19:10 UTC, Chris Murphy
no flags Details
acs_encr_end.sparse.img (56.94 KB, application/x-xz)
2013-12-13 19:32 UTC, Chris Murphy
no flags Details

Description Chris Murphy 2013-12-09 21:02:57 UTC
Description of problem:
libblkid does not recognize GPT partitiontypeGUID, but should.

Version-Release number of selected component (if applicable):
util-linux-2.24-2.fc20.x86_64

How reproducible:
Always

Steps to Reproduce:
Actual results:

See bug 1033778 for example of consequences.


Additional info:
The partitiontypeGUID for Apple Core Storage is 53746F72-6167-11AA-AA11-00306543ECAC.

Comment 1 Karel Zak 2013-12-10 11:55:50 UTC
I have already replied in big #1033778. The blkid returns the GUID as a string in ID_PART_ENTRY_TYPE=.

From my point of view this is not a bug.

Comment 2 Chris Murphy 2013-12-13 19:01:19 UTC
re: bug 1033778 comment 20 "It would be the best long-term solution to identify the real content on the devices to have proper ID_FS_TYPE"

Apple Core Storage is the OS X logical volume manager. Partitions with this partitiontypeGUID are PVs with some metadata at the start and end of the partition.
https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man8/diskutil.8

Comment 3 Chris Murphy 2013-12-13 19:10:09 UTC
Created attachment 836476 [details]
acs_encr.sparse.img.xz

This is the first 9MB of the Apple Core Storage partition created by enabling FileVault2 encryption, and therefore is a single PV, LVG, LVF and LV. Since this implementation COWs the entire original file system into the LV, everything not encrypted hypothetically is core storage metadata.

dd if=/dev/sda2 of=acs_encr.img bs=1M count=9
cp --sparse=always acs_encr.img acs_encr.sparse.img
xz acs_encr.sparse.img.xz

OS X 10.8.5, MacbookPro 8,2, Samsung 830 series, FileVault2 default.

Comment 4 Chris Murphy 2013-12-13 19:32:48 UTC
Created attachment 836479 [details]
acs_encr_end.sparse.img

This is the last 351MB (if I computed this correctly) of that Apple Core Storage partition from comment 3.

if=/dev/sda2 of=acs_encr_end.img skip=469043199
cp --sparse=always acs_encr_end.img acs_encr_end.sparse.img
xz acs_encr_end.sparse.img

Disk /dev/sda2: 500118192 sectors, 238.5 GiB
Logical sector size: 512 bytes
Number  Start (sector)    End (sector)  Size       Code  Name
   2          411648       470173695   224.0 GiB   AF05  Fugue

Looks like the sparse copy step was unnecessary, the final xz is the same with or without that step. Most of this 351MB are zeros, but it looks like there is some ciphertext and then plaintext metadata.

Comment 5 Chris Murphy 2014-10-24 20:52:15 UTC
For what it's worth, recently released Apple OS X 10.10 now defaults to using Core Storage for new and existing (it converts existing volumes to use Core Storage). Assuming history will repeat itself, it means by the end of this year a majority of Mac users will have only Core Storage boot volumes.


Note You need to log in before you can comment on or make changes to this bug.