How to boot Ubuntu persistent live USB on Android? I'm discovering the possibilities offered by persistent live USB using Ubuntu 19.10 and I was wondering if it would be possible to boot with Ubuntu on Android (i.e. using your computer capabilities through your smartphone) using those multi-plug USB sticks which have both USB3 and micro-USB2.

In other way: can I get some kind of a boot menu on an Android device in order to boot with a persistent live USB in order to access my Linux computer tools and setup from a wider range of devices?
Near duplicate: Is it possible to boot an Android phone from a USB drive?

You question has two parts:

1. How to boot from USB on Android device?

On most of the recent Android devices you can't boot even Android from USB, rather Ubuntu or some other OS.

PCs:

PC world has a standardization. BIOS / UEFI, ACPI and discoverable buses make every PC almost identical to the OS, so we can boot any OS. BIOS lets you select boot device, loads bootsecotor / MBR and bootloader which loads OS kernel. UEFI Boot Manager is even more sophisticated, it can read filesystems and load one of multiple BLs or even Linux kernel directly from EFI System Partitions (ESP).



Multiboot compliant BLs can load multiple OSes. Windows BOOTMGR and Linux GRUB can also chain load each other. Latter can act as 1st stage BL (MBR/VBR) as well as 2nd stage (GUI boot manager which reads configuration from filesystem). See Boot Process: Android vs. Linux

Phones:

Phone's world has a lot of fragmentation. They are based on SoC design, so every vendor implements its own closed-source firmware. Non-enumeration-capable buses depend on Device Tree, which is stored on flash storage as blob (DTB), and loaded by final BL (like U-Boot, LittleKernel / Aboot) and Linux kernel. So SoC firmware has to bootstrap the device to BL stage so that it's able to identify hardware.


Image source: Exploiting Qualcomm EDL Programmers

SoC firmware cannot boot from a generic MBR/VBR or filesystem, instead it has hard-coded paths to partitions containing BLs. Also the strict Chain of Trust in boot process loads only signed binaries, unlocked BL can break this chain. See Rooting Android phone without unlocking BL, VB and AVB.

However final BL allows somewhat interaction with user to boot fastboot, or Linux kernel from boot or recovery partition. Both partitions don't have filesystems, but a standard raw format as per Android specifications.



Conclusion:

So due to small size, non-standardization, closed-source / signed nature of firmware and minimal functionality, SoC firmware + DT + Aboot setup is no way comparable to BIOS / UEFI + ACPI + GRUB setup. Functionalities like USB communication and graphical selection menus would make the BL kernel bigger than the by-design acceptable size limit. Note that "on embedded ARM platforms the core of LK is typically 15-20 KB."

However SoCs can boot from USB, particularly those used with development boards or single board PCs. See Difference between BootRom and BootLoader.

EFIDroid is a 2nd stage BL based on UEFI (EDK-II). Currently it replaces kernel in boot partition (like other multi-boot hacks), not the original BL.

But we may see (SoC firmware and/or) some (or all) BLs being replaced with UEFI and Device Tree with ACPI (particularly on ARM as it's not very unlikely). It'll make booting from USB devices on mobile phones more probable. For instance Qualcomm's Sanpdaragon 835 already has its SBL replaced with UEFI-based XBL (which also supports ACPI on Windows) and Aboot with ABL. See UEFI on ARM-V8  based Linux Embedded System.



2. How to boot Ubuntu on Android device?

On Android devices it's not possible to boot Ubuntu even from SD card or internal flash memory, rather USB.

Hardware Discovery:

Generic OSes like Ubuntu are not modified for a specific hardware environment. On an ACPI compliant system, after power on, OS may immediately start querying buses: "what hardware is attached to you?", which is not the case with DT based devices. See The case of UEFI for Windows on ARM.

Similarly on PCs Power Management is looked after by ACPI while on phones PMIC is usually a part of SoC - again hardware specific.

Kernel:

Ubuntu userspace is not compatible with Android kernel as latter is largely modified e.g. Paranoid Networking, qtaguid, USB gadgets etc. It's theoretically possible to boot Ubuntu kernel from boot.img e.g. using fastboot, or load it by Android kernel using kexec. However even bigger problem is vendor's incomplete implementations of hardware drivers in kernel, which are not part of upstream kernel source (the one used by Ubuntu). Running console login and traditional X server etc. might not be easy to achieve, see Android vs. Linux.

Binary Blobs:

Android is not strictly based on UNIX's "Everything is a file" theory. Mainly due to license issues, a lot of hardware work is managed by (again) closed-source vendor specific HALs which act as bridge between Android's native/Java framework and kernel e.g. sound, graphics, RIL, fingerprint, camera, sensors and so on. Since Android 8, HIDL (based on Binder IPC) specifically separates vendor-specific binary blobs from AOSP as well as Linux kernel.

Hardware Abstraction:

In addition to binary blobs, AOSP userspace daemons like surfaceflinger, audioserver and gatekeeperd also interface Java stack (which runs apps) on one end, and kernel or HALs on other (which interface hardware). So every hardware component is not simply a file in /dev with well documented kernel interface, instead there are layers of Android-specific IPCs and APIs between apps and hardware.

This model enables AOSP Java framework to be agnostic about lower-level driver implementations, and restricts apps direct access to hardware resources. Apps need manifest permissions to pass through protected APIs in order to access a system resource including storage, network, camera, mic, sound etc.

Partitions:

AOSP depends on a few partitions like /system and /data but HALs need more. On Qualcomm devices vendor daemons like sensors.qti, qseecomd, rmt_storage and wcnss_service read and write to raw block devices (e.g. ssd, rpmb, fsg) and filesystems (e.g. modem, persist and dsp). So camera, sensors, TEE, Wi-Fi, bluetooth, fingerprint, aDSP etc. won't work without extra partitions. SoC, processors, modem, TZ, RPM and BLs also use other partitions for boot process, OTAs, recovery, secure boot, encryption, boot/charging logo and so on. Read more about Android Partitions and Filesystems.

So it's not possible to boot an OS entirely from a single partition. PCs can be started if there is no storage device, but Android devices won't turn on if eMMC / UFS is damaged. Hardware-specific partitions are required at pre-kernel as well as post-kernel stages. That's why Android devices are more vulnerable to be permanently bricked.



Conclusion:

On Android phones there is no generic Android OS, instead we have ROMs which are tightly bound to a specific hardware. So booting Ubuntu on Android device requires integrating all hardware-related vendor code in Ubuntu kernel and/or userspace.



LINKS:


Why don't Android hardware manufacturers build to a common BIOS specification?
Device Tree: What It Is?
Engaging Device Trees.pdf
U-Boot on Arm32, AArch64 and beyond
Nvidia Tegra Boot Flow
LK BL Overview.pdf
Booting Android (Slides)
Comparison of bootloaders
Android HAL and Device driver architecture