I wouldn't technically call this "boot" since the kernel has already booted...
If get google-drive "mounting" support into grub, then I'll concede.
This just places the rootfs on some strange place.<p>btw, I have a project in my drawer, to place rootfs of my NixOS on IPFS.
How about booting Linux off bittorrent? <a href="https://libguestfs.org/nbdkit-torrent-plugin.1.html#EXAMPLES" rel="nofollow">https://libguestfs.org/nbdkit-torrent-plugin.1.html#EXAMPLES</a><p>The problem with booting Linux off very high latency devices is the kernel tends to time out I/O requests after too short a time (60 seconds I think) so you have to adjust those timeouts upwards.
Back in the the day it was possible to boot Sun Solaris over HTTP. This was called wanboot. This article reminded me of that.<p>This was basically an option of the OpenBoot PROM firmware of the SPARC machines.<p>It looked like this (ok is the forth prompt of the firmware):<p><pre><code> ok setenv network-boot-arguments dhcp,hostname=myclient,file=https://192.168.1.1/cgi-bin/wanboot-cgi
ok boot net
</code></pre>
This doesn't only load the initramfs over the (inter)network but also the kernel.<p><a href="https://docs.oracle.com/cd/E26505_01/html/E28037/wanboottasks2-105.html#scrolltoc" rel="nofollow">https://docs.oracle.com/cd/E26505_01/html/E28037/wanboottask...</a><p><a href="https://docs.oracle.com/cd/E19253-01/821-0439/wanboottasks2-61/index.html" rel="nofollow">https://docs.oracle.com/cd/E19253-01/821-0439/wanboottasks2-...</a>
What people really want is sub-second booting, especially in embedded. It is a hard problem but somehow nobody seems interested in doing the hard CS research to solve it.
Love the one up manship!<p>I read the “How to shrink a file system without a live cd. So here’s my one. How to shrink a file system without a live CD as part of a single command install script of a program.<p>My sbts-aru sound localizing recorder program does that on the pi.<p>I’m willing to bet that no other project on the Internet does this, but I’d love to be surprised. Let me know.<p>It installs the majority of the code, then reboots, shrinks the file system. Creates additional partitions and labels them installing file systems. Then finishes the install and comes up running.<p>So the procedure goes as follows.<p><pre><code> sudo apt install -y git
git clone https://github.com/hcfman/sbts- aru.git
cd sbts-aru
sudo -H ./sbts_install_aru.sh
</code></pre>
That’s it. It comes up running a recorder on a system with multiple partitions running an overlayFS on memory on the first one.<p>It will even work on a Raspberry Pi zero (Works on all Pi versions) and it doesn't matter if it's Raspbian or Bookworm.
Speaking of booting Linux from places, what I would like to be able to do is carry a Linux image around with me on my (Android) smartphone, plug the phone into a USB port on a laptop and boot the Linux image from there on the laptop. Does such a thing exist?
I did something similar some time ago: Booting from an RPM repository on a Tumbleweed installation DVD.<p>My initial goal was to write a fuse filesystem for mounting RPM packages, but I wanted to see how far it goes. Turns out, pretty far indeed: <a href="https://github.com/Vogtinator/repomount/commit/c751c5aa56897efd872836cae9ed79a4b59bb852">https://github.com/Vogtinator/repomount/commit/c751c5aa56897...</a><p>The system boots to a working desktop and it appears like all packages available on the DVD are installed.
Any current or future OS should have its filesystem completely <i>decoupled</i> from the OS itself -- thus allowing booting/running the OS off of any kind of plain or esoteric storage device, local or network, present or remote, physical or cloud-based, interrupt/DMA based or API/protocol based, block-based or file-based, real or virtualized, encrypted or not encrypted, tunnelled or not tunnelled, over another protocol or not over another protocol, using TCP/IP or UDP or even just raw 1's and 0's over whatever electronic communication channel someone invents next, etc., etc.<p>Old time OS programmers typically didn't need to think about these things...<p>Current and future OS designers might wish to consider these things in their designs, if they desire maximum flexibility in their current or future OS...<p>Anyway, an excellent article!<p>Related:<p><a href="https://en.wikipedia.org/wiki/Coupling_(computer_programming)" rel="nofollow">https://en.wikipedia.org/wiki/Coupling_(computer_programming...</a><p><a href="https://thenewstack.io/how-decoupling-can-help-you-write-better-software/" rel="nofollow">https://thenewstack.io/how-decoupling-can-help-you-write-bet...</a><p><a href="https://softwareengineering.stackexchange.com/questions/244476/what-is-decoupling-and-what-development-areas-can-it-apply-to" rel="nofollow">https://softwareengineering.stackexchange.com/questions/2444...</a>
This inspired me to study the possibility of booting on one linux and then chrooting to another linux. Reason being that I cannot update the first one, it being too old, but it has important janitorial purposes. With the help of ChatGPT I made this script, where everything seems to work including x-windowed programs.<p><pre><code> sudo mount /dev/sdb2 /mnt
sudo xhost +local:
sudo mount --bind /tmp/.X11-unix /mnt/tmp/.X11-unix
sudo cp ~/.Xauthority /mnt/root/.Xauthority
sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo mount --bind /dev/pts /mnt/dev/pts
sudo unshare --uts chroot /mnt su -l timonoko
sudo umount /mnt/proc
sudo umount /mnt/sys
sudo umount /mnt/dev/pts
sudo umount -l /mnt/dev
sudo umount -l /mnt/tmp/.X11-unix
sudo umount -l /mnt</code></pre>
I remember first getting my cable modem at the house, and I was able to install BSD over the network using a boot floppy.<p>That was an "amazing" thing to me back in the day. I had the bandwidth to do it, a simple floppy to start the whole process and...there it was! BSD on my machine.<p>I'm not sure if you can still do that today. Pretty sure the files were FTP hosted somewhere (or even TFTP). I think today it's all ISOs.
> On the brink of insanity, my tattered mind unable to comprehend the twisted interplay of millennia of arcane programmer-time and the ragged screech of madness, I reached into the Mass and steeled myself to the ground lest I be pulled in, and found my magnum opus.<p>pulitzer prize nomination material
Considering how slow and buggy it is to use as a rootfs, you can instead put an initrd on Google Drive and just boot that. You'll need to make it by hand to get it to a reasonably small size, so picking up a copy of Linux From Scratch, and using libmusl or libuclibc along with BusyBox, will go a long way towards a functional system in a small size.<p>If you want a fuller system you could try 1) convert the filesystem to tmpfs after boot and install packages to RAM, or 2) mount a remote disk image as your roofs rather than keeping individual files remote. The former will be blazing fast but you're limited by your RAM. The latter will be faster than fuse, benefit from io caching, and not have the bugs mentioned.