| Summary: | RFE libblkid should be able to identify ID_FS_TYPE contained within Apple Core Storage partitiontypeGUID partitions | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Chris Murphy <bugzilla> | ||||||
| Component: | util-linux | Assignee: | Karel Zak <kzak> | ||||||
| Status: | ASSIGNED --- | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | unspecified | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | rawhide | CC: | jonathan, kzak | ||||||
| Target Milestone: | --- | Keywords: | Reopened | ||||||
| Target Release: | --- | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2013-12-10 11:55:50 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 1033778 | ||||||||
| Attachments: |
|
||||||||
|
Description
Chris Murphy
2013-12-09 21:02:57 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. 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 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.
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. 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. |