You can of course boot from USB if the phone is connected via USB to a host running
uuu
Thanks, might need to dig that.
What I actually want is to get access to the phone’s internal eMMC (or whatever it is) drive as a block device (while it is not mounted) — to backup its image, and maybe later restore it if I screw things up.
That’s easy then. On a host computer with uuu installed, download Jumpdrive and boot Jumpdrive on your Librem 5 via USB from the host.
Jumpdrive will expose the internal eMMC drive as a block device on the host (and, if there’s a uSD card inserted in the Librem 5, it will also expose the uSD card as a block device on the host).
Neither block device will be mounted on the Librem 5, so you can safely mount the block device on the host if that’s what you want or leave it not mounted on the host if that suits your purposes.
I’ve done this in order to image the eMMC drive to a file on my host, hence I don’t want it mounted on the host - as a form of backup (that is slow but simple and reliable) - and for exactly the same reason as you (restore if I screw things up 
).
Obviously if the main partition is encrypted then you will need to do the usual stuff if you need to access files on it - but if you just want to image the whole thing then it shouldn’t make a difference as to whether it is encrypted or not. (However bear in mind then that if you just back up the whole thing then the backup won’t cover the case that you e.g. forget your encryption passphrase.)
But can you later just restore the encrypted image and get the same configuration as before?
Done! The only thing that bugged me was the need to take the battery out to get into serial downloader boot mode (as instructed here). Why wouldn’t just holding volume-up be enough?
Definitely. If you create a dumb dump of the whole disk (e.g. dd) while nothing else is accessing it, you can be reasonably certain that you’ll get the original state of the disk upon dumb restoration of the dump — no matter what was on it.
But, doing it dumb is a bit… dumb unless you know that most of the space is occupied with data. This is certainly not the case with a new just-out-of-the-box L5. It is much more efficient to dump the partition table, then unlock the encrypted partition and create smart dumps of the filesystems with partclone. In my case, the gzipped root filesystem dump is only 1.1GB.
It is. The instructions just make sure that you succeed against as many edge cases as possible.
To add to that though …
if the partition is not encrypted and most of the space is empty then dd ... | gzip ... might take longer than a smarter backup but won’t take more space
if the partition is encrypted and most of the space is empty then … it’s complicated.
If the partition is encrypted and you choose to unlock it in order to back it up unencrypted then you need to make sure that the backup is adequately protected, taking into account your threat model (whereas if you back it up encrypted then the backup doesn’t particularly warrant any greater or lesser protection than the original, as they are identical). “adequately protected” includes the option of backing up unencrypted but encrypting the final result.
I wonder if that’ll change
I’m not sure if it’s helpful to anyone, but one thing I noticed when I was trying to convert the eMMC from ext4 to btrfs is I managed to create an initramfs that recognized my SD card’s encrypted LUKS partition and successfully unlocked it during the boot process. It got as far as unlocking the LUKS partition during the boot but otherwise failed as either a) default root when mounting the unencrypted partition wasn’t set up correctly, or b) I did set up the proper device but because I didn’t have a default subvolume set on the encrypted SD card it couldn’t find the files ergo panicked/crashed.
Considering I was able to successfully decrypt the SD card during boot, I wager that it’s possible to boot from the SD card if someone creates a proper initramfs that’s read from the eMMC first that loads up a default root located on the SD card. I also wager that, sticking with btrfs, one could have subvolumes like @pureos, @mobian, and @postmarketos. By using a symbolic link like @ --> @pureos and changing /etc/fstab of the root device to something like /dev/by-uuid/$BTRFS_PARTITION / btrfs subvol=@ you can change what boots up by just changing whatever the symbolic link points to.
(Caveat: in this particular example, all the OSes that are subvolumes would need to use the same kernel, if the initramfs offers a method to select a subvolumes.)
It did. u-boot can now access the SD card and boot from it - it does so when you boot with Vol- key pressed.
That’s what I used since 2020, before u-boot gained access to the SD reader 
Is there a particular format things need to be to do so? I’m guessing if it’s from the SD card everything including /boot needs to be on the root of the SD?
It’s exactly the same as on eMMC. You can even dd an eMMC image onto SD card and it will work (just make sure you don’t use the same image for both eMMC and SD so you don’t have duplicated partition UUIDs )
You should be able to re-randomise the UUID in order to avoid the consequences of having a duplicate UUID. After doing that, update /etc/fstab
Woooooo! That’s awesome!
At least in case of PureOS, you would also have to either change it inside initramfs or provide correct root= parameter in kernel’s cmdline. But that matters only if you use the exact same image, otherwise UUIDs are already going to be different