Booting Linux off of Google Drive

Original Article ↗ Hacker News Discussion ↗

Novel and Historical Boot Methods

  • Multiple anecdotes of unconventional boots: Windows NT from DAT tape, Windows installed from dozens of floppies, BSD over network from a boot floppy, AIX and Solaris booting from tape or HTTP.
  • Commenters note that sequential tape can be surprisingly OK for linear loads but awful for random access, making it mostly a stunt.
  • Thread references modern equivalents: booting Linux from S3, RPM repos, Git, BitTorrent, and ideas like NixOS on IPFS and Google Drive–based initrd.

What “Booting Off Remote Storage” Really Means

  • Some argue the article isn’t “truly” booting from Google Drive because the kernel and initramfs are local; only the root filesystem is remote.
  • Others suggest treating the first kernel as a bootloader and kexecing a second kernel whose rootfs is remote to make the definition stricter.

Smartphones as Boot Media

  • Several tools and approaches discussed: DriveDroid, Magisk modules, USB mass-storage gadget mode, and running PXE servers on Android.
  • Requirements and limitations: often needs root, specific kernel config (mass-storage gadget or ConfigFS), and correct USB cabling.
  • Debate over practicality: some prefer a tiny USB stick on a keychain; others like the “always with you” phone, despite cable issues.

Network / HTTP / PXE Booting

  • Many parallels drawn to classic TFTP/PXE boot, diskless workstations, Sun’s wanboot over HTTP, and modern iPXE/UEFI HTTP boot.
  • HTTP is favored over TFTP for robustness, security, and ease of configuration.
  • Raspberry Pi and similar boards can PXE/netboot; HTTP boot is seen as a nice way to eliminate SD cards in some setups.

Boot Performance and Engineering Challenges

  • Desire for sub-second boot times, especially in embedded systems; some claim it’s achievable with stripped-down kernels and controlled hardware.
  • Others note most real systems boot slowly due to firmware delays, generic drivers, and lack of coordinated hardware–software design.
  • Disagreement whether this is hard CS research or “just” tedious engineering; analogy drawn to package management complexity.

Reliability and Architecture Considerations

  • SD card failures on Pis reported as common, especially under constant write workloads; others argue careful use (logs in RAM, read-only root) avoids wear.
  • Network-booted Pis backed by a resilient NAS are pitched as easier to back up and maintain at scale.
  • Broader point: OS designs should decouple themselves from specific storage types so rootfs can reside on arbitrary local or remote backends.