Linux Mint Live USB with Persistent Partition: how?

[rui no onna]

Just a couple of "idle, silly" questions. Is there a BIOS that will permit booting from a USB connected HDD? (i've not tried, so don't know) I'd have thought that that would be a no-brainer given that USB flash memory can be bootable.

Note, not all motherboards support booting from USB flash either. Probably more pronounced for computers released prior to 2010.

I expect most newer devices wouldn't have an issue booting from USB though (regardless of HDD or flash drive). Granted, I'm just guessing. Last time I tried a USB "hard drive" was back in 2012 working on even older hardware. My MB didn't like it.

[spaceman5]

I expect most newer devices wouldn't have an issue booting from USB though (regardless of HDD or flash drive).

Does a BIOS boot from USB 3 device as well as it does from USB 2 devices??
And when it boots from a USB 3 device, does it work in USB 3 mode or USB 2 mode?


I ask this because when you connect a USB 3 device to a computer running an OS,
If that OS has drivers for your USB 3 controller, then you will get USB 3 speeds.

But when you boot from a USB 3 Device, the motherboard has to take responsibility of everything..
There's no OS running already that will provide USB 3 drivers..

Anyone has experience with this?

[rui no onna]

I ask this because when you connect a USB 3 device to a computer running an OS,
If that OS has drivers for your USB 3 controller, then you will get USB 3 speeds.

But when you boot from a USB 3 Device, the motherboard has to take responsibility of everything..
There's no OS running already that will provide USB 3 drivers..

Unlike Windows XP or Windows 7, the current Linux kernel has built-in support for USB 3.0. Mind, both Windows 8 and 10 have built-in support for USB 3.0, too.

[BG405]

Unlike Windows XP or Windows 7, the current Linux kernel has built-in support for USB 3.0

This .. and yes, if it'll boot off a flash drive, it'll normally boot off a suitably prepared USB HDD too.

YES you can load to, and boot from an external HDD with one caveat! It stuffs up Grub on the primary drive so now I have to work out how to repair it!!! 'nutha thread coming up!

What I'd do is set the BIOS to boot from USB first, then, if possible, remove the internal hard disk before starting the installation.

If this is impractical, you may need to run ubiquity -b from a Terminal, which runs the installer without installing the bootloader (GRUB). Then, do sudo grub-install /dev/sdX where X is the USB drive.

NOTE: I'm assuming this is a BIOS (Legacy) install? If it's (U)EFI then the bootloader needs to go in the EFI System Partition (ESP).

[lsemmens]

This .. and yes, if it'll boot off a flash drive, it'll normally boot off a suitably prepared USB HDD too.

YES you can load to, and boot from an external HDD with one caveat! It stuffs up Grub on the primary drive so now I have to work out how to repair it!!! 'nutha thread coming up!

What I'd do is set the BIOS to boot from USB first, then, if possible, remove the internal hard disk before starting the installation.

If this is impractical, you may need to run ubiquity -b from a Terminal, which runs the installer without installing the bootloader (GRUB). Then, do sudo grub-install /dev/sdX where X is the USB drive.

NOTE: I'm assuming this is a BIOS (Legacy) install? If it's (U)EFI then the bootloader needs to go in the EFI System Partition (ESP).

It did not work when I plugged into another computer, so I'll need to play some more. Sorry, I cannot offer more assistance at this stage. I spent the rest of yesterday getting two computers working again instead of just the one that prompted my attempt. In the end, it was quicker just to perform a re-load. (BACKUPS are wonderful!!!!)

[rui no onna]

YES you can load to, and boot from an external HDD with one caveat! It stuffs up Grub on the primary drive so now I have to work out how to repair it!!! 'nutha thread coming up!

Curious, assuming the following:

/dev/sda - internal HDD
/dev/sdb - Live USB
/dev/sdc - external USB HDD

Did it mess up grub on /dev/sda with /dev/sdc selected for bootloader install? Also, was this under Legacy BIOS or UEFI mode?

Mind, assuming dissimilar hardware, how portable is a full install compared to the Live USB?

[spaceman5]

Did it mess up grub on /dev/sda with /dev/sdc selected for bootloader install? Also, was this under Legacy BIOS or UEFI mode?

Maybe he didn't select the USB HDD on the bottom ComboBox, like Mute Ant noted?

Along the Something Else route you need to specify that the boot-loader GRUB should go to the same store that's going to hold the OS.

[lsemmens]

Maybe he didn't select the USB HDD on the bottom ComboBox, like Mute Ant noted?

That, indeed, may well have been a possibility. I can't recall even seeing that option, but that does not mean it was not presented to me. If I left the drive plugged in, it would boot to grub where I could, then select which OS to boot. It was only when I unplugged the drive and tried to re-boot that I went to the Grub rescue prompt. I also, then, plugged that external drive into another computer and it would not boot. (I'll qualify that in that it was an older machine, that would boot from a memory stick, but may not from a USB HDD.)

[spaceman5]

This Grub is so problematic?

It's impossible to Install Mint without it?
(for example if one is installing only Mint, without doing MultiBoot or anything special)

[rui no onna]

Maybe he didn't select the USB HDD on the bottom ComboBox, like Mute Ant noted?

That, indeed, may well have been a possibility. I can't recall even seeing that option, but that does not mean it was not presented to me. If I left the drive plugged in, it would boot to grub where I could, then select which OS to boot. It was only when I unplugged the drive and tried to re-boot that I went to the Grub rescue prompt. I also, then, plugged that external drive into another computer and it would not boot. (I'll qualify that in that it was an older machine, that would boot from a memory stick, but may not from a USB HDD.)

If you don't recall changing that option and assuming you didn't run the installer as BG405 showed ubiquity -b (no boot loader install), then it would default to /dev/sda which replaces the boot loader for your local install. The computer will look for the USB HDD in order to boot every single time and fail to boot without it. One way to fix that is to boot into the local install and run sudo grub-install which should restore local grub to how it was before the USB HDD install.

That also means the USB HDD does not have a boot loader installed ergo, it can't boot if plugged into a different computer.

[spaceman5]

I think the developer of that screen should change it.

In 99.9% of the cases, a user would need the boot loader and the boot partition to be on the same physical drive.

For the rare case where someone would think about a reason not to do so, this should only be enables via some special checkbox that enables splitting the boot loader and the boot partition to 2 physical drives.

[rui no onna]

I think the developer of that screen should change it.

In 99.9% of the cases, a user would need the boot loader and the boot partition to be on the same physical drive.

For the rare case where someone would think about a reason not to do so, this should only be enables via some special checkbox that enables splitting the boot loader and the boot partition to 2 physical drives.

I think it's fine the way it is. For the 99.9% of cases, I expect using default Mint install options would install both boot loader and boot partition on the same physical drive (internal).

Being able to select the drive for boot loader install is part of the "Something else" setup which is geared towards more advanced users (or at least ones who are hopefully following an in-depth tutorial). It's far more likely that someone who chooses "Something else" is doing so for multiboot ergo, having one boot loader for all drives is likely the preferred default.

[rui no onna]

Just installed Linux Mint 19 Cinnamon 64-bit on my old, slow Kingston SSDNow V 40GB (rebadged Intel X25-V 40GB, ~40 MB/s max sequential read/write) connected via USB-SATA adapter. Laptop is set to Legacy BIOS/MBR mode.

"Something else"

Code: Select all

Device      Type    Mount point     Size
------------------------------------------
/dev/sdc1   btrfs   /               20 GiB
free space                           5 GiB  (OP while allowing for potential growth of sdc1)
/dev/sdc2   fat32   /media/shared    5 GiB
free space                           7 GiB  (OP while allowing for potential growth of sdc2)


Device for boot loader installation:
/dev/sdc    Kingston SSDNow V 40GB

Seems to work OK. It didn't change grub on the laptop's internal drive and it installed the boot loader properly to the Kingston. Despite low sequential speed, boot up was pretty fast. I don't believe TRIM is supported via USB hence the manual over-provisioning (OP).

The fat32 partition /media/shared is if for when I need an easy way to copy files without needing to mess with permissions.

[lsemmens]

I think it's fine the way it is. For the 99.9% of cases, I expect using default Mint install options would install both boot loader and boot partition on the same physical drive (internal).

Being able to select the drive for boot loader install is part of the "Something else" setup which is geared towards more advanced users (or at least ones who are hopefully following an in-depth tutorial). It's far more likely that someone who chooses "Something else" is doing so for multiboot ergo, having one boot loader for all drives is likely the preferred default.

Agreed! I was trying "something else" and failed, but that is to my benefit, as I learnt from it.
@ rui no onna I actually did try sudo grub -install and, for some reason it would not install. Anyway, I performed a re-load of Linux which was quick and painless. It took way less time than trying to solve the issue. I did not learn as much as I might have out of the exercise, but my time is at a premium and I must steal what moments I have.

[rui no onna]

Agreed! I was trying "something else" and failed, but that is to my benefit, as I learnt from it.
@ rui no onna I actually did try sudo grub -install and, for some reason it would not install. Anyway, I performed a re-load of Linux which was quick and painless. It took way less time than trying to solve the issue. I did not learn as much as I might have out of the exercise, but my time is at a premium and I must steal what moments I have.

By any chance are you on UEFI? After several failed attempts trying to get UEFI working, I'm sticking to Legacy BIOS/MBR for now, lol. UEFI's a task for another day (or weekend... or month...) when I have more time and energy to devote to research and troubleshooting.

I did have to learn some grub legacy basics by necessity. Multiboot setup on a tiny SSD kinda depended on it. The more I use other distros though, the more I appreciate how Mint works (mostly) well out of the box.

By the way, was the grub-install performed from your local drive or using a Live CD/USB? If it's Live, I usually have to do:

Code: Select all

sudo mount /dev/sdXY /mnt
sudo grub-install --root-directory=/mnt /dev/sdX

[lsemmens]

Linux would not instal under UEFI on my lappy, so I turned it off. I tried Grub install from a live USB. I also connected to the 'net in case it wanted to download. I even tried it after booting into the correct OS using grub from the external drive, and nothing would work. At that time I just gave up and re-installed Linux, which was waaaaay quicker than stuffing around.

[rui no onna]

Linux would not instal under UEFI on my lappy, so I turned it off. I tried Grub install from a live USB. I also connected to the 'net in case it wanted to download. I even tried it after booting into the correct OS using grub from the external drive, and nothing would work. At that time I just gave up and re-installed Linux, which was waaaaay quicker than stuffing around.

Like I mentioned, for me it was a necessity. I was probably already on my 10th or more Mint re-install and still couldn't get things working. I had no choice but to learn to figure out where it's going wrong.

[Moem]

Mod note:
The question from majpooper about an iMac is now here: viewtopic.php?f=46&t=276472
Please do not hijack other people's topics, it's rude. Post a new topic instead. Thanks!

[tanguero]

Seems like the original question: How to create a Linux Mint Live USB with Persistent Partition [in the easiest way possible--my addition] seems to have got bogged down in details. Since I just did it (before reading this thread, fortunately, otherwise I might have been scared off ). Really, it's a 2-step process, and you don't need to get involved in gparted, grub, and so on unless you really want to or are doing something more complicated.

Main caveat: This was for a Legacy BIOS/MBR computer so UEFI/GPT may well have other complications, although I have addressed them to some extent (without having tried it).

Step 1. Choose the Live USB creator software you wish to use (instructions below are for Rufus and YUMI, both well-regarded and both mainstream) and other parameters of the installation. The USB creation software does a lot of the hard work for you so you don't have to worry about bootloaders, partitions and special configurations unless you really have more advanced needs in which case you don't need this tutorial anyway.
Step 2. Download the Linux Mint ISO
Step 3. Create the USB

(OK, that's 3 steps but Step 2 hardly counts as a real step and Step 3 is just pushing the Start button)

There was only one small hitch I encountered which I will describe below so you won't even have to deal with that. In fact, let's get it out of the way now, since it has a major effect on other choices. Persistence can be implemented in one of two ways: FILE based, where all changes that need to be preserved from one session to the next are stored in a virtual file-system in a file, or PARTITION based, where a separate Unix partition, whose contents are generally not visible to Windows, is created to store the file changes that need to be preserved from one session to the next. This is "chosen" by the live USB creation software. Rufus chooses PARTITION based and YUMI chooses FILE-based (presumably because it supports multiple images). In theory, the only practical difference is that FILE-based will be limited to 4 GB of persistence if you have the drive formatted as FAT32 (but not if formatted as NTSC), while partition-based will not have this limitation, regardless of FAT32 vs. NTSC. Other differences between the two forms are beyond the scope of this article (fortunately, since I don't know what they are!)

HOWEVER, there is a long-standing Ubuntu bug (2015-2019), that affects Linux Mint as well from 17.3 through the current 19.3 at least, that prevents partition-based persistence from working (from my own experience, this manifests itself only on FAT32 installations, but does NOT affect NTSC installations). Those interested can check out the bug description at https://bugs.launchpad.net/ubuntu/+sour ... ug/1489855

All of this background is necessary to understand that if you want to use Rufus (and hence use partition-based persistence), you MUST format your USB drive as NTSC and not FAT32. If you use YUMI, you will get file-based persistence and can choose FAT32 (with a 4 GB persistence limitation) or NTSC (without that limitation). Also, UEFI boot only works on FAT32 USBs (a rather incredible limitation on a "new" technology) while Legacy BIOS boot generally works on both, so you have to take that limitation into account as well (although Rufus claims to have overcome that limitation and can create UEFI/NTFS bootable USB drives even if the system natively doesn't support it).

So you see, the complicated part is only in understanding the limitations of what combination of (a) persistence type (file vs. partition) (b) USB creation software (YUMI vs. Rufus, although there are dozens more) (c) USB file system type (NTFS vs. FAT32) (d) Boot method (Legacy BIOS vs. UEFI) (e) Persistence size (<4GB vs. >4GB) and (f) Linux Mint version (<17.3 or post-future-bug-fix vs. 17.3-through-19.???) play nicely with each other. Those are 2^6, or 64 possible combinations, not taking other USB creation software into account, and I believe this article has enough information to indicate which ones will work, or at least are claimed to work. (At some point, the bug fix, which has just recently made it into Ubuntu 19.10 and will be in Ubuntu 20.04 LTS, will make it into LM 20 and some of the restricted combinations will work again.)

The rest is now easy.

Step 1: Download Rufus or YUMI and run it (for YUMI, make sure to choose Linux Mint from the list of possible installations, so it sets the right options for you). Once you choose the previously downloaded ISO , you will also see a persistence size slider option.

Step 2: Download the ISO from the link provided by YUMI (or navigate to where you previously downloaded it). Choose the other options (Rufus gives you UEFI vs Legacy BIOS choices while YUMI works only on BIOS, though there is a different (Beta?) version for UEFI).

Step 3: Click Start and wait until it's done.

I settled on Rufus with NTSC and 64-bit LM 19.3 finally, since I didn't need multiboot and didn't want to complicate my life with multiboot + persistence simultaneously. But I did test YUMI as well and it worked fine as persistent, although it bypasses LM's initial menu that lets you choose Compatibility Mode and so on, and takes you right into the main LM desktop.

[pbear]

There's an easier way to do this in Windows (albeit also limited to BIOS), using PenDrive's UUI.
There's an easier way to do this in Linux using mkUSB (not limited to UEFI).

Better than both is full install to USB drive.