TQ
dev.com
Blog about software development
29 Aug 2025 - by 'Maurits van der Schee'
Linux Mint can be installed on an external SSD. Simply boot from this SSD on any other machine and it just works! You can easily buy a fast, large and durable external SSD nowadays. Unfortunately installing Linux Mint on a an external SSD is not so straightforward due to a bug in the installer. In this post I'll explain you how to work around this bug in the installer of Linux Mint, my favorite desktop distribution.
I used a (relatively) cheap "Kingston XS1000 1TB" (80 eur), but you may use any M2 NVMe enclosure that supports USB 3.0 or higher and UASP. It should ideally be an external drive rated for 1000 MB/sec or more in read performance to ensure you are dealing with an external SSD that is as fast as your internal disk (and also durable enough).
Method A: The safest way to install Linux Mint to an external SSD is to remove the internal disk from the machine, connect the external SSD over USB and do the installation as you normally would (no manual partitioning or bug workaround needed).
Method B: You can also create a virtual machine (with EFI boot). You need the install ISO as the first disk (CDROM) in the VM and connect the external USB disk (using USB forwarding) as the second disk in the VM. This is the fastest, easiest (and recommended) way to install Linux onto an external SSD.
So really, there is no need to run into trouble. Use one of these two methods and you can skip reading this article. If you insist on running the installation on your Linux or Windows laptop, or you already did and want to understand what went wrong, please read on.
IMPORTANT! Playing with disks and their partitions is risky. You may end up with a system that does not boot anymore from the internal disk or even with an internal disk that is completely wiped. Always make a backup of all disks in the system before you start.
People will try to install with the internal disk connected and that disk will contain a FAT32 partition with "boot" flag on it. The installer seems to allow you to select which EFI partition to use (in a "bootloader" dropdown). Unfortunately this selection is ignored as this selection is only relevant for systems using legacy boot (nobody does this anymore). Instead the installer overwrites the first FAT32 partition it finds that has a "boot" flag set (the one on your internal disk).
This will lead to a system that can neither boot from the internal disk nor from the external disk on another system. Because of this strange behavior (a bug in my opinion) you have to remove the "boot" flag of the internal disk before you start installing on the external SSD. When you are done installing you can put the "boot" flag back on the partition of the internal disk.
To restore the overwritten EFI partition on the internal disk you can use the tool "boot-repair" from the terminal before starting the Linux Mint installation. I've had to do this many times when writing this aricle.
The Linux Mint 22 installer is affected and so is Debian 13 netinst (both are Ubiquity based). The problem might be resolved in the Calamares installer, that is included on the Debian 13 Live ISOs (and many other distributions, including Arch btw). If you don't care specifically for Linux Mint XFCE, then you may give Debian 13 Cinnamon a try.
Boot from the thumb drive that has the Linux installer into a Linux Live environment.
First we will prepare the external SSD.
Now the external SSD is clean and ready to be used as an external disk.
Next we are going to remove the "boot" flag from the internal disk(s)
Note that changes to the flags are immediately effective.
Now the Linux Mint installer can be started.
As a last step add the "boot" flag again:
Now the system can both be booted from the internal disk and the external SSD.
Your desktop Linux experience is in my opinion best measured by throughput and response time. For throughput we can do a single threaded 4k random read performance test and for response time we can do an I/O ping benchmark. By running these two benchmarks on any drive you can determine which disk works best for you.
Subscribesudo apt install fio
To test the single threaded 4k random read performance, run:
fio --name TEST --filename=temp.file --rw=randrw --size=20m --io_size=100m --blocksize=4k --ioengine=libaio --fsync=1 --iodepth=1 --direct=1 --numjobs=1 --runtime=60 --group_reporting
Look for this line with results:
READ: bw=5594KiB/s (5728kB/s), ...
To test the I/O ping, run:
ioping -c 20 .
Look for this line with results:
min/avg/max/mdev = 178.9 us / 198.9 us / 231.1 us / 23.0 us
The above are results from my USB 3.1 connected "Kingston XS1000 1TB" disk under LUKS (single threaded benchmark). I was hitting about 5600 KiB/s for the single threaded 4K random reads with an I/O ping of about 200 us. This was better than the my internal NMVe disk (that is also LUKS encrypted) on which I was getting 4000 KiB/s throughput and a response time of about 290 us.
If your performance results are disappointing, then this may be due to the lack of UASP (USB Attached SCSI Protocol) support. You can test for UASP support by issuing the following command:
$ lsusb -v -t | grep Storage -A 1
Look for the "Driver=" string on the device you connected:
|__ Port 003: Dev 009, If 0, Class=Mass Storage, Driver=usb-storage, 480M
ID 058f:6387 Alcor Micro Corp. Flash Drive
If you see "usb-storage" then UASP is not enabled and your drive will be 2x slower and not support TRIM and such.
|__ Port 001: Dev 006, If 0, Class=Mass Storage, Driver=uas, 5000M
ID 0951:1780 Kingston Technology
If you see "uas" then UASP is enabled and everything is working optimal!
PS: Liked this article? Please share it on Facebook, Twitter or LinkedIn.