Support booting from devices exposed as non-removable
Tails refuses to boot from devices that expose themselves as non-removable. Historically, all USB sticks said they were removable, even if this is not correct according to the specification (removable is rather for devices that can be fed with removable medium, such as a floppy drive). But:
- Some USB sticks (especially Sandisk) expose themselves as non-removable.
- Some external USB hard drives expose themselves as non-removable.
- There’s recurring interest in installing Tails on internal hard disks (e.g. for performance reasons, or to dedicate a machine to Tails, or to avoid having a USB stick protruding outside of a laptop, or to install Tails on a tablet’s internal storage): see
Feature #8422for use cases and what it would take to support it.
A plan could be to:
pass the syslinux SYSAPPEND variable a bitmask that enablesDONE in commit:d421f38e22898fc0a6e58b9ae79a25366f0a2dfa
FSUUID=functionality (bit 0x40000): this feature appends, to the kernel command-line, the UUID of the partition the kernel is booted from (added in 6.03-pre9, see commit 386b59e1 in syslinux Git)
- add support to live-boot to search the SquashFS only on the filesystem specified by the FSUUID kernel command-line parameter, when present; when present, FSUUID should override any
live-media=found on the command-line, so that we would still pass
live-media=removable, that would only be taken into account when booting from DVD.
|Feature #7475: Have live-boot honor FSUUID=||Confirmed||
Related to Tails -
Related to Tails -
Related to Tails -
Related to Tails -
Blocked by Tails -
#17 Updated by sajolida 2014-07-31 11:46:41
Already two people reported that newer SanDisk might have a different firmware that fixes this issue. But that still need confirmation.
After this, and as SanDisk was the main (if not only) vendor with that behavior, maybe this ticket can be set as low priority or closed…
#22 Updated by intrigeri 2014-11-10 16:03:54
- Assignee changed from intrigeri to sajolida
- QA Check set to Info Needed
Dear frontdesk, how is it going on your side? Did you notice a substantial change in the rate of bug reports that can be workaround’d by removing
live-media=removable, since Sandisk changed their practices?
#31 Updated by WhiteWind 2015-01-13 23:42:51
Hello. Just wanted to say, I got a bought-new Sandisk Extreme 64GB USB 3.0 thumb drive (SDCZ80-064G-G46), there is no Windows 8 logo on the box, and I can’t boot from it. BUT that is currently only my first try with something different than Windows, so that could be something else I’ve not done/ I did wrong, on my end. I have followed the instructions given on Tails mainsite, SecureBoot is disabled and the thumb drive is set as the boot drive in the UEFI. When I boot on it, I have a black screen with “No configuration file found. Boot: ”. I would try the live-media= thing, but I’m not too confident, and well I don’t really understand how it is done.
#32 Updated by intrigeri 2015-01-14 09:33:11
email@example.com wrote (13 Jan 2015 23:42:52 GMT) :
> Hello. Just wanted to say, I got a bought-new Sandisk Extreme 64GB USB 3.0 thumb drive (SDCZ80-064G-G46), there is no Windows 8 logo on the box, and I can’t boot from it.
Please report a bug, including the answers to all questions on https://tails.boum.org/doc/first_steps/bug_reporting/tails_does_not_start/. Thanks!
#33 Updated by sajolida 2015-01-14 09:48:46
The live-media= parameter has to be entered on the boot screen, see:
So if you don’t get to the boot screen, then I think that you are facing
a different issue. Feel free to contact our support team for more help.
#37 Updated by sajolida 2015-03-15 15:56:45
Frontdesk people, please make sure to submit patches to add the relevant hardware on the known issues page. This is definitely on your plate as stated in https://tails.boum.org/contribute/working_together/roles/front_desk.
Also, please make sure to have people run that find command before adding hardware. It’s in the frontdesk repo. As you surely know, people do all kind of crazy stuff to get Tails to run and report them in very funny ways sometimes…
#38 Updated by intrigeri 2015-03-16 22:45:05
It’s getting hard to find the relevant information in here, so let’s make things clear.
Frontdesk people: it’s useful to report general tendencies (or even stats), as I asked on Feature #6397#note-22: this will help us decide how urgent this problem is. (Looking at the history of the known issues section about it may actually be enough to assert its impact, as long as you keep it updated.)
However, this ticket is not about compiling a list of individual devices that can’t boot with
live-media=removable, nor about updating the known issues page (there are better places for that anyway). It’s about fixing this problem for good.
Please, let’s stop adding to the (already big) pile of comments anything that doesn’t help fixing the underlying problem. Thanks!
#42 Updated by intrigeri 2017-04-11 14:53:20
https://sources.open-infrastructure.net/software/system-boot/commit/?id=c6de5da6c4b3e6744cc05601930508472de54549 makes system-boot (a live-boot fork) ignore the “removable” bit, and instead use heuristics based on the bus that’s used (i.e. something relatively similar to what we do in Tails Installer and Tails Persistence Setup, where we treat all deviced plugged via USB or SDIO as OK). Might be good enough for us. I had rejected this idea on
Feature #6641 but I think my reasons were too simplistic: as the aforementioned commit shows, there’s a sane way to do it. Now, this addresses the initial goal of this ticket, but it doesn’t address the UX issue one has when starting a computer with 2 Tails devices plugged in — however, Feature #7475#note-7 does, and can nicely combined with the solution described here.
#53 Updated by intrigeri 2019-08-30 20:15:06
- Subject changed from Support booting from USB devices exposed as non-removable to Support booting from devices exposed as non-removable
- Status changed from In Progress to Confirmed
We don’t care about such USB devices anymore (
Feature #16926) but there’s interest in supporting running Tails from an internal hard-drive, which is a similar problem ⇒ repurposing.
#55 Updated by intrigeri 2020-03-09 19:30:38
- Description updated
- Parent task set to
I want to scrap all alternate plans except the initial one, because:
- The goal of the alternate plans was to avoid having to deal with bootloaders, but we did that already: we now pass
FSUUID=on the kernel command line. So, the initial plan is now cheaper than expected initially.
- At least in some cases, heuristics based on the bus don’t solve the “2 USB sticks plugged into the computer” problem, even combined with the initramfs+SquashFS UUID approach (details: Feature #7475#note-10).
- Heuristics based on the bus still won’t solve the “booting Tails from an internal drive” scenario.
- The “backup plan” that I’m deleting from the description assumed that the main way to install Tails was “install from ISO” in Tails Installer. That’s not the case anymore. In our current setup, we cannot rely on the installer to do anything more clever than a bit-by-bit copy.
Note, however, that the initial plan (Feature #7475) has two problems, that both stem from the fact the FSUUID is a publicly known value (currently shared by all versions of Tails:
a69020d2), combined with a primary installation method based on bit-by-bit copy:
- Security regression: when a user starts a newly installed Tails from a USB stick, if an adversary has previously planted a Tails-like-rogue-OS on the internal hard drive of the same computer, there’s a chance we boot from that rogue OS.
- Once a Tails USB stick has been booted once, and our partitioning script has run, this problem goes away: our partitioning script sets a random FS UUID.
- We could derive a random FS UUID, at image build time, from
SOURCE_DATE_EPOCH. So at least, every Tails release has a different FS UUID. This would make it significantly more expensive, in most cases, to set up this attack successfully. Good enough?
- If 2 freshly installed, never booted yet, Tails USB sticks are plugged in the computer, then we could partition another USB stick than the one the user elected to boot from, and mount the SquashFS from that other USB stick as well ⇒ confusion. IMO this is too much of a corner case to worry about.