If you are a sysadmin and this is too slow, skip to the TL;DR below, this is actually extremely trivial once you know how disks are laid out.
You might find this link helpful in understanding.
Recently I was faced with a situation where I thought I was nearly done developing what's now called LOTMaster - the master pi in my LAN of things, which now does a *lot* more (I'm consolidating computers to save power etc). But as usual, afgter some days of testing, oops, some relatively major changes needed to be made. BUT! I'd already switched to an enormous USB drive - how to back up the whole shebang cleanly in minimal time and space? And of course, without a restore, it's not a backup.
I'm going to detail how to go from a pure SD card situaion to a pure USB situation here - once the various paritioning etc is done, there are some steps you can obviously skip to repeat this. In my new Pi3 b+s (hint, they are super nice, and so are Class 10 A1 SD cards - the new ones go 98 mB/sec and that's now the fastes horse in the stable - if you can live with the reliability issues) - the "boot from USB" bit is already burned, so I'm skipping that - check this link.
For whatever reason, just copying a bit-image from an SD to a USB and then booting - simply works, we're done. But that's the only case that works (though you can then expand the ext4 partition on the USB) without other changes. If you're kind of scratch building a new USB, things need a little more twiddling (and it's more obvious why this works than why it worked from the bit-image on the wrong device at all - it turns out that the "unique IDs for partitions got copied in the bit image).
Starting with a clean USB, call up gparted on it, and create a new partition table, making it MSDOS type. You'll be correctly warned that this wipes the drive (it's the fastest wipe there is...). Now the fun part - the Pi standard partitioning is on boundaries that gparted and some other tools can't hit precisely. But it works if you get
"close enough" AS LONG AS YOU MAKE A COUPLE EDITS TO TELL IT WHERE THINGS ARE NOW. In other words, a couple files have partition UIDs specified in them, and now those are wrong. Easy to fix, though. You simply edit those files, and put in the new stuff. I'm going to cheese out here and just use /dev/sda1 for the new boot partition and /devsda2 for the root filesystem - it you have more than one USB disk, God bless you and you already know how to know which one becomes which, I hope.
So, first I gathered some data from an existing working SD card in gedit, and here are the screenshots:
- Overview of original SD card in gedit
And a little more detail - but not quite enough as I found out and worked around.
- Overview of original SD card in gedit
- The original fat32 boot partition
- The original ext4 root partition
Note that these show the start locations and so on as sectors - but when you're making new setup, gparted wants megabytes (MiB actually) and it won't take fractions as input, even though it will report them. This turns out to be overcome by simply using the old linux not-a-trick of telling the bootloader where root is, and setting up /etc/fstab to use the new locations as well - it gets read a bit later in the boot process and it all has to agree - that that big a deal if you know this.
So...after all that preliminary faffing around, here;s, the step by step: (for a linux host - you need to be able to create an ext4 parition, dunno if win can do that yet)
Put your USB stick (or big drive and SATA<>USB able) in the host. This is the one you're going to wipe and make a new pi image on.
Make a a new partition table of MSDOS type.
Make a FAT32 partition starting at 4 mB and make it 42 mb long - that's close enough. You can label it boot or bootfs if you're hard to confuse (we'll have another drive on here later with one of those names already - my linux adds a '1' to the end of the display name for whichever was plugged in second).
Now make an ext4 partition starting 2mB after the end of the first one - you can label this one root or rootfs (I don't think these names matter to it working).
Now you can put in your SD master card (priceless).
At this point you can use a couple simple copy commands to move all the bits - and it's WAY faster as it only move the used ones, not the blank spaces.
On my machine this looked like:
Doug@BroadNUC /media/doug $sudo cp -rp ./boot/* ./BOOT/
Doug@BroadNUC /media/doug $sudo cp -rp ./rootfs/* ./rootfs1/
NOTE: I'd had the SD card in already, so it's my new USB that had the names BOOT and rootfs1!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
The point here is to understand how this works so you can do it however best suits you. Please note!
Now that you've copied these files (and in a fraction of the time it takes to do a bit copy), you need to modify /boot/cmdline.txt, and /etc/fstab on the USB - both will require sudo (or root) privelege to edit.
cmdline.txt will look something like this:
dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=PARTUUID=071cf894-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles
You just need to change the root= to root=/devsda1 in this file. Presumably it would also work to just change the PARTUUID to the correct new one if you know that.
Save, and now we do /etc/fstab, which looked like this:
proc /proc proc defaults 0 0
PARTUUID=071cf894-01 /boot vfat defaults 0 2
PARTUUID=071cf894-02 / ext4 defaults,noatime 0 1
# a swapfile is not a swap partition, no line here
# use dphys-swapfile swap[on|off] for that
tmpfs /var/www/plots tmpfs rw,nodev,nosuid,size=1M 0 0
(you don't need that last line, I'd added it for the LOT plots to put them on a ramdisk).
Note the PARTUUID lines - those get changed to /dev/sda1 and /dev/sda2 instead of PARTUUID=SOMEWIERDHEX - leave the rest of the lines as is.
Note you'll have to R&R your new USB storage to get it to show mounted after using gparted to do low level stuff on it.
TL;DR TL;DR TL;DR TL;DR TL;DR TL;DR TL;DR TL;DR TL;DR TL;DR
Sysadmin synopsis:
All you have to do in partitioning is get close - right type of partition table and right types of the filesystems. Then you have to tell both the boot process and the finally running linux where stuff is THIS time. And you're done. Other methods require a lot more calculation and detail of naming partition UUIDs and so on - it's actually as easy as this synopsis.
For what it's worth - the new "A type" SD cards are the fastest thing available.
Next is an SSD drive on a USB3<>SATA cable - this is the setup of choice here if I need space and speed.
Next is a plain old laptop 2.5" spinner on the same cable, and is what I used for a few years. 2tb to back up the rest of my world was hard to resist.
Last is a USB3 flash stick - which is slower than a plain class 10 SD card, go figure, and was dropping some frames for us when recording fusor scope screens.
Evidently the wimpy CPU in the USB stick goes out wear leveling veeeerrrry slooowwwwly.
