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's not about `ConfigFS` as a whole, but specifically `CONFIG_USB_CONFIGFS_MASS_STORAGE`, that is left disabled, while lots of other `CONFIG_USB_CONFIGFS_BLA` are enabled.
This and more can be seen in the `device info` screen of the App mentioned above
Should have said *proper ConfigFS support. Anyway, had no prior interest in this kernel feature until you mentioned the anomaly that is specific to certain vendors.
You can also do `zcat /proc/config.gz | grep CONFIGFS_` in a root shell (su) inside termux to get what options are set by the default kernel.
Android stopped exposing USB Mass Storage, because it's problematic for the core use case of letting you grab pictures and what not from your phone, because it requires exclusive access to a filesystem; that wouldn't be a big deal for you, I don't think, you probably just want to create a large file and expose that as a device, but the implications of exposing the sd card (or the virtual sd card) as mass storage are why it went out of style.
What I'd like to know is why my 2023 phone is still every bit as flaky as my 2018 phone was. For a while I was blaming my Linux solution but every time I try to use it on Windows it's just as flaky.
Fundamentally, accessing files on a live filesystem is a solved problem, and has been since before smart phones. I don't even know how they made such a broken setup.
(I believe the problem with USB mass storage is that it's closer to an IDE/SCSI protocol than a filesystem protocol. You can't have one bit of the system running around "accessing files" while you've got something else "moving the simulated drive head and writing this sector". In principle you could put the work in to make it all work out, but then it would be as flaky as the media access is now, only for a good reason rather than laziness/lockin.)
The situation with USB is a lot more complicated than it appears. See things like this for instance: https://unix.stackexchange.com/questions/120368/make-a-compu... The controllers that sit between the port and the computer can create significant limitations versus what is theoretically possible if you were directly bit-banging the cords.
You can do this with an ethernet cable, if you have one and an ethernet port on both ends. You can manually set up a network on just that cable and transfer at full speed. (AFAIK all modern ethernet ports are capable of figuring out that they need to crossover in this situation and you haven't needed a special crossover cable in a long time.)
If the sd card is mounted by your computer, you can't run any apps on the phone that need to use the sd card. That means, apps you moved to the SD card for space reasons, or apps that might save photos to the SD card (such as messengers).
If your computer messes up the filesystem, then you're in a world of hurt.
If multiple apps can access the filesystem at the same time, why couldn't also some app (background system process) read from / write to the filesystem in an android multi access compatible way, while serving the mass storage device API on the other side
That's possible, but really challenging to do because mass storage is block oriented, the host (desktop) is likely to do read and write caching, and there's no mechanism for a host to say I finished writing this file, and there's no mechanism for a device (phone) to say blocks changed from under you.
The paradigm for block oriented filesystem access is exclusive access, and filesystem code is built around that. There's some niche filesystems around multiple simultaneous access to block devices, but I don't know if there's any that are open source; mostly people don't setup scsi/sas/das disk arrays with two hosts anymore, and when they do, they're much more likely to have exclusive access with failover than simultaneous access.
If you had a team of really detail oriented developers capable of getting this done for Android and desktop platforms, wouldn't you rather they work on something else?
Another approach might be to build a virtual filesystem to export as a block device on usb connection that's essentially a snapshot of the current one, and then you sync any changes that were written on usb disconnect, but then you need to manage divergent changes and that's unfun too.
SMB over USB would be terrible in many ways, but probably handle this use case much better.
> If you had a team of really detail oriented developers capable of getting this done for Android and desktop platforms, wouldn't you rather they work on something else?
If you can improve the world (mass storage device is really wide spread) this way, why not?
For better or worse, most people's photos never get transferred to a computer. Heck, there's a ton of people who don't have a non-phone computing device. Pushing their photos to the cloud so they see them after their current device dies is better than working on a new filesystem that allows for multiple host simultaneous access and porting that to everything. I could make a huge list of more tractable things that this hypothetical team could work on to make Android better for way more people.
Top on my list would be getting it so the touch screen just works every time. I can't count the number of times I've had to turn the screen off and on, because the touch screen came up in a way that I can't swipe up to get the code entry because swiping from the bottom to the top of the screen doesn't move it enough. I've had this happen on pretty much all my androids.
Things like booting faster would actually be nice. Especially since sometimes phones reboot in pockets. Setting up applications for faster starting would be amazing. It's not all in Google's court, but a basic hello world with the Android IDE starts up rather slow, even if you've noticed you need to compile a release build.
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.
What do you do about the USB cable though? A flash drive you can plug in directly, it's guaranteed to work. A phone requires you to either carry around an extra cable (arguably more annoying to carry than a flash drive) or take the risk that you won't have the right cable available nearby when you're trying to (say) boot a laptop.
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.
Reminds me of the credit card sized (literally [1]) USB stick I still have somewhere but it was too annoying to carry around and hope that next time that cheap stick still works...
Using the phone directly still seems the cleanest and most reliable way. Or maybe a combination of both, like those magnetic plugs [2] but with an integrated USB stick. Bonus points if you don't have to take it out at all (until needed) by either connecting the other magnetic part for data transfer and charging or data through USB OTG and wireless charging. One can dream... but the technology will shrink even further so who knows.
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 :)
