🎯 Goal

Build a stable, non-destructive dual-boot setup on an Intel MacBook Pro (2013):

  • macOS Big Sur as the recovery anchor
  • Ubuntu Server (LTS) as the lab target
  • clean GPT partitioning
  • no APFS corruption
  • no EFI takeover
  • repeatable recovery path

This wasn’t “install Linux.” This was “install Linux correctly on Apple hardware.”

âś… What I Did

1) Defined the architecture strategy (control > convenience)

Decisions:

  • macOS remains “disk owner”
  • APFS resized once
  • Linux installed into true unallocated GPT free space
  • reuse existing Apple EFI
  • no LVM, no encryption
  • avoid guided installer defaults and bootloader surprises
  • use Apple Boot Picker for OS selection

Target layout: disk0
├── EFI (200MB)
├── APFS Container (~300GB) → macOS
└── ext4 (~200GB) → Ubuntu

2) Resized APFS the professional way (Terminal, not GUI)

Disk Utility GUI created extra APFS container behavior that wasn’t aligned with the goal.

Fix:

  • used diskutil apfs resizeContainer to shrink APFS cleanly
  • left real unallocated space

Verified with:

  • diskutil list

Outcome:

  • EFI intact
  • APFS container resized
  • free space visible as free GPT space

3) Created the Linux partition manually (installer didn’t refresh free space)

The Ubuntu Server installer (Subiquity) didn’t reliably detect trailing free space until layout was refreshed.

Process:

  • drop to installer shell
  • use parted /dev/sda
  • create partition 3 in the free space
  • reset installer layout view

Mount decisions:

  • /boot/efi → existing EFI partition
  • / → ext4 partition 3

No APFS touched. No EFI recreated.

4) Installed Ubuntu Server with minimal risk settings

Selected:

  • Ubuntu Server (not minimized)
  • OpenSSH server enabled (lab access)
  • custom storage layout
  • no LVM
  • no encryption

Post-install:

  • Apple Boot Picker shows macOS + Ubuntu
  • boot integrity confirmed

đź”— Key Cybersecurity Connections

  • This is now a real bare-metal lab target:
    • real kernel + drivers
    • real EFI + boot chain
    • real network stack
    • SSH exposure = realistic remote entry point
  • Dual boot done safely is a discipline:
    • controlled partitioning prevents “self-inflicted incidents”
    • recovery anchor (macOS) keeps the lab resilient

⚠️ Challenges

  • Disk Utility GUI behavior around APFS containers can mislead
  • Subiquity not refreshing free space reliably
  • Unit confusion risk in partition tooling (MB/GB/%)

🧠 What I Learned

  • APFS container ≠ APFS volume (important distinction)
  • EFI should not be recreated casually on Macs
  • guided installers are risky when you need strict control
  • always verify partition math before committing changes

⏭️ Next Steps

  • verify network stack + connectivity
  • confirm SSH exposure and authentication posture
  • baseline firewall status
  • capture a “clean system snapshot” for repeatable labs
  • begin attack surface mapping from Kali

đź’­ Reflection

This was foundational infrastructure work. Dual-boot on Apple hardware is not trivial if you want zero damage and repeatability — but now the lab target is real and stable.

âś… Lessons Learned

What worked

  • Terminal-based APFS resizing
  • manual GPT partitioning
  • Apple Boot Picker for clean OS selection

What broke

  • GUI partition assumptions
  • installer free-space detection/refresh behavior

Why it broke

  • macOS tries to be “helpful” with APFS containers
  • installer UI doesn’t always reflect disk state immediately

Fix / takeaway

  • verify with diskutil list and parted print
  • never trust guided installers on Apple hardware

  • measure twice, write once