FORUMS
Remove All Ads from XDA

Magisk General Support / Discussion

1,840 posts
Thanks Meter: 57,601
 
By topjohnwu, Recognized Developer / Recognized Contributor on 4th August 2016, 02:20 AM
Post Reply Email Thread
Announcement from topjohnwu: Info regarding the next release
13th June 2019, 07:40 AM |#34111  
Recognized Contributor
Thanks Meter: 3,184
 
More
Quote:
Originally Posted by ApeironTsuka

If you've previously used adb and given shell Superuser access, you could connect your device to that computer, run this command and then turn the device on.


I hadn't given adb SU access but decided to try that anyway. Doesn't get far enough in the boot for adb to connect, unfortunately. It pops up a quick "Please wait..", crashes back to bootloader, and boots to a "Your system may be corrupt. If this keeps happening yada yada" screen with a try again/factory reset. Since the bootloader on-board is the stock one until this is resolved, it then boots fine from there.

What happens if you flash the new stock (unrooted) kernel to both slots? This almost sounds (guessing since I haven't seen it) that it's failing to boot on one slot then recovering by booting from the other slot. Saying this because you say it fails, then succeeds.
Bootloader will always be stock. Nothing you've done, or attempted to do, effects the bootloader (other than applying the OTA).

Did you patch the new, updated, stock kernel with Magisk or are you trying to use an older kernel?
@martyfender
If he's running stock then he shouldn't be turning dm_verity off anyway.
The Following User Says Thank You to jcmm11 For This Useful Post: [ View ] Gift jcmm11 Ad-Free
 
 
13th June 2019, 08:33 AM |#34112  
Junior Member
Thanks Meter: 7
 
More
Quote:
Originally Posted by Didgeridoohan

That doesn't sound like it's caused by a module. They're loaded later in the boot process. You've likely got something else going on. A wipe might be necessary...

And what about the bootloader? Magisk doesn't touch that.

The module I'm thinking is the problem is the Edge Sense Plus Magisk module. I'm not sure how early in the process that loads. If I could just wipe /data/adb/modules or put it into core only...

Quote:
Originally Posted by jcmm11

What happens if you flash the new stock (unrooted) kernel to both slots? This almost sounds (guessing since I haven't seen it) that it's failing to boot on one slot then recovering by booting from the other slot. Saying this because you say it fails, then succeeds.
Bootloader will always be stock. Nothing you've done, or attempted to do, effects the bootloader (other than applying the OTA).

Did you patch the new, updated, stock kernel with Magisk or are you trying to use an older kernel?

I did the update via the flash-all script of the full factory image, which used slot A. There's nothing installed, or has ever been installed, to slot B. The fail-then-succeed is because I'm loading the Magisk patched bootloader via fastboot while leaving the stock bootloader on the device itself so that it's still at least usable until I can get this sorted. Flashing the Magisk patched bootloader to slot A doesn't change it failing to boot, so I've left the stock one in-place and do all of my testing via fastboot. I apologize for not making that clear before.

I've tried working around it by adding
Code:
write /data/cache/.disable_magisk 1
chmod 0775 /data/cache/.disable_magisk
# sanity check
write /sdcard/bootlog 1
exec -- /system/bin/sh /sdcard/boottest.sh
to the init.rc of the otherwise unchanged stock bootloader between the early-boot and boot triggers (which should be after /data is decrypted and usable..), with the boottest.sh script being
Code:
#!/system/bin/sh
echo "well, it executed" > /sdcard/bootlog # sanity check
/system/bin/whoami >> /sdcard/bootlog # sanity check
echo "cache" >> /sdcard/bootlog
/system/bin/ls -lA /data/cache >> /sdcard/bootlog # see if it *did* create .disable_magisk
echo "modules" >> /sdcard/bootlog
/system/bin/ls -lA /data/adb/modules >> /sdcard/bootlog # because I don't know the directory names used in case I can't do .disable_magisk but can somehow rm -R a module
however, no /sdcard/bootlog is created at all, which is confusing. Unless I should be using /storage/emulated/0 or /data/user/0 instead in those? I'm throwing things at the wall to see what sticks at this point. I don't even know if exec is implemented in the stock, or even the Magisk patched init binary.
13th June 2019, 08:43 AM |#34113  
Didgeridoohan's Avatar
Forum Moderator
Thanks Meter: 7,489
 
Donate to Me
More
@ApeironTsuka From your description it sounds like the device might not even get far enough to decrypt /data...

And again: you keep talking about the bootloader. Magisk only alters the boot image... Two very different things.
13th June 2019, 08:53 AM |#34114  
Junior Member
Thanks Meter: 7
 
More
Quote:
Originally Posted by Didgeridoohan

@ApeironTsuka From your description it sounds like the device might not even get far enough to decrypt /data...

And again: you keep talking about the bootloader. Magisk only alters the boot image... Two very different things.

Ahh sorry, mixing terms. I've been meaning boot image.

Using the stock boot image, it fully boots and is fully usable albeit without root available. However that same boot image, when patched by Magisk, crashes along the way. Tried images patched both by stable (19.3) and canary builds of Magisk with the same result.

The modifications I've done to try to work around it have been using the stock boot image as the base, and it still boots all the way just fine, however I cannot verify if the work arounds have had any effect as the sanity checks in it haven't worked.

Edit:

Why did I never think to do this before. Pulled a 1.7mb logcat during a failed boot (apparently it *is* getting far enough for adb to kick in. Didn't seem like it before). Combing through it now.

Edit 2:
Code:
--------- beginning of crash
06-13 03:19:16.681  1595  1595 E AndroidRuntime: FATAL EXCEPTION: main
06-13 03:19:16.681  1595  1595 E AndroidRuntime: Process: com.android.systemui, PID: 1595
06-13 03:19:16.681  1595  1595 E AndroidRuntime: java.lang.NoSuchMethodError: No direct method <init>(Landroid/content/Context;Lcom/android/internal/colorextraction/types/ExtractionType;)V in class Lcom/android/internal/colorextraction/ColorExtractor; or its super classes (declaration of 'com.android.internal.colorextraction.ColorExtractor' appears in /system/framework/framework.jar!classes2.dex)
06-13 03:19:16.681  1595  1595 E AndroidRuntime:        at com.android.systemui.colorextraction.SysuiColorExtractor.<init>(Unknown Source:0)
06-13 03:19:16.681  1595  1595 E AndroidRuntime:        at com.android.systemui.colorextraction.SysuiColorExtractor.<init>(Unknown Source:6)
06-13 03:19:16.681  1595  1595 E AndroidRuntime:        at com.android.systemui.Dependency.lambda$start$44(Unknown Source:4)
06-13 03:19:16.681  1595  1595 E AndroidRuntime:        at com.android.systemui.-$$Lambda$Dependency$2EP6AlwVDwhJzblZCh1s1Kry3Yc.createDependency(Unknown Source:2)
06-13 03:19:16.681  1595  1595 E AndroidRuntime:        at com.android.systemui.Dependency.createDependency(Unknown Source:25)
06-13 03:19:16.681  1595  1595 E AndroidRuntime:        at com.android.systemui.Dependency.getDependencyInner(Unknown Source:9)
06-13 03:19:16.681  1595  1595 E AndroidRuntime:        at com.android.systemui.Dependency.getDependency(Unknown Source:0)
06-13 03:19:16.681  1595  1595 E AndroidRuntime:        at com.android.systemui.Dependency.get(Unknown Source:2)
06-13 03:19:16.681  1595  1595 E AndroidRuntime:        at com.android.systemui.statusbar.phone.StatusBar.start(Unknown Source:237)
06-13 03:19:16.681  1595  1595 E AndroidRuntime:        at com.google.android.systemui.statusbar.phone.StatusBarGoogle.start(Unknown Source:0)
06-13 03:19:16.681  1595  1595 E AndroidRuntime:        at com.android.systemui.SystemBars.createStatusBarFromConfig(Unknown Source:54)
06-13 03:19:16.681  1595  1595 E AndroidRuntime:        at com.android.systemui.SystemBars.start(Unknown Source:0)
06-13 03:19:16.681  1595  1595 E AndroidRuntime:        at com.android.systemui.SystemUIApplication.startServicesIfNeeded(Unknown Source:144)
06-13 03:19:16.681  1595  1595 E AndroidRuntime:        at com.android.systemui.SystemUIApplication.startServicesIfNeeded(Unknown Source:11)
06-13 03:19:16.681  1595  1595 E AndroidRuntime:        at com.android.systemui.SystemUIService.onCreate(Unknown Source:9)
06-13 03:19:16.681  1595  1595 E AndroidRuntime:        at android.app.ActivityThread.handleCreateService(ActivityThread.java:3570)
06-13 03:19:16.681  1595  1595 E AndroidRuntime:        at android.app.ActivityThread.access$1300(ActivityThread.java:200)
06-13 03:19:16.681  1595  1595 E AndroidRuntime:        at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1672)
06-13 03:19:16.681  1595  1595 E AndroidRuntime:        at android.os.Handler.dispatchMessage(Handler.java:106)
06-13 03:19:16.681  1595  1595 E AndroidRuntime:        at android.os.Looper.loop(Looper.java:193)
06-13 03:19:16.681  1595  1595 E AndroidRuntime:        at android.app.ActivityThread.main(ActivityThread.java:6718)
06-13 03:19:16.681  1595  1595 E AndroidRuntime:        at java.lang.reflect.Method.invoke(Native Method)
06-13 03:19:16.681  1595  1595 E AndroidRuntime:        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:493)
06-13 03:19:16.681  1595  1595 E AndroidRuntime:        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:858)
06-13 03:19:16.683  1208  1218 W RescueParty: Noticed 1 events for UID 10044 in last 15 sec
After 5 of these in 3 seconds, RescueParty kicks in, sets FACTORY_RESET rescue level, and calls for a reboot.
13th June 2019, 11:08 AM |#34115  
zgfg's Avatar
Senior Member
Thanks Meter: 1,066
 
More
That bug with empty Downloads is really not crucial, but I wonder is there some unit testing before committing and regression testing before releasing

Using MM b219 (and M b19301).

Every day (now third day in a row) when opening Downloads, it is empty.

Clear Repo Cache does not help immediately - only after restarting MM, Downloads pulls off and shows data.
13th June 2019, 11:44 AM |#34116  
guest4711's Avatar
Senior Member
Flag Београд (Beograd/Belgrade/Griechisch Weißenburg/Alba Graeca; Alba Bulgarica)
Thanks Meter: 2,176
 
More
Quote:
Originally Posted by zgfg

That bug with empty Downloads is really not crucial, but I wonder is there some unit testing before committing and regression testing before releasing

Using MM b219 (and M b19301).

Every day (now third day in a row) when opening Downloads, it is empty.

Clear Repo Cache does not help immediately - only after restarting MM, Downloads pulls off and shows data.

It's empty for some people, for others it is working fine. For me it is working since dsys, after I did clear repo cache once. And I'm updating IanMacD's unofficial builds >= once a day...
13th June 2019, 12:23 PM |#34117  
Didgeridoohan's Avatar
Forum Moderator
Thanks Meter: 7,489
 
Donate to Me
More
Quote:
Originally Posted by zgfg

That bug with empty Downloads is really not crucial, but I wonder is there some unit testing before committing and regression testing before releasing

Of course there is. And you're a part of it. That's the Canary releases of Magisk and Manager. Expect bugs...
13th June 2019, 01:46 PM |#34118  
Senior Member
Thanks Meter: 60
 
More
Quote:
Originally Posted by Didgeridoohan

There's been no change to Magisk's abilities to hide an unlocked bootloader. Can you pass SafetyNet? If so the unlocked bootloader is hidden...
Apps that look for it stops showing up in the Play store of you somehow have gotten your device flagged as uncertified

Appreciate the thought, but we all pass SafetyNet, all our devices show as still being Play store certified. Only change was updating Magisk to 19.3. I tested it myself after others had mentioned losing Netflix -- Netflix available in Play store, update Magisk, device now not compatible in play store. Google Pay, PayPal, and other bank apps are still available.

Only commonality to all the devices is the unlocked bootloader. I don't believe SafeyNet or Play store certification is dependent on an unlocked bootloader, so it would seem that root is staying hidden but the bootloader status is not...
13th June 2019, 01:49 PM |#34119  
Didgeridoohan's Avatar
Forum Moderator
Thanks Meter: 7,489
 
Donate to Me
More
Quote:
Originally Posted by duh1

Appreciate the thought, but we all pass SafetyNet, all our devices show as still being play store certified. Only change was updating Magisk to 19.3. I tested it myself after others had mentioned losing Netflix -- Netflix available in play store, update, device not compatible in play store. Google Pay, PayPal, and other bank apps are still available. Only commonality to all the devices is the unlocked bootloader. Seems that root stays hidden but the bootloader status is not...

If that's the case you're going to have to gather much more info on why your device is experiencing this. I can't replicate your issue on any of my devices, all of which have Magisk v19.3+ and unlocked bootloaders.
13th June 2019, 02:17 PM |#34120  
Senior Member
Thanks Meter: 60
 
More
Quote:
Originally Posted by Didgeridoohan

If that's the case you're going to have to gather much more info on why your device is experiencing this. I can't replicate your issue on any of my devices, all of which have Magisk v19.3+ and unlocked bootloaders.

Are you on 19.3 stable only, not canary? Clear play store and play services cache, reboot, and search for Netflix in the Play store...
13th June 2019, 02:30 PM |#34121  
Didgeridoohan's Avatar
Forum Moderator
Thanks Meter: 7,489
 
Donate to Me
More
Quote:
Originally Posted by duh1

Are you on 19.3 stable only, not canary? Clear play store and play services cache, reboot, and search for Netflix in the Play store...

I'm practically never on the stable release... At the moment it doesn't matter though, since the current Canary (19301) is pretty much the same as the stable release. But, when reporting about issues and bugs you should always test on the current Canary debug build, to make sure that it hasn't already been fixed and to have more verbose logging.

And lastly, none of that made any difference...

Edit: my main point is that you need to collect more info. Just saying: it's this, without any other kind of information makes it virtually impossible for @topjohnwu to do anything about it if there's an actual issue.
Post Reply Subscribe to Thread

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes