Magisk icon indicating copy to clipboard operation
Magisk copied to clipboard

Magisk cannot detect key events correctly

Open pndwal opened this issue 2 years ago • 16 comments

Device: Redmi Note 8T Android version: 10 Magisk version name: f822ca5 Magisk version code: 23001

Key Combo Timing for Safe Mode on MIUI / Xiaomi

I thought I'd try safe mode on my (Xiaomi) devices... (for my own safety).

I have Mi Pad 4 (LTE) w/ LOS18.1 (Android 11), and Redmi Note 8T w/ stock MIUI (Android 10).

[I have not been able to access Safe Mode from RN8T / MIUI from booted system any which way 🤨, but no problem on Mi Pad 4 / LOS.]

From device powered down I also had issues with timing on both Mi Pad 4 / LOS and RN8T / MIUI.

Holding the pwr button down for more than ~6 seconds after MI / REDMI logos appear causes black screen and fresh reboot, so it is necessary to release pwr after about 4 seconds.

[Releasing pwr then pressing vol- immediately after MI / REDMI logos appear doesn't trigger Safe Mode.]

After releasing pwr at ~ 4 seconds, then waiting (about 10 seconds more) for boot animation (Lineage / MIUI animated logos), then holding vol- until booted, I get Safe Mode but Magisk has not detected button combo, and MagiskHide / modules are still enabled.

Working method:

However, by holding the pwr button down and releasing it after about 4 seconds, then holding vol- during these logos as well as boot animation logos until booted I get safe mode and Magisk detects / disables MagiskHide and modules.

So clearly Magisk's button detection is not reliable and device may boot to Safe Mode without Magisk detecting it.

It seems there is a critical timing sweet spot, at least for Xiaomi, where Safe Mode is triggered and Magisk also detects the key combination.

pndwal avatar Sep 02 '21 00:09 pndwal

May already be fixed upstream from the last Canary? https://github.com/topjohnwu/Magisk/commit/117d1ed0801c0b9fa144d195c0a89cabc488d176

osm0sis avatar Sep 02 '21 01:09 osm0sis

May already be fixed upstream from the last Canary? 117d1ed

No, that must be something else - Entering Safe Mode is not the real issue; Magisk not detecting that this has occurred is.

I'm actually using @vvb2060's latest Alpha w/ TJW commits to 30 August already merged and this remains the same.

This issue can be resolved with some experiments with timing but is causing users to assume Safe Mode method for disabling modules is not working or that their boot problem is not related to incompatible modules when they erroneously assume that these have been disabled...

In short it is misleading and prolonging the agony for those with problem modules causing bootloop.

Would be good if Magisk could piggyback off native Safe mode key detection (probably impossible!) or otherwise properly detect Safe mode once it's booted in order to always disable modules...

pndwal avatar Sep 02 '21 02:09 pndwal

May already be fixed upstream from the last Canary? 117d1ed

I suggest making a commit about supporting F1VM based VMs, Plus, Remove magisk, we don't need it since we can use a VM instead,

Sorry, I don't know what you're talking about... This is a Magisk issue regarding bootloop fix for incompatible Magisk modules...

pndwal avatar Sep 27 '21 08:09 pndwal

You should probably provide some logs, hey?

osm0sis avatar Oct 20 '21 08:10 osm0sis

@pndwal any improvement with 23014? Also you never provided logs and I asked almost a month ago..

osm0sis avatar Nov 12 '21 13:11 osm0sis

You should probably provide some logs, hey?

Very sorry I missed this ping!...

I'll try to do this in next two days; please say best logs...

pndwal avatar Nov 13 '21 02:11 pndwal

@pndwal any improvement with 23014? Also you never provided logs and I asked almost a month ago..

Just tried again w/ 23014 on RN8T and standard Xiaomi Safe Mode booting method:

  1. Turn off our smartphone completely.
  2. Turn it on normally and when the MIUI logo appears, press and hold the volume down button until the system boots completely --> Safe Mode
  3. Reboot --> System

System rebooted w/ Airplane mode on etc, however Magisk is still fully functional; modules enabled as before, SafetyNet passing etc 😕 , so no change.

It is still critical to use variations to trigger Magisk detection of Safe Mode.

After trying this many more times, here is my revised (simplified) working method:

  1. Turn off our smartphone completely.
  2. Turn it on normally. (Can actually release power button immediately.) BUT don't wait for the animated MIUI logo to appear. Press and hold the volume down button after waiting at least 2 seconds until the system boots completely --> Safe Mode.
  3. Reboot --> System.

It seems that OS checks button state sometime after animated logo appears, but Magisk daemon checks before this so doesn't detect Safe Mode with standard key combo instructions.

On RN8T standard logo shows for approx 33 seconds before animated logo appears. Mi Pad 4 is much quicker.

My tests show

  1. Holding volume down before about 3 seconds may not trigger Safe Mode (especially on Mi Pad 4).
  2. Holding volume button down from anywhere between 5 and 25 seconds (on RN8T) boots to Safe Mode with Magisk daemon detection.
  3. Holding volume button down for 30 seconds (3 seconds before animated logo appears) boots to Safe Mode but Magisk daemon fails to detect this.

Useful observation:

Rebooting from safe mode before unlocking screen preserves custom launcher, widgets, and other settings on rebooting to system. Only Airplane mode and Magisk modules + Enforce denylist / MagiskHide need resetting for me.

Another (potentially useful) anomaly:

I can also trigger Magisk daemon Safe Mode detection without entering Safe Mode at all! (Tested on Mi Pad 4.) Simply:

  1. Turn off our smartphone completely.
  2. Turn it on normally, but don't wait for the animated MIUI llogo to appear. Press and hold the volume down button after waiting at least 2 seconds and release it as soon as animated logo appears. Reboots --> System.

After this no Safe Mode changes occur (airplane mode is still off, etc) but Magisk modules + Enforce denylist / MagiskHide are disabled / need resetting.

Also strangely (perhaps due to Magisk expecting an extra boot) no installed modules appear but they return after a reboot in disabled state, so effectively one extra reboot is required.

hidelist / denylist is populated as soon as Enforce denylist / MagiskHide are toggled on. No reboot needed for that as expected.

It now seems to me that since OS and Magisk daemon Safe Mode detection are clearly independent, John could simply provide his own "Restore/Rescue Magisk Boot Mode" or "Magisk SafeBoot Mode" key combo that simply disables Magisk modules + Enforce denylist / MagiskHide without invoking Safe Mode at all. Effectively (with altered key timing) that's what we already have... Just a few tweaks needed?

👀 PW

pndwal avatar Nov 13 '21 05:11 pndwal

You should probably provide some logs, hey?

Very sorry I missed this ping!...

I'll try to do this in next two days; please say best logs...

As I lack experience diagnosing, I'm not sure what type of issue this is.

"Bug Reports For installation issues, upload both boot image and install logs. For Magisk issues, upload boot logcat or dmesg. For Magisk app crashes, record and upload the logcat when the crash occurs."

I'd like to send best logs. Please give a pointer. 🤪

pndwal avatar Nov 14 '21 00:11 pndwal

For something that early dmesg, but logcat could also be useful; for all of the safe mode triggering scenarios you've described.

osm0sis avatar Nov 14 '21 01:11 osm0sis

@Osm0sis, sorry I haven't supplied logs as yet... @Didgeridoohan has confirmed I will need to get a logcat or dmesg when booting into Safe Mode using PC / adb and given me a good guide.

Problem has been getting an hour or two to re-do tests with different timing / PC connected etc; my wife and I have both been in hospital this week; plenty of time with mobile phone in waiting rooms, drip in arm etc, but not with PC. I will get onto this as soon as I can reasonably give it needed attention...

Further, kmsg/last_kmsg are 0 bytes and there's no console-ramoops in /sys/fs/pstore folder on my device.

FWIW, it seems most likely that this quirk is common to many Xiaomi devices, so anyone with Xiaomi can also test; likely not unique to Xiaomi either FTM...

pndwal avatar Nov 17 '21 12:11 pndwal

Take your time, family comes first. last_kmsg is from previous boot so would be more complicated for you than just getting dmesg output. To get dmesg just running dmesg > /sdcard/dmesg.log as root is fine, no PC required, but again, take your time.

osm0sis avatar Nov 17 '21 14:11 osm0sis

As far as I tested, my MIUI can trigger safe mode.

yujincheng08 avatar Mar 24 '22 12:03 yujincheng08

As far as I tested, my MIUI can trigger safe mode.

From booted system? That's interesting... but real issue is with key combo timing for safe mode from device powered down on both my Xiaomi devices.

On both devices I can boot to Safe Mode (by holding vol- as soon as animated logo appears) without Magisk detecting the button combo, and MagiskHide / modules remain enabled after reboot as described.

By varying the timing however (ie. by releasing pwr button, then holding vol- well before animated logo until booted) I can boot to safe mode with Magisk detecting disabling MagiskHide and modules.

The problem is that most guides for safe mode on Xiaomi say 'when the MIUI logo appears, press and hold the volume down button until the system boots' or similar. This means that while safe mode detection by Magisk daemon can work with experimentation, users have assumed either that Safe Mode method for disabling modules is not working, or that their boot problem is not related to incompatible modules when they reboot believing that these have been disabled...

pndwal avatar Mar 24 '22 15:03 pndwal

Additional Issue with same failure to trigger Magisk Safe Mode on newer devices:

̶I̶'̶m̶ ̶r̶e̶a̶d̶i̶n̶g̶ ̶r̶e̶p̶o̶r̶t̶s̶ ̶t̶h̶a̶t̶ ̶l̶a̶t̶e̶ ̶M̶I̶U̶I̶ ̶d̶e̶v̶i̶c̶e̶s̶ ̶(̶M̶i̶ ̶1̶1̶ ̶e̶t̶c̶)̶ ̶n̶o̶ ̶l̶o̶n̶g̶e̶r̶ ̶d̶i̶r̶e̶c̶t̶l̶y̶ ̶b̶o̶o̶t̶ ̶t̶o̶ ̶S̶a̶f̶e̶ ̶M̶o̶d̶e̶ ̶u̶s̶i̶n̶g̶ ̶o̶l̶d̶ ̶k̶e̶y̶ ̶c̶o̶m̶b̶o̶.̶ ̶U̶s̶e̶r̶s̶ ̶r̶e̶p̶o̶r̶t̶ ̶t̶h̶e̶ ̶n̶e̶e̶d̶ ̶t̶o̶ ̶b̶o̶o̶t̶ ̶t̶o̶ ̶R̶e̶c̶o̶v̶e̶r̶y̶ ̶m̶o̶d̶e̶,̶ ̶t̶h̶e̶n̶ ̶s̶e̶l̶e̶c̶t̶ ̶S̶a̶f̶e̶ ̶M̶o̶d̶e̶ ̶f̶r̶o̶m̶ ̶t̶h̶e̶ ̶m̶e̶n̶u̶.̶.̶.̶

Edit: It now seems direct key combo is in fact working even for MIUI 13 (see my post below). ... However there is a problem here as updated instructions for Safe Mode in MIUI are now directing users to boot to recovery, then select Safe Mode from the menu there (added in MIUI 13).

This means that Magisk cannot detect the standard Safe Mode key combo and modules are not disabled even when Safe Mode has been activated, so this Safe Mode method will not restore boot when modules are incompatible.

̶E̶d̶i̶t̶:̶ ̶I̶t̶ ̶s̶e̶e̶m̶s̶ ̶t̶h̶a̶t̶ ̶t̶h̶i̶s̶ ̶m̶a̶y̶ ̶o̶n̶l̶y̶ ̶b̶e̶ ̶a̶f̶f̶e̶c̶t̶i̶n̶g̶ ̶t̶h̶o̶s̶e̶ ̶u̶p̶d̶a̶t̶e̶d̶ ̶t̶o̶ ̶A̶n̶d̶r̶o̶i̶d̶ ̶1̶2̶,̶ ̶b̶o̶t̶h̶ ̶c̶u̶s̶t̶o̶m̶ ̶R̶O̶M̶s̶ ̶a̶n̶d̶ ̶M̶I̶U̶I̶ ̶1̶3̶.̶.̶.̶

Edit: It would therefore seem necessary at least to indicate (in docs) the need to boot to Safe Mode using the depreciated direct key-combo method, and not to select from recovery menu.

pndwal avatar Apr 18 '22 04:04 pndwal

Doesn't it also trigger Magisk through the safe mode prop being set? What prop is MIUI using? Maybe this part can be resolved that way.

osm0sis avatar Apr 18 '22 13:04 osm0sis

Doesn't it also trigger Magisk through the safe mode prop being set? What prop is MIUI using? Maybe this part can be resolved that way.

Not sure about props here, but last comment may be a false alarm in fact, sorry... One user who said direct key combo not working in MIUI 13 just said "Sorry..., but it is possible to start safe mode by "long press the power, the Mi LOGO appears and vibrate to let go, and then keep pressing the volume - until the power is turned on"."... Other users report key combo not working with custom ROMs however... I'll edit post above. 😬

pndwal avatar Apr 18 '22 13:04 pndwal

Can anyone confirm that this issue has been fixed? It seems the change Shana commited only added support for detecting "Reboot to safe mode" from recovery?

canyie avatar Feb 06 '23 07:02 canyie

I can confirm that the issue was NOT fixed...

Sorry i'd missed this request... I did put some comments re. Shana's fix and why I was also sceptical that it would work:

[snip]

AS I mentioned, this is guesswork on my part, and it does seem that there may only be nanoseconds between the setting of these props, so I'm actually equally sceptical that this will be a proper fix... It still looks to me as if Magisk's critical bootstage checks may simply have timed out by the time the animated logo appears on some devices while Android system seems to set the props early but continue checking vol- until animated logo and revert settings unless vol- is still depressed at that point...

So we shall see... I'm happy to see at least some early work on this...

https://forum.xda-developers.com/t/magisk-general-support-discussion.3432382/post-87901089

Anyway, I've just tested this again on Mi Pad 4 w/ 25206 and see the same behaviour...

Safe mode booted by powering up from off state then holding vol- when animated logo appears results in Magisk modules still enabled after a reboot...

As previously, Safe mode booted by powering up from off state then holding vol- well before animated logo appears results in Magisk modules still enabled after a reboot...

... Many thanks for your efforts/attention to this...

pndwal avatar Feb 15 '23 13:02 pndwal

@pndwal, how about booting into recovery, selecting safe mode, and rebooting into normal mode?

yujincheng08 avatar Feb 15 '23 13:02 yujincheng08

@pndwal, how about booting into recovery, selecting safe mode, and rebooting into normal mode?

Sadly that can't work on either of my devices...

Neither Mi Pad 4 w/ LOS 18.1 & TWRP 3.5.0_9-0 nor Redmi Note 8T w/ stock MIUI (but still Android 10) offer a Reboot to Safe mode option in respective recoveries...

I guess that may be a workable solution for some/later devices/OSs...


The issue caused by current boot to Safe mode behaviour may be resolved by either fixing Magisk demons failure to properly respond to key-press data or simply by explaining to users that entering Safe mode is no guarantee that Magisk has detected this / modules are disabled and that they may need to alter key-press timing and try again...

Without this information, as I said above:

The problem is... that while safe mode detection by Magisk daemon can work with experimentation, users have assumed either that Safe Mode method for disabling modules is not working, or that their boot problem is not related to incompatible modules when they reboot believing that these have been disabled...

... Many thanks for your efforts / revisiting this...

pndwal avatar Feb 15 '23 15:02 pndwal

This is not possible, magisk must disable modules before system service starts. Therefore the key press must be detected earlier than system.

vvb2060 avatar Jan 14 '24 18:01 vvb2060

This is not possible, magisk must disable modules before system service starts. Therefore the key press must be detected earlier than system.

Sorry, is neither alternative I suggested possible?... Can't we 'simply explain to users that entering Safe mode is no guarantee that Magisk has detected this / modules are disabled, and that they may need to alter key-press timing and try again so that users don't assume either that Safe Mode method for disabling modules does not work, or that their boot problem is not related to incompatible modules when they reboot because of believing that these have actually been disabled'?

... It does appear that you're saying exactly what I said. but the information should be added to the first TJW FAQ Q. etc...

pndwal avatar Jan 15 '24 03:01 pndwal

As I noted above,

By varying the timing however (ie. by releasing pwr button, then holding vol- well before animated logo until booted) I can boot to safe mode with Magisk detecting disabling MagiskHide and modules.

but

The problem is that most guides for safe mode on Xiaomi say 'when the MIUI logo appears, press and hold the volume down button until the system boots' or similar

and so these methods fails (apparently because by the time the logo appears, post-fs-data has ended). Online instructions for entering safe mode on other devices may be similar...

... To make things worse, this means that users have assumed either that Safe Mode method for disabling modules does not work, or that their boot problem is not related to incompatible modules when they reboot because they believe that these must have been disabled but triggering safe mode

pndwal avatar Jan 15 '24 04:01 pndwal