There was an article recent for somebody doing it on an Orange Pi [1]. IIUC, you can have one RasPi with an SD Card (I use USB drives but w/e) to be the PXE server and then the rest can all network boot.
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.
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?
This really is nice to have and a sibling comment has already linked to DriveDroid, the solution I'm using for this.
Back in the CyanogenMod days, I had an even better setup: there was an app that also let you emulate a USB keyboard and mouse, so I could, with some command-line trickery, boot a computer from an ISO on my phone, then use that same phone as a keyboard and mouse/trackpad, including in the BIOS.
It doesn't, but consider that the vast majority of us already carry our phones everywhere.
Would carrying an extra USB stick be that big of a hassle? No, but I can see the need for booting up a ready Linux image being extremely situational so the vast majority of time you're just carrying dead weight.
You can have a stick with one boot and one commonly formatted (FAT32/exFAT/ext) partition, Linux image being stored in later. Then it's like a normal stick that can also be used to boot Linux. Ventoy automates this process, allowing you to throw any ISO in a specific directory and boot it.
I have a few Verbatim "Tuff and Tiny" USB drives. Like this but without the plastic clip part. I can fit them in my wallet because its about the thickness of 2 credit cards which are also in my wallet.
USB sticks attached to keychains are already widespread in some communities (DJs for example), I'm sure us software people could do it too if we wanted to :)
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.
btw, I have a project in my drawer, to place rootfs of my NixOS on IPFS.
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.
There's tons of work on millisecond boot times going on, in kata-containers, confidential computing, and various "serverless" implementations. I wrote a paper about it nearly a decade ago too[1].
And I still can't boot my Linux system in a reasonable time. Perhaps the true problem that needs to be solved is that everybody is somehow (forced at) reinventing the wheel every time.
I can only guess here. But remember that software package management was a pain too and it took someone to do a Ph.D. on the topic to give us NiX (and it still isn't perfect).
Ah I see where you're coming from. I don't see any reason to expect that's the case here though. Package management has some fairly obvious tough CS problems inherent in it -- dependency resolution with version upgrades inherently feels NP-hard, for example. Whereas booting is about making hardware that initializes quickly and then making software that abstracts over a variety of hardware well... within the development budget you have. And then you're stuck with backward compatibility as everything changes. I could be wrong here but it feels like a costly engineering problem more than anything else.
(Note I'm not saying you can't do a PhD in it and improve the situation -- you could probably do that for any problem, honestly. Just saying that I think you could get most of the way there by just paying the engineering cost.)
Dependency resolution with versions is indeed NP-hard, if versions "conflict" (2 versions of the same package can't be installed at the same time). What if they don't conflict, and you just wanna install the fewest possible package versions to satisfy all dependencies? That's NP-hard too.
I'm just seeing that this is a forever lingering problem and I think if only engineering costs were involved the problem would have been solved by now.
While not booted from, wimlib's support for pipable WIMs means through some shenanigans, you can install modern Windows from tape. I had a bootstrap ISO that would fire up Windows PE, mount my USB DAT tape drive, rewind it, prep the onboard storage, then image direct from tape to disk and make it bootable.
I posit that because wimlib supports pipable WIMs that we could pipe an endless stream of QR codes to it (thus making the "installing Windows from QR codes" possible)...
If your intended system volume was going to require drivers that weren't built into WinNT, you needed to press F6 at a specific point during installation. This would allow you to load a driver that makes the volume visible / usable.
This process was specific to installing storage drivers needed for the system volume. All other driver installation happened elsewhere.
My memory says there was actually a "Press F6 to load system storage drivers" prompt or something displayed by the installer, but it wasn't displayed for all that long a time and I imagine it was effectively invisible for many people. I recall spamming F6 to make sure I wouldn't miss the prompt.
My first IT job involved installing a lot of Windows 95 from floppy disk. Luckily each PC I bought came with a set, so I'd build up some "good sets" over time after discarding all the disks that had read errors.
Somewhere in my parents' house there is a massive box with floppies for office 95 (or whatever it was called back then). Not 40 floppies massive, but still a large number.
I think we managed to only ever install it once successfully without error.
Also, fun semi-related fact: In my country we called 8" and 5.25" floppies "floppies", and the smaller 3.5" ones were called "stiffies" - because the larger ones were floppy, and the smaller were, well, stiffer. Do with this information as you please.
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.
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.
This was basically an option of the OpenBoot PROM firmware of the SPARC machines.
It looked like this (ok is the forth prompt of the firmware):
This doesn't only load the initramfs over the (inter)network but also the kernel.https://docs.oracle.com/cd/E26505_01/html/E28037/wanboottask...
https://docs.oracle.com/cd/E19253-01/821-0439/wanboottasks2-...
https://ipxe.org/appnote/uefihttp
There was an article recent for somebody doing it on an Orange Pi [1]. IIUC, you can have one RasPi with an SD Card (I use USB drives but w/e) to be the PXE server and then the rest can all network boot.
[1]: https://news.ycombinator.com/item?id=40811725
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 CyanogenMod days, I had an even better setup: there was an app that also let you emulate a USB keyboard and mouse, so I could, with some command-line trickery, boot a computer from an ISO on my phone, then use that same phone as a keyboard and mouse/trackpad, including in the BIOS.
[0] https://play.google.com/store/apps/details?id=com.softwareba...
https://github.com/nitanmarcel/isodrive-magisk
needs root, and your kernel needs USB Mass storage gadget support module enabled, which, sadly, LineageOS doesn't enable by default.
It dosen't work on all smartphone
To rootless Boot a Linux ON (not from) your phone is possible via tmux APP.
Search for "rootless kali nethunter" on YouTube. See here: https://m.youtube.com/watch?v=GmfM8VCAu-I
Would carrying an extra USB stick be that big of a hassle? No, but I can see the need for booting up a ready Linux image being extremely situational so the vast majority of time you're just carrying dead weight.
You're only allowed to use it in the prescribed fashion.
https://www.amazon.com/Verbatim-8GB-Clip-Flash-Drive/dp/B00N...
btw, I have a project in my drawer, to place rootfs of my NixOS on IPFS.
But still, nicely done!
[1] http://git.annexia.org/?p=libguestfs-talks.git;a=tree;f=2016...
I'm surprised to see this, in what way does it require hard CS research? Isn't it just debugging and implementation pain?
(Note I'm not saying you can't do a PhD in it and improve the situation -- you could probably do that for any problem, honestly. Just saying that I think you could get most of the way there by just paying the engineering cost.)
I posit that because wimlib supports pipable WIMs that we could pipe an endless stream of QR codes to it (thus making the "installing Windows from QR codes" possible)...
In the late 90s I worked in the server support line for DEC, and the number of times we had to talk people through the "invisible F6 prompt" was nuts.
This process was specific to installing storage drivers needed for the system volume. All other driver installation happened elsewhere.
My memory says there was actually a "Press F6 to load system storage drivers" prompt or something displayed by the installer, but it wasn't displayed for all that long a time and I imagine it was effectively invisible for many people. I recall spamming F6 to make sure I wouldn't miss the prompt.
I think we managed to only ever install it once successfully without error.
Also, fun semi-related fact: In my country we called 8" and 5.25" floppies "floppies", and the smaller 3.5" ones were called "stiffies" - because the larger ones were floppy, and the smaller were, well, stiffer. Do with this information as you please.
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.