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

Android rescue par #7

Closed
PolpOnline opened this issue Jun 5, 2023 · 28 comments
Closed

Android rescue par #7

PolpOnline opened this issue Jun 5, 2023 · 28 comments

Comments

@PolpOnline
Copy link

This is a very similar issue to #1. It makes my phone to reboot directly to the recovery after showing sim card lock, here's the error i screenshotted from OrangeFox:

-2147483648_-210204

I disabled this module through OrangeFox recovery and it worked fine. But obviously now I can't use this module.

@zebz213
Copy link

zebz213 commented Jun 5, 2023

same issue, deleting per_boot from the data folder will allow the phone to boot, but it will be extremely slow, pretty much an unusable experience. disabling the module resolves the issue.

@shizonic
Copy link

shizonic commented Jun 6, 2023

Can confirm: I have the same issue.

@etihwjd
Copy link

etihwjd commented Jun 6, 2023

I'm getting this as well. I'm on a Pixel 6 Pro running Android 14 beta 2.1, and had to reboot into safe mode, disable the module and roll back to the prior version. Lost my banking apps in the process. :-(

I can't get any logs right now because I'm out of the house and need my phone. If the dev @zgfg can leave instructions on how to collect relevant logs, I'll try later.

@3xistenz
Copy link

3xistenz commented Jun 6, 2023

I run an OnePlus 9 with /e/OS (Lineage based) Android 12. I updated this morning through Magisk (direct install) and after reboot my device immediately crashed and went to /e/OS-recovery (same as Lineage). Several reboots did nothing (problem) stayed. When I connected my device to my PC (via USB) that somehow triggered my anti-bootloop-module in Magisk, since the device rebooted with all modules switched off. I was able to delete the V1.0.5 version and now do not know what to do. I'm not an expert, just an user, so I can't help with logs. But I thought I'd mention anyhow.

Probabaly useless to mention that all previous versions worked fine. I've just downloaded and re-enabled V1.0.4 - works! But I have to be carefull with updates now!

@zgfg
Copy link
Collaborator

zgfg commented Jun 6, 2023

I'm getting this as well. I'm on a Pixel 6 Pro running Android 14 beta 2.1, and had to reboot into safe mode, disable the module and roll back to the prior version. Lost my banking apps in the process. :-(

I can't get any logs right now because I'm out of the house and need my phone. If the dev @zgfg can leave instructions on how to collect relevant logs, I'll try later.

If you just disabled the module (without uninstalling it), please go to
/data/adb/modules/BuiltIn-BusyBox

(you can use root explorer like MiXPlorer or TWRP/Advanced/File explorer) and please copy and attach here the log file:
post-fs-data.log

You can re-enable/re-install the module and let it create the log file - thanks

You can always disable the module from TWRP by putting (an empty - doesn't matter) file named exactly as:
disable

into the module's folder:
/data/adb/modules/BuiltIn-BusyBox

Btw, that way you can disable any module, putting the disable file to:
/data/adb/modules/

If there is no TWRP or custom Recovery then you must use Android Safe mode to disable modules that cause issues

@3xistenz
Copy link

3xistenz commented Jun 6, 2023

Problem is that in the current state (directly after reboot, went to recovery) you have no way to enter Safe Mode. And since I use Lineage recovery there is no way to disable there, only ADB would work, but that's almost "over my head". Unfortunately I cannot re-do the process. Booting via Magisk Bootloop Protecter switches all my LSPosed-modules off a well, creating tons of work. Took me almost 2 hours to re-do the damage, ReVanced still not working.

@zgfg
Copy link
Collaborator

zgfg commented Jun 6, 2023

I run an OnePlus 9 with /e/OS (Lineage based) Android 12. I updated this morning through Magisk (direct install) and after reboot my device immediately crashed and went to /e/OS-recovery (same as Lineage). Several reboots did nothing (problem) stayed. When I connected my device to my PC (via USB) that somehow triggered my anti-bootloop-module in Magisk, since the device rebooted with all modules switched off. I was able to delete the V1.0.5 version and now do not know what to do. I'm not an expert, just an user, so I can't help with logs. But I thought I'd mention anyhow.

Probabaly useless to mention that all previous versions worked fine. I've just downloaded and re-enabled V1.0.4 - works! But I have to be carefull with updates now!

If you could please provide the log from v1.0.5 - please see the info how to collect log in my post above

In that post above it is also described how to disable the module (you test and creaate the log, then reboot to custom Recovery and disable the module, later reboot to System and take the log and install working v.1.0.4) - seems you have custom Recovery where you can access Advanced option, File explorer

@zgfg
Copy link
Collaborator

zgfg commented Jun 6, 2023

Problem is that in the current state (directly after reboot, went to recovery) you have no way to enter Safe Mode. And since I use Lineage recovery there is no way to disable there, only ADB would work, but that's almost "over my head". Unfortunately I cannot re-do the process. Booting via Magisk Bootloop Protecter switches all my LSPosed-modules off a well, creating tons of work. Took me almost 2 hours to re-do the damage, ReVanced still not working.

Safe mode disables - not uninstall the modules

Later you just enable them back from Magisk app and reboot - disabling modules does no9t wipe their settings:
Upon reenabled and rebooted, they work again as previously

Btw, I'm not familiar with LOS Recovery but check is there like Advanced options with File Explorer - you can then directly copy the log to /sdcard/Download (your Download folder)

@zgfg
Copy link
Collaborator

zgfg commented Jun 6, 2023

same issue, deleting per_boot from the data folder will allow the phone to boot, but it will be extremely slow, pretty much an unusable experience. disabling the module resolves the issue.

Please see answers above with how to disable the module (One time booting to Android Safe mode and rebooting to System - instructions on Magisk GitHub official page, generally for all modules) or via Custom Recovery

And if you can collect the log please

@3xistenz
Copy link

3xistenz commented Jun 6, 2023

@zgfg: sorry for beeing noob, but the only option I know to boot into Safe Mode is FROM a running system, which state I cannot reach. Also there is no command possability with e/OS / Lineage recovery. And since I have many modules/settings in LSPosed (that also require root), those are all lost after the whole procedure (like AOSP). So it seems both options will not work for me.

@RedKage
Copy link

RedKage commented Jun 6, 2023

same issue, deleting per_boot from the data folder will allow the phone to boot, but it will be extremely slow, pretty much an unusable experience. disabling the module resolves the issue.

Please see answers above with how to disable the module (One time booting to Android Safe mode and rebooting to System - instructions on Magisk GitHub official page, generally for all modules) or via Custom Recovery

And if you can collect the log please

I have some logs, but not sure if they are good.

I am on LineageOS 19.1, and I updated BusyBox from 1.0.4 to 1.0.5.
After rebooting, I could see a 1 second frame of the SIM pin lock screen, then the OS restarted and went directly to the LineageOS recovery screen.

I am unaware of any "safe" mode with LineageOS.

I tried to connect with ADB, it worked, but I could not find the /data/adb directory. All of the "data" directories were empty.
Then I fastbooted to TWRP and I moved the BusyBox folder away.
After rebooting, it worked.

Since I moved the folder, I still have the post-fs-data.log in the directory, and Ipulled it out. There:
post-fs-data.log

@zebz213
Copy link

zebz213 commented Jun 6, 2023

Here is mine also, hope it helps.
post-fs-data.log

@zgfg
Copy link
Collaborator

zgfg commented Jun 6, 2023

same issue, deleting per_boot from the data folder will allow the phone to boot, but it will be extremely slow, pretty much an unusable experience. disabling the module resolves the issue.

Please see answers above with how to disable the module (One time booting to Android Safe mode and rebooting to System - instructions on Magisk GitHub official page, generally for all modules) or via Custom Recovery
And if you can collect the log please

I have some logs, but not sure if they are good.

I am on LineageOS 19.1, and I updated BusyBox from 1.0.4 to 1.0.5. After rebooting, I could see a 1 second frame of the SIM pin lock screen, then the OS restarted and went directly to the LineageOS recovery screen.

I am unaware of any "safe" mode with LineageOS.

I tried to connect with ADB, it worked, but I could not find the /data/adb directory. All of the "data" directories were empty. Then I fastbooted to TWRP and I moved the BusyBox folder away. After rebooting, it worked.

Since I moved the folder, I still have the post-fs-data.log in the directory, and Ipulled it out. There: post-fs-data.log

Thanks for the log

Please tell me, with BB v1 0.4, do you also have folder
/data/adb/modules/BuiltIn-BusyBox/system/bin

or you have:
/data/adb/modules/BuiltIn-BusyBox/system/xbin

Please have BB module installed.
It can be disabled and it can be BB v1 0.4 or v1 0.5

Go to:
/data/adb/modules/BuiltIn-BusyBox

and replace the script you will find there:
post-fs-data.sh

with the modified script attached here (download and unzip)

Enable the module (ie, remove that disable file), reboot and please provide the new log

And please test does it fix the problems you had with v1.0.5

If not, please do one more test I will describe in the next post

post-fs-data.zip

@zgfg
Copy link
Collaborator

zgfg commented Jun 6, 2023

Here is mine also, hope it helps. post-fs-data.log

Thanks for your log, too

Please test/answer as I asked and uploaded in the previous post

Then, if you still have problems:

Please replace post-fs-data sh with the modified one as attached to this post (download and unzip)


Btw, the whole logic in the module is in that script

You can have eg BB module V1 0.4 installed, rename its post-fs-data.sh script to post-fs-data.bak and i install my modified scripts

Later just remove my modified script (if still not helping), rename your bak to sh and reboot

That way you don't need to disable, reinstall, etc

@zgfg
Copy link
Collaborator

zgfg commented Jun 6, 2023

Second version of modified script, if first does not help

Download, unzip, replace in the module folder, reboot
post-fs-data.zip

@zgfg
Copy link
Collaborator

zgfg commented Jun 6, 2023

@PolpOnline @shizonic @3xistenz could you also please test/answer as I described in the previous two posts - thanks

@RedKage
Copy link

RedKage commented Jun 6, 2023

Please tell me, with BB v1 0.4, do you also have folder /data/adb/modules/BuiltIn-BusyBox/system/bin
or you have: /data/adb/modules/BuiltIn-BusyBox/system/xbin

I have only /data/adb/modules/BuiltIn-BusyBox/system/bin

Please have BB module installed. It can be disabled and it can be BB v1 0.4 or v1 0.5

Go to: /data/adb/modules/BuiltIn-BusyBox

and replace the script you will find there: post-fs-data.sh

with the modified script attached here (download and unzip)

Enable the module (ie, remove that disable file), reboot and please provide the new log

And please test does it fix the problems you had with v1.0.5

If not, please do one more test I will describe in the next post

post-fs-data.zip

With v1.0.4 original post-fs-data.sh
-> OK post-fs-data-104.log

With v1.0.4 modified post-fs-data.sh (first one)
-> OK post-fs-data-104-first.log

With v1.0.4 modified post-fs-data.sh (second one)
-> OK post-fs-data-104-second.log

With v1.0.5 original post-fs-data.sh
-> CRASH post-fs-data-105.log

With v1.0.5 modified post-fs-data.sh (first one)
-> OK post-fs-data-105-first.log

With v1.0.5 modified post-fs-data.sh (second one)
-> OK post-fs-data-105-second.log

@zgfg
Copy link
Collaborator

zgfg commented Jun 6, 2023

Please tell me, with BB v1 0.4, do you also have folder /data/adb/modules/BuiltIn-BusyBox/system/bin
or you have: /data/adb/modules/BuiltIn-BusyBox/system/xbin

I have only /data/adb/modules/BuiltIn-BusyBox/system/bin

Please have BB module installed. It can be disabled and it can be BB v1 0.4 or v1 0.5
Go to: /data/adb/modules/BuiltIn-BusyBox
and replace the script you will find there: post-fs-data.sh
with the modified script attached here (download and unzip)
Enable the module (ie, remove that disable file), reboot and please provide the new log
And please test does it fix the problems you had with v1.0.5
If not, please do one more test I will describe in the next post
post-fs-data.zip

With v1.0.4 original post-fs-data.sh -> OK post-fs-data-104.log

With v1.0.4 modified post-fs-data.sh (first one) -> OK post-fs-data-104-first.log

With v1.0.4 modified post-fs-data.sh (second one) -> OK post-fs-data-104-second.log

With v1.0.5 original post-fs-data.sh -> CRASH post-fs-data-105.log

With v1.0.5 modified post-fs-data.sh (first one) -> OK post-fs-data-105-first.log

With v1.0.5 modified post-fs-data.sh (second one) -> OK post-fs-data-105-second.log

Ok, thanks but there are actually only two new logs here:

  • original v1.0.4 did not print thelog file, it is the log from your previous run of the v1.0.5 module

  • v1.0.4 and v1.0.5 (and earlier versions, and the next one) differ only in the version number that is written in the module prop (and that string/number doesn't matter for the behaviour) and this script post-fs-data.sh that runs the whole show

Hence, if you install v1.0.3, v1.0.4 or v1.0.5 and replace that sh script, it is then that new script, not the old v1.0.4 or v1.0.5

As I said, you can keep v.1.0.5 with the first or second modified script - once you have replaced the script, it doesn't matter does the module.prop identifies as v1.0.4 or V1.0.5

I'd like to see logs and results from the others and then one of those two modified scripts will be released as the new v1.0.6 fix

Frankly, second script is almost the same as v1.0.4 (except that script in V1 0.4 did not produce any log and did not 'chase' ToyBox applets)

Hence that second script will be very conservative, almost like going back to v1.0.4

Therefore I'd like to see if your phone can survive stable with the first modified script, that would be then some compromise between v1.0.4 and v1.0.5

This was referenced Jun 7, 2023
Closed
@RedKage
Copy link

RedKage commented Jun 7, 2023

There's something I don't understand. I did the first test with v1.0.4 and original script after having completely removed BB
I installed 1.0.4 from magisk, rebooted, and saved the log.
Are you sure version 1.0.4 doesn't create logs?

If so then I must have messed up somewhere though I don't know how.

Therefore I'd like to see if your phone can survive stable with the first modified script, that would be then some compromise between v1.0.4 and v1.0.5

You want me to try using any BB version, with both modified scripts? I have already done that at least with version 1.0.5 above, or are these logs not belonging to the right version as well?
I'm confused. Which combination should I try to give you the logs?

@zgfg
Copy link
Collaborator

zgfg commented Jun 7, 2023

There's something I don't understand. I did the first test with v1.0.4 and original script after having completely removed BB I installed 1.0.4 from magisk, rebooted, and saved the log. Are you sure version 1.0.4 doesn't create logs?

If so then I must have messed up somewhere though I don't know how.

Therefore I'd like to see if your phone can survive stable with the first modified script, that would be then some compromise between v1.0.4 and v1.0.5

You want me to try using any BB version, with both modified scripts? I have already done that at least with version 1.0.5 above, or are these logs not belonging to the right version as well? I'm confused. Which combination should I try to give you the logs?

Clean installation of v1.0.4 will not create any log. Ie, original posts-fs-data.sh in V1 0.4 does not create logs.
Logs were introduced in BB module with v1.0.5, ie with its script posts-fs-data.sh, and both two new modified scripts I provided yesterday above also print the logs

If you go to the module's folder and remove the log file, then install v1.0 4 and reboot (without replacing the sh script with the new scripts), there will be no logs

But if you don't manually remove the log file, it will stay there forever (v1.0 4 is not 'aware' of that log file)

And for the second part - I didn't ask you to create third set of logs

To the contrary, I commented that you didn't need to test:

a) V1.0.4 with the new modified sh script
b) V1.0.5 with the new modified sh script
C) V1.0.3 with the new modified sh script
etc

Because both work exactly the SAME. And produce EQUAL logs

Once you replace the sh script with the new modified script, it is no more v1.0.4 neither v1.0.5 because the sh script matters (sh script is the logic, engine, whatever you call), not what is defined as
version=1.0.4

or
version=1.0.5

in the module.prop file

Open the module.prop (it's just a textual file, you can edit) and replace to be:
version=1.99.99

and save Open Magisk app, modules and it will show that you have BB version 1.99.99 installed 😁

Ie, if you unzip eg BuiltIn-BusyBox_v1.0.4.zip (installation), you will only find:
LICENCE file (always the same text file)
modul.prop
post-fs-data.sh
META-INF folder with some folders and two files inside (provided on Magisk GitHub, all modules must have that Magisk can recognize as a module installation file)

Hence BB v1.0 x versions differ only in different post-fs-data.sh scripts - and once you overwrite that script with the other, new one, it is no more the old V1 0.x but the new, modified BB

@RedKage
Copy link

RedKage commented Jun 7, 2023

OK, yes I understood that the logic is in the script and everything else doesn't matter.
I was just wondering if you needed other logs, other tests, or if you are good with what I have already provided!

EDIT:
I think I understand what you want: I am now running version 1 of your script.
And I will keep using it for multiple days to see whether version 1 is stable or not!

@zgfg
Copy link
Collaborator

zgfg commented Jun 7, 2023

OK, yes I understood that the logic is in the script and everything else doesn't matter. I was just wondering if you needed other logs, other tests, or if you are good with what I have already provided!

EDIT: I think I understand what you want: I am now running version 1 of your script. And I will keep using it for multiple days to see whether version 1 is stable or not!

Thanks - I will provide Beta soon (module zip for easier installation) to install and (re)test

@zgfg
Copy link
Collaborator

zgfg commented Jun 7, 2023

Hi

@PolpOnline @shizonic @RedKage @etihwjd @3xistenz @zebz213 @TacticalFreak

I'd like to test the fix and release, please perform the following:

  1. Download and install the attached BB v1.0.5a-bugfix module
    and reboot

Based on results from the other users with similar issues, this version should hopefully work for you :-)

  1. Upon rebooting, please use some root explorer like MiXPlorer and go to:
    /data/adb/modules/BuiltIn-BusyBox

find the file post-fs-data.log, copy to your Download folder, zip and provide me back here the log to see results

Please describe also does that v1.0.5.0-bugfix now works fine for you

Thanks

BuiltIn-BusyBox_v1.0.5a-bugfix.zip

@RedKage
Copy link

RedKage commented Jun 7, 2023

Version 1.5.0a worked, no boot loop
post-fs-data.log

@etihwjd
Copy link

etihwjd commented Jun 7, 2023 via email

@zebz213
Copy link

zebz213 commented Jun 7, 2023

Also no problem here, phone runs with no issue so far.

@shizonic
Copy link

shizonic commented Jun 7, 2023

Fine. 1.5.0a works. Great work!

@zgfg
Copy link
Collaborator

zgfg commented Jun 8, 2023

@zgfg zgfg closed this as completed Jun 8, 2023
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

No branches or pull requests

7 participants