Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inaccessible userdata after using chroot-distro #33

Open
nickelberg opened this issue Sep 3, 2024 · 25 comments · Fixed by #38
Open

Inaccessible userdata after using chroot-distro #33

nickelberg opened this issue Sep 3, 2024 · 25 comments · Fixed by #38
Assignees

Comments

@nickelberg
Copy link

nickelberg commented Sep 3, 2024

I can't be the only one, so it should be pretty self explanatory.
Happened on two my different phones - common features: Xiaomi, rooted, Android 14.
After exiting shell from distro's chroot and then exiting Termux, phone apps don't have access to phone storage.

Examples:

  • Gallery not able to display photos
  • Files (app) not able to display internal memory files
  • Material Files, here I got more informative error message:
    "java8.nio.file.FileSystemException: /storage/emulated/0: opendir: Transport endpoint is not connected"

Edit:
Important to add - a simple reboot fixes this, but it's cumbersome.

@jjkola
Copy link
Collaborator

jjkola commented Sep 7, 2024

Thanks for the report and the extra information. I did notice your bug report a few days ago. Unfortunately, I have been really busy, so I haven't been able to react to your report.

Just using chroot should not cause this kind of behavior. Also, as chroot-distro uses bind mounts, it should not cause the described behavior.

So, I would like to have more information about the situation so that I can try to reproduce the issue.

First, what distribution did you use? Be as exact as possible.

Second, while using the distribution, what did you do? If you can provide clear steps to reproduce the issue, then all the better.

Third, after exiting the jail, did you just close the Termux, or did you issue some commands?

Also, if you could provide the version of the chroot-distro, that would be helpful.

@nickelberg
Copy link
Author

  1. Debian 12 and Alpine 3.19
  2. Doesn't matter. I can install whole desktop enviroment and vnc server or just do sudo apt update and then quit. It will happen anyway.
  3. Steps:
    3.1 chroot-distro:$ exit
    3.2 Termux#: chroot-distro unmount debian
    3.3 Termux#: exit
    3.4 Termux$: exit
    3.5 *app closes*
  4. It has happened every time I used chroot-distro. Originally in March 16th version and even in the most recent version v1.1.3.

And most importantly I forgot to add:
I'm not using Magisk, I have KernelSU on both of my phones.
There's a high possibility, this is the bug culprit.

@jjkola
Copy link
Collaborator

jjkola commented Sep 15, 2024

Unfortunately I don't have any devices with KernelSU so I can't test this. @YasserNull, do you have any devices with KernelSU?

@YasserNull
Copy link
Collaborator

No, I don't have any devices with KernelSU.

@roninspin
Copy link

roninspin commented Sep 16, 2024

chroot-distro unmount <distro> (ubuntu in my case) really unmounts /storage/* for android instead of chroot distro. Maybe chroot_distro_unmount_system_points receives empty distro_path somehow. Why do we touch /storage after all? Isn't /sdcard sufficient?
Btw. I have KernelSU and I use chroot-distro as a standalone script (without installed module).

@defectly
Copy link

defectly commented Sep 20, 2024

it's not kernelSU problem i guess, i've been using tmoe with magisk for chroots, and there's same problem with unmount

@jjkola
Copy link
Collaborator

jjkola commented Sep 21, 2024

I have checked, and distro_path should not be empty. @nickelberg, @roninspin and @defectly, can you run command -v umount and then with the path run ls -l <path returned by command>. I want to check what is providing the umount command. These needs to be run as a root, and I want the output of both commands.

@defectly
Copy link

I have checked, and distro_path should not be empty. @nickelberg, @roninspin and @defectly, can you run command -v umount and then with the path run ls -l <path returned by command>. I want to check what is providing the umount command. These needs to be run as a root, and I want the output of both commands.

like this?
Screenshot_20240921-132423_Termux

@jjkola
Copy link
Collaborator

jjkola commented Sep 21, 2024

@defectly thanks, that was what I wanted to see

@roninspin Using standalone version of chroot-distro is not a problem, only matter of convenience and preference. If you want, you can run mksh -xv <location of chroot-distro> unmount <distro> after normal login, and redirect the output to a file. The output will tell exactly what commands were run, and with what parameters. If you don't mind would you like to share the output for example through pastebin (or some similar service) if you did run the debug run?

@roninspin
Copy link

roninspin commented Sep 21, 2024

@roninspin Using standalone version of chroot-distro is not a problem, only matter of convenience and preference. If you want, you can run mksh -xv <location of chroot-distro> unmount <distro> after normal login, and redirect the output to a file. The output will tell exactly what commands were run, and with what parameters. If you don't mind would you like to share the output for example through pastebin (or some similar service) if you did run the debug run?

Here you go
https://pastebin.com/MNdaLxJw

P.S. After unmount:

ls -lR /storage
/storage:
total 3
drwxrwx--- 4 media_rw media_rw 3452 2023-06-26 20:26 emulated
drwxr-xr-x 2 root     root       60 2024-09-21 14:23 self
ls: emulated: Transport endpoint is not connected

/storage/self:
total 0
lrwxrwxrwx 1 root root 19 2024-09-21 14:23 primary -> /storage/emulated/0

@jjkola
Copy link
Collaborator

jjkola commented Sep 22, 2024

Based on debug log, the script has worked as it should. I'm starting to think that there may be a problem with toybox implementation of umount in this particular situation, or something else which affects umount calls.

@nickelberg, @roninspin and @defectly: Can you provide as much information about your device as possible?

At least device model, android version, firmware version, twrp version (or if you didn't install twrp, then what did you install, or if you didn't install custom recovery at all), kernel version, busybox version (should not matter but does no harm).

Also, can you guys run toybox --version? Also, if you have custom rom, then what rom, and what version? Also, just in case, whether the device has kernelsu or magisk, and what is the version?

One more thing, can you run mount (and redirect the output to file) before distro login, and after exiting the distro but before unmount command, and lastly after unmount, just so that it is easier to see what happens to mounts. And if you could attach the outputs to your reply (one reply per device)?

@defectly
Copy link

defectly commented Sep 22, 2024

Based on debug log, the script has worked as it should. I'm starting to think that there may be a problem with toybox implementation of umount in this particular situation, or something else which affects umount calls.

@nickelberg, @roninspin and @defectly: Can you provide as much information about your device as possible?

At least device model, android version, firmware version, twrp version (or if you didn't install twrp, then what did you install, or if you didn't install custom recovery at all), kernel version, busybox version (should not matter but does no harm).

Also, can you guys run toybox --version? Also, if you have custom rom, then what rom, and what version? Also, just in case, whether the device has kernelsu or magisk, and what is the version?

One more thing, can you run mount (and redirect the output to file) before distro login, and after exiting the distro but before unmount command, and lastly after unmount, just so that it is easier to see what happens to mounts. And if you could attach the outputs to your reply (one reply per device)?

Xiaomi Redmi Note 10 Pro
model: M2101K6G
codename: sweet
Android 13 Cherish OS 4.8 (custom)
PitchBlack Recovery Project 4.0
KernelSU version 11872
BusyBox for Android NDK version 1.36.1

Screenshot_20240922-120936_Settings

Screenshot_20240922-121208_Termux

mount.txt
mount2.txt
mount3.txt

this problem was even in stock miui rom with tmoe and magisk

@jjkola
Copy link
Collaborator

jjkola commented Sep 22, 2024

If somebody could also provide their device information if this is working properly, then that may help providing direction to where this bug may lay. Based on the mount data from @defectly, it should work without problems, but clearly it isn't.

I checked toybox change logs from news page and the last time umount command was changed is for version 0.8.0, and the change was to ignore -c parameter. So, most likely toybox is not the cause for the bug unless it is a bug which has been there always/very long time.

P.S. @nickelberg and @roninspin, I would still like to get the device information from you guys, so that we have more data available to help pinpoint where the problem lays.

@roninspin
Copy link

roninspin commented Sep 22, 2024

Nubia Red Magic 6 (NX669J)
ROM: stock android 12(L)
kernel: 5.4.249 (lots of backports)
TWRP 3.7.0
KernelSU: 11928
toybox: 0.8.4-android
BusyBox for Android NDK version 1.36.1

Turns out that the reason for the problem (at least for me) is the use of umount with -f (forced) for /storage/emulated. Without that parameter no problems at all.
So, @jjkola, I think you should omit it, at least for /storage/*.

@jjkola
Copy link
Collaborator

jjkola commented Sep 22, 2024

@roninspin Thanks, good catch. We will have to investigate this but it sounds like something has changed on kernel side which makes it unusable on newer kernels (my device is Asus Zenpad 10 (Z301M) with 3.18.35 kernel, and it works). Bind mounts should never affect their originator mounts but clearly this has been broken at some point.

@YasserNull Do you happen to remember why -f flag has been added? I tried digging through the version control but umount -lf <path> seems to be even in the first uploaded version of the file.

@nickelberg
Copy link
Author

Sorry for not much response from me, I'm kinda busy irl lately.


@jjkola

Phone 1:

  • Phone: Xiaomi Mi 9T Pro (codename raphael)
  • ROM: Android 14 - LineageOS 21 (Unofficial build)
  • Kernel: 4.14.350
  • Recovery: OrangeFox R11.1_4 Stable
  • KernelSU: 11872
  • Toybox: 0.8.10-android
  • BusyBox: 1.36.1

Phone 2:

  • Phone: POCO F4 GT (codename ingres)
  • ROM: Android 14 - HyperOS 1.0.4.0.ULJCNXM (xiaomi.eu)
  • Kernel: 5.10.192
  • Recovery: OrangeFox R12.1_1 Unofficial
  • KernelSU: 11928
  • Toybox: 0.8.9-android
  • BusyBox: 1.36.1

@YasserNull
Copy link
Collaborator

@jjkola In fact, I don't remember, but what I do remember is that I used ChatGPT to learn how to use this command.

@jjkola
Copy link
Collaborator

jjkola commented Sep 22, 2024

I did a test on my raspi device where I did multiple successive bind mounts, and forced unmount (-lf) worked properly with kernel 6.6.47. I did the test with normal mount/umount as well as with toybox (0.8.9) mount/umount. I did use loopback device as the source so that is not the same as with block devices.

@roninspin
Copy link

Anyway, -f shouldn't be used all the time (by default).

@jjkola
Copy link
Collaborator

jjkola commented Sep 29, 2024

Fix released.

@jjkola jjkola closed this as completed Sep 29, 2024
@jjkola jjkola linked a pull request Sep 29, 2024 that will close this issue
@jjkola jjkola self-assigned this Sep 29, 2024
@defectly
Copy link

Fix released.

Screenshot_20240929-131531_Termux

so how do i shutdown it?

@jjkola jjkola reopened this Sep 29, 2024
@jjkola
Copy link
Collaborator

jjkola commented Sep 29, 2024

I'll try to add more output to error message to make it easier to pinpoint the problem. Most likely I will have time for that next weekend.

@jjkola
Copy link
Collaborator

jjkola commented Sep 30, 2024

In the mean time, you can try following:
mount | grep <mount_point_path>
losetup | grep <mount_point_path>
lsof | grep <mount_point_path>

If those don't help (and there is no running processes) then you will have to check for anonymous inodes and inotify watchers.

@defectly
Copy link

In the mean time, you can try following: mount | grep <mount_point_path> losetup | grep <mount_point_path> lsof | grep <mount_point_path>

If those don't help (and there is no running processes) then you will have to check for anonymous inodes and inotify watchers.

can it be automatic? tmoe has feature to kill chroot, and it also kills chroot if you use unmount in it

@jjkola
Copy link
Collaborator

jjkola commented Oct 1, 2024

Sure, it can be added. But it can't be default action as it can leave the jail in inconsistent state as it will not bring it down in managed/consistent way. At least, I would prefer bringing my stuff down in a way that it will not cause problems for me in the future.

Also, just to be clear the unmount command just unmounts the known system mount points, it does nothing more, nothing less.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants