Booting Linux off of Google Drive

Original Article ↗ Hacker News Discussion ↗

Booting Linux from unconventional storage like Google Drive sparks both admiration for the technical stunt and skepticism about its practicality, especially given latency, fragility and timeout issues. Commenters compare it to long-standing network and remote-boot techniques—PXE/TFTP, NFS roots, HTTP/iPXE, S3, even tape and old Sun/Solaris netbooting—arguing that more standard approaches usually work better for real systems. The thread broadens into questions of how tightly operating systems should be coupled to storage, the trade-offs between clever hacks and maintainable infrastructure, and ongoing challenges in achieving fast, reliable boots on modern hardware.

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.