tetherback
tetherback copied to clipboard
dlenski
Device support for unmounting by block device is spotty
Either the kernel, or the userspace mount utility, used in TWRP for Google Pixel XL, does not properly support unmounting by block device.
$ adb -d shell 'grep vendor /proc/mounts'
/dev/block/bootdevice/by-name/vendor_b /vendor ext4 rw,seclabel,relatime,data=ordered 0 0
$ adb -d shell 'umount /dev/block/bootdevice/by-name/vendor_b'
umount: can't umount /dev/block/bootdevice/by-name/vendor_b: Invalid argument
$ adb -d shell 'umount /vendor'
$ adb -d shell 'grep vendor /proc/mounts'
These are all good issue reports (#47, #48, #49) but I don't really have any way to test changes to support them, without other users contributing patches.
In the absence of some agreed-on standard for the interface provided by TWRP, all I can do is guess that other devices with handle partitions similar to the ones I've seen.
I'm just a guy who owns two old-ish Android devices, and don't have any way to test whether changes will work with other devices. ¯\_(ツ)_/¯
I'm actually thinking of abandoning tetherback altogether because of this, and because the authors of TWRP are adding (or already have added) backup-over-USB support on their own: https://plus.google.com/+DanielLenskiPDX/posts/FxzDgLgynUP
This particular case just seems like broken or nonstandard behavior from the kernel, or maybe by Busybox. I've never seen a Linux system that didn't support unmounting both by the path of the device node and by the path of the mounted FS.
Are the contents of /dev/block/bootdevice/by-name/* symlinks? If you deference the symlinks and umount /dev/underlying/device/path… does that work?
If not… it should be possible to work around this by looking up the device's mount point in /proc/mounts exactly as you're doing, and then do umount /mount/point instead. Patches welcome :grinning:
If you are referring to USB OTG support, that is not the same thing. In fact, I briefly tried it with an ext4 formatted flash drive before using tetherback, and it was a huge failure for me. Filing some bugs on it would probably help, but I preferred being able to pull to a computer instead of having to go through a flash drive first, especially since backups are really as simple as dd and tar.
I believe the incompatibilities can be solved by making tetherback as generic as possible. For instance, don't provide any hard coded names, or if they're going to be defaults: make them disable-able. Make the user provide translations of names like system_b => system.
I, of course, do not mean to be demanding these fixes from you. I was just filing the bugs so the issues are at least documented, even if they are intentionally never fixed. I may also work on fixing these types of issues myself, in which case you could just merge them if you like them.
If you are referring to USB OTG support, that is not the same thing. In fact, I briefly tried it with an ext4 formatted flash drive before using tetherback, and it was a huge failure for me. Filing some bugs on it would probably help, but I preferred being able to pull to a computer instead of having to go through a flash drive first, especially since backups are really as simple as dd and tar.
Totally agreed, backup via ADB is much more versatile. But see the link I posted: one of the TWRP devs commented with a link to hist own work on adding backup-over-ADB to TWRP itself.
I believe the incompatibilities can be solved by making tetherback as generic as possible. For instance, don't provide any hard coded names, or if they're going to be defaults: make them disable-able. Make the user provide translations of names like system_b => system.
When I first started working on this, I found some Android platform documentation that suggested that there should always be partitions named userdata, system, and cache… turns out once other people starting using it that it's not the case for many devices. :-1:
I, of course, do not mean to be demanding these fixes from you. I was just filing the bugs so the issues are at least documented, even if they are intentionally never fixed. I may also work on fixing these types of issues myself, in which case you could just merge them if you like them.
Sounds good. Pull requests are welcome!
Totally agreed, backup via ADB is much more versatile. But see the link I posted: one of the TWRP devs commented with a link to hist own work on adding backup-over-ADB to TWRP itself.
Out of curiosity, did this actually require any changes to TWRP itself, considering the simplicity of the actions. I also assume there must be a desktop tool to actually do the pull, and how does that work? Is it pretty much the same thing as tetherback (scripting around dd and tar, with their .info generation)?
When I first started working on this, I found some Android platform documentation that suggested that there should always be partitions named userdata, system, and cache… turns out once other people starting using it that it's not the case for many devices. 👎
In my case, I guess you can look at this like a specification change introduced with A/B updates. It is still true that those partitions exist, just with the slot suffix.
Totally agreed, backup via ADB is much more versatile. But see the link I posted: one of the TWRP devs commented with a link to hist own work on adding backup-over-ADB to TWRP itself.
Out of curiosity, did this actually require any changes to TWRP itself, considering the simplicity of the actions. I also assume there must be a desktop tool to actually do the pull, and how does that work? Is it pretty much the same thing as tetherback (scripting around dd and tar, with their .info generation)?
???
You can look at the commit that he linked to for the details: https://github.com/omnirom/android_bootable_recovery/commit/ce8f83c48d200106ff61ad530c863b15c16949d9
You use adb backup on the host side.
That's pretty interesting, actually. The latest fastboot-bootable image for marlin doesn't seem to support this yet (I'll probably have to compile my own, later), but I just tested with a friend on bullhead, and it almost worked: it errored out on /data like mine has been with normal backups. It also appears to be slower than tetherback.
Either way, that's still pretty cool.
I just tested with a friend on bullhead, and it almost worked: it errored out on /data like mine has been with normal backups.
Huh… it basically worked fine for me on hammerhead. That's pretty much the most well-tested, standard-adhering, known-quantity Android device in the world, though.
It also appears to be slower than tetherback.
I am fairly proud of the tricks I used to get tetherback as fast as possible :smile:.
The both of us use LineageOS, which might have something to do with it. I've noticed that I can backup fresh installations (heh), but once I start using the installation, I get the TarFork error. There's no strange bind mounts, so I can't see any reason for this to fail besides the original "backing up device to itself" interference theory, but that happened with adb-based backup, so I no longer have a theory.
Are the contents of /dev/block/bootdevice/by-name/* symlinks? If you deference the symlinks and umount /dev/underlying/device/path… does that work?
I forgot to answer this when it was asked. They are, indeed, symlinks, and unmounting the target device gives the same error. Patching to try unmounting by mount point will probably be necessary.
I still have a use for this project because my smartwatch fills its 512mb or RAM when making a TWRP adb backup, and corruption occurs.
I'm getting the issue described - an alternative on unmount failure may be to prompt the user to unmount the required partitions manually, and then press a button to continue the backup.
