# Apple File System ## Identification [[InstallESD.dmg|InstallESD.dmg]] is associated with macOS installer media. `DMG` is Apple’s disk-image container; “ESD” commonly denotes electronic software distribution. ## Notebook evidence - [[Scanned_20260730-1719#PDF page 18 — macOS installer image fragment|PDF page 18: macOS installer image fragment]] — This is a reminder about locating or interpreting the bootable payload inside macOS installation media. - [[Scanned_20260730-1719#PDF page 35 — Filesystem types and console projects|PDF page 35: Filesystem types and console projects]] — The author appears to be inventorying mounted storage volumes or project folders, then recording cloud consoles used to configure an application. This is another local/remote duality: filesystem state on the device versus hosted project state. - [[Scanned_20260730-1719#PDF page 49 — Mojave APFS and Hackintosh source repositories|PDF page 49: Mojave APFS and Hackintosh source repositories]] — This is a source-provenance list for making Mojave/APFS boot on non-Apple firmware: ACPI editing, UEFI image inspection, boot-layer projects, and application compatibility. - [[Scanned_20260730-1719#PDF page 50 — AMI Aptio firmware modules and UEFITool|PDF page 50: AMI Aptio firmware modules and UEFITool]] — The author wants firmware that can understand more filesystems and emulate missing services before an OS loads. This is the architectural center of the Ozmosis section: move compatibility functions into UEFI modules so multiple boot paths can use them. - [[Scanned_20260730-1719#PDF page 51 — Ordered UEFI modules in a Z77/Ozmosis firmware image|PDF page 51: Ordered UEFI modules in a Z77/Ozmosis firmware image]] — This is a reverse-engineering observation: the author inspected a working image and recorded the module sequence as a template for another build. - [[Scanned_20260730-1719#PDF page 52 — RetroArch BIOS, PlayStation firmware, and Ozmosis modules|PDF page 52: RetroArch BIOS, PlayStation firmware, and Ozmosis modules]] — The page juxtaposes two boot-ROM layers: console firmware required by an emulator and PC firmware required to launch the host environment. The parenthetical “cmos-to-post” shows the author thinking about the chain from persistent settings through hardware initialization to an application’s virtualized console. - [[Scanned_20260730-1719#PDF page 53 — Ozmosis build components, PXE, and Kext-to-FFS conversion|PDF page 53: Ozmosis build components, PXE, and Kext-to-FFS conversion]] — The intended firmware is not merely “Mac compatible.” It is a universal pre-OS service layer capable of local filesystem access, Mac identity support, shell access, and network boot. ## Relationships and overlays The source places this note in a shared evidence cluster with [[Acidanthera|Acidanthera]] · [[Btrfs|Btrfs]] · [[Enhanced FAT UEFI driver|Enhanced FAT UEFI driver]] · [[exFAT|exFAT]] · [[ext4|ext4]] · [[FakeSMC|FakeSMC]] · [[Filesystem in Userspace|Filesystem in Userspace]] · [[InstallESD.dmg|InstallESD.dmg]] · [[MaciASL|MaciASL]] · [[macOS Mojave|macOS Mojave]] · [[MS-DOS FAT|MS-DOS FAT]] · [[NTFS|NTFS]] · [[Preboot Execution Environment|Preboot Execution Environment]] · [[Scanned_20260730-1706|Scanned_20260730-1706]] · [[UEFI Shell|UEFI Shell]] · [[UEFITool|UEFITool]]. Within the larger collection, this evidence extends [[Vendor-Agnostic Recovery|vendor-agnostic recovery]] and [[Continuity Architecture|continuity architecture]] by showing how software, hardware, identity, and pre-OS control depend on recoverable interfaces. ## Evidentiary status and open leads The final command fragment is too incomplete to execute or normalize. ## Source - [[Scanned_20260730-1719|Scanned_20260730-1719]]