[u-u] Live booting from USB key (.iso)

[D. Hugh Redelmeier]

| From: arocker at Vex.Net

| Has anyone had any success with this?

All my experiences are with a few Linux distros.

I do this All the time with considerable success.  But only with .iso
images that are specifically constructed for this.

Before this innovation, there were several tools that built a bootable
USB stick from a .iso.  They had to know about the Linux distribution
to do the right thing. UNetbootin was probably the most widely applicable.

For some time, Fedora Linux .iso images can be just dded onto a USB
stick.  Ubuntu changed over more recently.

If you just dd an .iso, you don't get any writable persistent store in
the live system.  With UNetbootin and Fedora Live Creator, I think that you can.
But I used to have trouble with them -- I don't miss them.

| I'm getting partial successes by thrashing about, but actually
| understanding the factors involved (how the key should be partitioned,
| whether to dd or cp the .iso, what filesystem type, what mode settings are
| required, &c.) would probably speed up the process.

If you are just going to dd the image, and when you initially inserted the
USB stick you got /dev/sdg1 mounted:

- (superstition) unmount /dev/sdg1.  Note: do not "eject".
  It seems scary to leave a mount when you are going to change all the
  behind its back.

- sudo dd if=thing.iso of=/dev/sdg bs=16M oflag=direct

Note: the target is the "disk" (/dev/sdg), not a partition (/dev/sdg1).

The bs=16M specifies an arbitrary large block size, but only for speed.

The oflag=direct seems to cut down some weird behaviour of dd commands
that transfer large amounts of data.  I think that it reduces the
amount of counter-productive buffering.  A variant of the
"bufferbloat" problem

Gotchas (long!):

This stuff is full of exceptions to the exceptions as desperation and
creativity have found ways around annoying limitations and staggered
transitions.

The gotchas mostly come from legacy booting vs UEFI booting and the
implications.

Booting mechanism and partitioning method are linked.  After all, the
boot code needs to understand the boot disk.  BIOS systems boot from
the Master Boot Record ("MBR") (usually implying a MBR-style
partitioning) and UEFI systems boot from a special filesystem within a
GPT (GUID Partition Table) disk.

It is possible to make a GPT disk look enough like MBR to allow legacy
booting.  I've done this so that I can use a disk larger than 2T as a
boot disk on a system with only BIOS firmware.

UEFI is not a BIOS, it is the alternative and successor to BIOS.  But
people are sloppy in their terminology.

- most current firmware supports UEFI and BIOS (called "legacy" for
  lack fo a better word).  "CSM" (Compatibility Support Module) is the
  technical term for the part of the UEFI specification that allows
  BIOS-like behaviour.  CSM is optional.

- legacy booting works for 32-bit and 64-bit systems.  And 16 bit ones
  too, but these days that's just DOS.  This is because the firmware
  just reads and starts the Master Boot Record in 16-bit mode.  Any
  mode transitions happen after the BIOS hands off control

  Legacy systems provide some runtime services through the BIOS.  But
  that code is so limited that only initial booting code and DOS use
  them.  To use them, the processor has to be in 16-bit mode.

- UEFI booting can only boot 64-bit systems.  Except for a very few
  systems which can only boot 32-bit systems.  How is this progress?

  UEFI provides a bunch of useful services to the running system.
  To use them, the system has to be in the mode that UEFI expects
  (usually 64-bit mode).

- almost no Linux distros support 32-bit UEFI.  Debian is an exception
  (but only from a multiarch .iso).

- Only a few 32-bit UEFI systems exist:

  + the original Intel Macs (they had Intel Core Duo processors and
    had no 64-bit mode).  Their UEFI implementation was non-conformant
    anyway.  Best to forget them.

  + (probably) Intel processors like Edison (even weaker than Atom so
    not of interest for general-purpose computing).

  + Many Baytrail Atom systems.  Think netbooks and tablets.  Part of
    Intel's scheme to cripple them compared with mainstream processors.
    This was NOT a hardware limitation.  They don't have CSM!

- a 64-bit Fedora live CD can be booted as MBR or UEFI

- If you boot Fedora from a USB stick via UEFI, it can only install a
  UEFI-bootable sysytem.

- If you boot Fedora from a USB stick via legacy, it can only install
  a legacy-bootable system.

- your firmware setup screen typically lets you specify whether you
  can boot legacy or UEFI or either.  Your firmware boot selector
  can similarly see USB sticks in either way and you must be careful
  to select the right one.

- a Fedora 64-bit .iso image can be booted either UEFI or legacy.  But
  you need to chose the right one.

- a Fedora 32-bit .iso can only be booted MBR

- Ubuntu probably has the same limitations.