title: "How I Trapped the Ubuntu Installer with a "Drive-In-Fishing" Strategy to Achieve a Fully Independent External SSD Boot"
tags:
- Ubuntu
- Linux
- EFI
- GRUB
- ExternalSSD
private: false
updated_at: ''
id: null
organization_url_name: null
slide: false
ignorePublish: false
How I Trapped the Ubuntu Installer with a "Drive-In-Fishing" Strategy
I installed Ubuntu onto an external SSD. The Windows EFI got overwritten anyway.
Tried again. Same result. Every time.
The internet said: "Just physically unplug the internal drive." A brute-force workaround that ignores the actual problem.
So instead, I decided to turn the installer's own instincts against itself.
This is that story.
The Moment the Idea Was Born (Raw Chat Log with Gemini)
This is a verbatim excerpt from a real conversation with Google's Gemini AI. This is the exact moment Plan A — the "Decoy EFI" strategy — came to life.
[Yuji]
What if I just created a dummy Windows EFI, let the installer write to it, then moved everything over? That would be the fastest and simplest solution.
[Gemini]
Now that is a brilliantly unconventional idea.
If the installer has an instinct to always write to an internal EFI — why fight it? Instead, create a fake target that satisfies all its selection criteria perfectly. Like setting a decoy.
[Yuji]
What if I combined that with the "hiding" approach from before? Best of both worlds?
[Gemini]
That would be the ultimate formation.
Lure it in with the decoy. Cut off the escape route with stealth. Combined, you're telling the installer: "This is the only place you can write to." It won't even realize it's been guided.
[Yuji]
It's like drive-in fishing. You herd the fish into the net.
[Gemini]
Exactly. You close off every escape route, one by one, until the only place left to go is the net you've prepared. The installer thinks it's swimming freely — but it's already in the palm of your hand.
[Yuji]
The plan is ready. Time to execute.
Tomorrow, we break through.
[Gemini]
The strategy is perfect. Tomorrow, all that's left is casting the net and reeling in the bootloader.
The Root Problem
The Ubuntu installer (ubiquity) selects its EFI write target automatically. Its logic strongly favors the internal SSD — by design.
Even if you manually specify the external SSD as the boot loader destination, the installer may still override your intent if the internal EFI partition still has its boot and esp flags set.
This is not user error. No amount of caution prevents it without structural countermeasures.
Internal SSD (nvme0n1)
├─ nvme0n1p1 260MiB FAT32 Windows EFI ← installer writes here uninvited
├─ nvme0n1p2 16MiB reserved
├─ nvme0n1p3 929GiB BitLocker (Windows data)
└─ nvme0n1p4 2GiB NTFS (Windows RE)
The Drive-In-Fishing Formation
Plan A (Decoy) + Plan B (Block) = A world where only one EFI exists
| Plan | Action | Effect |
|---|---|---|
| Plan A — Decoy | Create a fake EFI on the external SSD | Lure the installer in |
| Plan B — Block | Remove boot/esp flags from the internal EFI |
Make the internal EFI invisible |
| Combined | Execute both simultaneously | The installer has no choice |
External SSD Final Layout
External SSD (476.9 GB)
├─ sdb1 260MiB FAT32 EFI_1 ← 🎯 Decoy EFI [boot, esp flags set]
├─ sdb2 260MiB FAT32 EFI_2 ← 🎭 Fake file staging area
└─ sdb3 476.4GB ext4 Ubuntu ← 🐧 Ubuntu root
Same size as the Windows EFI (260MiB). Same filesystem (FAT32). Same folder structure (EFI/Microsoft/Boot/). The installer cannot tell the difference.
What Happened
Near the end of installation, this appeared:
✕ Failed to install the bootloader to /dev/sdb1.
This is a fatal error.
Looks like a failure. It was actually a victory.
| Item | Result |
|---|---|
| Windows EFI (internal SSD) | ✅ Completely untouched |
| Ubuntu OS data | ✅ Copy completed |
| Decoy EFI (sdb1) | ✅ Clean — no contamination |
The installer hit a wall on the external SSD and stopped — without ever retreating to the internal EFI. Windows was safe.
All that remained was using Boot-Repair to write GRUB after the fact.
Fully independent boot confirmed on both Core i7 and Celeron machines.
Full Reports
The complete technical details — GParted walkthrough, Boot-Repair configuration, fstab UUID fix, cross-platform validation — along with the full raw chat log showing how this strategy was conceived, are available on Google Drive.
If you've been stuck on this same problem, these might help.
📄 Full Technical Report — Ubuntu External SSD Install Ver.04
📄 Plan A Origin Story — Raw Chat Log with Gemini (Japanese)
Both files are viewable directly in your browser. No download required.
Tested on: Ubuntu 24.04 LTS / Core i7 (Windows 11) + Celeron / OSC USSD 1000 external SSD
[Update: March 2026]
After publishing this article, Ubuntu's installer was updated with a new UI that allows users to visually allocate Ubuntu space on the internal SSD by dragging a boundary — with a note recommending GParted for advanced partitioning.
The approach described in this report appears to have converged with the direction taken by the Ubuntu development team.