USB drives are incredibly useful, both storing files for transport between different computers and for creating bootable drives that let us use or install other operating systems on our computers. While online file storage systems like Dropbox and Google Drive have taken over a large percentage of the former task from USB drives, they have not been able to act as bootable media, ensuring that each of us have a few jump drives lying around. That might not be the case anymore, though, as this guide is the first we know of to be able to use Google Drive to boot to a Linux system.
Unlike the tried-and-true jump drive methods, however, this process is not straightforward at all. It relies on two keys, the first of which is FUSE which allows a filesystem to be created in userspace. The second is exploiting a step in boot process of Linux systems where the kernel unpacks a temporary filesystem, called initramfs, in order to load the real filesystem. Normally a user doesn’t interact much with this step, but that doesn’t mean it’s impossible. A tool called dracut allows using an existing Linux installation to build a custom initramfs and in this case, the custom initramfs is built to include the proper support for both networking and FUSE.
The proof of concept in this demonstration originally ran in a container, using an existing project called google-drive-ocamlfuse to interact with Google Drive itself. From there, after sorting out some issues with root access, networking, malfunctioning symlinks, and various timeouts on the (perhaps predictably) slow system, the whole contraption was moved over to a laptop so it could be tested on real hardware. Everything runs, and although the original creator of this behemoth admits it is a bit “silly” they note that there may be some real-world use cases for something like this. We still won’t expect everyone to throw out their jump drives anytime soon, though. If you’re not feeling like your Linux skills are up to the challenge of something like this, we’d recommend you start with our own [Al Williams]’s Linux Fu series.
Author says “Booting Linux off of a Google Drive root.” The root disk being key here.
No need for all this talk of no more USB sticks because you still need to boot the kernel as to continue on to the step of booting the root file system as they describe.
May be its possible to install and boot the kernel directly from the BIOS EEPROM with Coreboot and do away with USB sticks all together?
yes however it would need to download a new kernel every time since the one in the bios would get out of date
The cloud is somebody else’s computer.
thankfully with LUKS containers, and striping across a RAICP, you can squat on someone else’s storage array without too much drama, its pretty useful and provides better redundancy in many circumstances, of course that relies on a stable network connection, IPFS or something along those lines with immutable squashfs is probably better mind.
You forgot the part of your comment where you make a point rather than sounding like you’re afflicted with some mental condition that requires you to say this every time cloud is mentioned.
It is someone else’s computer, and it’s very cheap and reliable.
I mean truth be told the USB jump drive is probably someone else’s, too. I have a bowl full of lost dogs. (Manage computer labs)
Erm what
And ain’t you glad it is!
Seriously, try to go through what’s involved in setting up a somewhat reliable on-premises operation, including your own data center with backup power, refrigeration, security, redundant Internet access, mirroring, backups and then add geographical redundance.
Regurgitating truthisms is easy.
Pretty cool!
In case you don’t know that : ipxe.org
Best comment here. Thanks for the info.
tftp add to google/dropbox?
nice idea for hacking many computerts
Interesting, sounds like you could run the minimal necessary in grub, and then pull a desktop from the cloud like desktop-as-a-service windows.
Caveat, my kids went to a school where IT called the student (Win) laptops DAAS but I never actually looked into what that meant technically.
Can’t UEFI be exploited for this? Well, exploited is not the word I’d use, since this would be a legit use case…
The magic here isn’t that you can boot an installer without media over the cloud. PXE/bootp/bootparamd/MOP have all been around for decades. IIRC you can even use the UEFI shell to DHCP and retrieve a file over HTTP, so yes, you could use UEFI with manual commands or with a shell script on a local disk.
The novel part is pulling down an encrypted ramdisk as root from an ubiquitous cloud storage provider.
People literally did this with NFS before. Even iSCSI would fare better
There was a purchasable product where you could have a number of disk images on a USB3 stick, make one active, and when a device booted from it, it would only see that image. Sad that such things are not more commonly available (more that it would be neat to be able to reprogram the controllers to implement such functionality).
This is obviously possible using a Pi Zero, et al, but it’s not USB3, limiting the possible performance. Also, you have to wait for the Pi Zero to boot first!
Ventoy and Easy2Boot are two free software solutions that provide exactly this functionality. Ventoy even supports Secure Boot. Having a single USB drive with both Linux ISOs (with persistence) and Windows Installer ISOs on hand has proved very useful.
Those don’t seem to do what I am thinking of. They provide a boot menu which executes, and allows you to select an image to continue booting.
What I am thinking of is a device with mass storage that either exposes the underlying filesystem containing multiple ISO images, allowing manipulation and selection of the active ISO, or else exposes only the active ISO image as the entire device.
This could potentially be implemented using Linux underpinnings as a device with multiple LUN’s. Ideally, however, you want a SBC that has both USB3 gadget AND nvme storage/USB3 Host capabilities. Would be interested to see what is out there. The RK3399 has USB3 gadget, but no fast storage, it seems, beyond eMMC.
Didnt know why USBIP never became popular. It would replace all this hassle and perform just as a remote drive ‘connected’ via usb
Well. you could use it with one of those otherwise ewaste like 256MB or like 1GB USB sticks or whatever.
Oof this’d be rough… I don’t have fiber yet so I get a whole 32mbps down (40mbps DSL + antiquated hardware, I have. VDSL2 hardware on my end but CenturyLink has whatever even older hardware on their end. ).
One note. s3ql filesystem also does the cloudy thing but already behaves properly (symlinks. permissions. sparse files although i found them slow when i used the sparse flag with rsync. even extended attributes.). I have all my storage on a few (with local backends but it’s default is cloud backend). I can even run wine games and VirtualBox VMs out of it.
I think the ONLY differences i’ve noticed from an ext4 filesystem…
1) it is running a fuse filesystem in python so untarring 1000s of small files is slower. Not ridiculously slower though, it’ll untar a linux kernel tree (using spinning rust) in about a minute. I have used it for compiles and it’s fine.
2) No “.” and “..” Doing a “cd ..” works they just aren’s listed by “ls”