[CLOSED][BETA][2018.7.19] Magisk v16.7 (1671)

Status
Not open for further replies.
Search This thread

georgekav33

Senior Member
Mar 4, 2017
97
31
Xiaomi Mi 5
I have absolutely no clue... :D I'm gonna link this to some people that actually know what they're talking about. Let's hope they have some idea...

I think I am starting to have a clue. The device is a true A/B device, and as such, we have skip_initramfs argument which basically ignores the Ramdisk of the boot.img. So basically what we did with the patch of the boot.img by the app is to patch the recovery (the ramdisk belongs to recovery now).
 

Wesley_NL

Senior Member
Nov 10, 2010
1,888
255
Rotterdam

Didgeridoohan

Retired Senior Moderator
May 31, 2012
12,299
1
14,823
Gone
Google Nexus 4
Nexus 6
I think I am starting to have a clue. The device is a true A/B device, and as such, we have skip_initramfs argument which basically ignores the Ramdisk of the boot.img. So basically what we did with the patch of the boot.img by the app is to patch the recovery (the ramdisk belongs to recovery now).

Is that any different from the Pixel family? Because they can install Magisk just fine.

Yes ok but what about safetynet itself ? That belongs here right ?

From the OP, regarding SafetyNet:
Please do NOT SPAM the forum with these kind of issues! It is NOT a priority to fix
So... No. Keep it in the Pokemon thread or the general support thread.
 

otyg

Senior Member
Apr 5, 2013
670
421
/dev/block/boot detection is broken in latest magisk manager (trying to upgrade to Magisk 16.7).

would it be possible to manually specify the location in the next Magisk Manager update?
 

georgekav33

Senior Member
Mar 4, 2017
97
31
Xiaomi Mi 5
Is that any different from the Pixel family? Because they can install Magisk just fine.

Indeed it should be close because also the MX8 has the latest features/recommendations of Google. BUT, I think it is different when we flash via zip. The binary of Magisk has access to all partitions, and thus by detecting the skik_initramfs, it mounts and modifies the system. When we give the boot.img to the App, it is possible that the script does not do the sanity checks of skip_initramfs, as it does with the recovery mode ; and even if it did, it has zero ability to modify the /system and the true ramdisk in there.

Next test to do is to do an old school root and then use the direct mode of the app. If the Pixel/Pixel 2 is not hard-code as device strings that will use the new skip_initramfs procedure then it should work.
 

SacredDeviL666

Retired Senior Moderator - May You Rest in Peace -
Sep 11, 2008
7,388
8,314
¤No Man's Land¤
Thread Cleaned.

Removed Safetynet posts
Posts without logs
Posts about playstore certifications
Discussion related to other apps
Responses given to all the above & any other non-beta related post. (use the Magisk General Thread :- https://forum.xda-developers.com/apps/magisk/mod-magisk-v1-universal-systemless-t3432382
DO NOT POST LINKS for unofficial builds in an Official Beta Thread.

If i have removed any of your posts in error PM me so i can take a look and action accordingly.

Read OP before you start posting in this thread specially :- https://forum.xda-developers.com/showpost.php?p=72588015&postcount=1

Thanks
SacredDeviL666
Forum Moderator.
 
Last edited:

Homeboy76

Recognized Contributor
Aug 24, 2012
3,882
2,327
Google Pixel XL
Google Pixel 7 Pro
Thread Cleaned.

Removed Safetynet posts
Posts without logs
Posts about playstore certifications
Discussion related to other apps
Responses given to all the above & any other non-beta related post. (use the Magisk General Thread :- https://forum.xda-developers.com/apps/magisk/mod-magisk-v1-universal-systemless-t3432382
DO NOT POST LINKS for unofficial builds in an Official Beta Thread.

If i have removed any of your posts in error PM me so i can take a look and action accordingly.

Read OP before you start posting in this thread specially :- https://forum.xda-developers.com/showpost.php?p=72588015&postcount=1

Thanks
SacredDeviL666
Forum Moderator.
Didn't know it was official :(, thought it was BETA.
The link was to Magisk General Support / Discussion by topjohnwu.
 
Last edited:

Pretoriano80

Senior Member
Jun 9, 2010
3,259
2,940
@topjohnwu
@Didgeridoohan
New issue on Huawei Phones - Mate 10, Mate 10 Pro, P9 - Huawei roll out a new OTA called: "patch01". In the changelog is some fix mentioned (example: mms...) but the main patch is to disable the possibility of Root.

That means: if someone flash Magisk with TWRP, or flash patched_boot.img to ramdisk and reboot the phone, Phone get stuck on the splash screen: "Your device cannot be trusted..." :)
Only flashing back the original Huawei ramdisk.img helps to boot again to system. But no Root with Magisk is anymore possible.
Downgrade helps (if available, because for some Phones like Mate 10 it is dangerous to downgrade, if the Downgrade Firmware has another Xloader.img... but this is another story)

→ So, for Users of Huawei Phones it is better not to install OTA with Patch01 and disable Systemupdate in /system/app/HwOUC - rename HwOUC.apk to HwOUC.bak

I attach here the patch from Huawei for P9 - may you take a look, thanks :)

Hmm, while it's true that latest Huawei behavior goes against modding, we shouldn't expect that Magisk will always work. OEMs will always do their best to avoid rooting (for them it will always be a security isdue) and sometimes might happen that Magisk will be affected by a patch that it's not even direct attack to it. It was like that with other Root solutions even before Magisk.
Now back to this patch 01 issue, any of you tried to debug it while it gets stuck on booting? Did you guys tried to backup patch01's ramdisk and check it against previous stock ramdisk.
What about rolling back the previous kernel.img instead of rolling back to the stock ramdisk?

What i'm trying to say (while i'm not defending Huawei at all) is that so far we are just speculating, without proper logs or anything that could help us understand what changed and how could be fixed.

P.S. If i would be at Huawei HQ and my intentions would be all against rooting, then i would force a bootloader lock with an update. Adios rooting! ? (i really hope they won't go this far)
 

Tecalote

Senior Member
Aug 6, 2015
4,116
3,143
61
Leipzig
Huawei Mate 40 Pro
Xiaomi Mi 11 Ultra
Hmm, while it's true that latest Huawei behavior goes against modding, we shouldn't expect that Magisk will always work. OEMs will always do their best to avoid rooting (for them it will always be a security isdue) and sometimes might happen that Magisk will be affected by a patch that it's not even direct attack to it. It was like that with other Root solutions even before Magisk.
Now back to this patch 01 issue, any of you tried to debug it while it gets stuck on booting? Did you guys tried to backup patch01's ramdisk and check it against previous stock ramdisk.
What about rolling back the previous kernel.img instead of rolling back to the stock ramdisk?

What i'm trying to say (while i'm not defending Huawei at all) is that so far we are just speculating, without proper logs or anything that could help us understand what changed and how could be fixed.

P.S. If i would be at Huawei HQ and my intentions would be all against rooting, then i would force a bootloader lock with an update. Adios rooting! ? (i really hope they won't go this far)

Hi Mate,

We are currently trying to find out if it was an unintended side effect.
For this we will roll up the whole situation with the patch again on two phones and try everything what's possible to sort it out.
I think we will know it at the end of this week.
I will report the results with Logs.

There are also two new Firmwares, which aren't officially released, but available.
We will test them too and see if Root is still possible or not..
 

yochananmarqos

Inactive Recognized Contributor
Feb 15, 2013
3,375
2,520
github.com
Google Pixel 3
Google Pixel 7
:rolleyes: I didn't see that this supports the OG Pixel XL (Marlin)
It specifically says "This script is for the UNLOCKED BOOTLOADER pixel2 / pixel2 XL"
If it does support original Pixel devices it might come in very handy.... :cool:
It does not, but it's very easy to modify.

This is way off topic, FYI.

Sent from my Pixel using XDA Labs
 

demonoidmaster

Senior Member
Nov 19, 2015
1,035
331
as said already; not enough info.
In general you have the options to restore the system from a previous backup. Or a factory reset and clean flash of your rom.
he can just hold down vol - on boot to start up in safe mode

Or he could just delete his magisk img from data/adb and reflash the modules that work all over again or.. Do what guest4711 said about manually creating a file telling magisk to be disabled on boot

What you said about previous back or factory reset and clean flash is dumb, fixing an issue with a magisk module is simple, there's no need for such drastic measures
 
Last edited:

IzaacJ

Inactive Recognized Developer
Sep 2, 2008
688
91
33
Eskilstuna
izaacj.github.io
Samsung Galaxy S7 Edge (Exynos) with Stock Oreo and Magisk 16.7 regularly looses root and says Magisk ain't installed.
Don't find the logs atm (no logs available in MM and on the go) but will attach them later tonight.
However, this happens without any modules installed, usually my only module is V4A but tried now for a week with no modules and still regularly says Magisk isn't installed until a reboot, and then it works for a few hours or so.
Any ideas?
 

Didgeridoohan

Retired Senior Moderator
May 31, 2012
12,299
1
14,823
Gone
Google Nexus 4
Nexus 6
Samsung Galaxy S7 Edge (Exynos) with Stock Oreo and Magisk 16.7 regularly looses root and says Magisk ain't installed.
Don't find the logs atm (no logs available in MM and on the go) but will attach them later tonight.
However, this happens without any modules installed, usually my only module is V4A but tried now for a week with no modules and still regularly says Magisk isn't installed until a reboot, and then it works for a few hours or so.
Any ideas?

That means that both magiskd and magisklogd are killed off somehow. Otherwise one would respawn the other. If you can pull the Magisk log from /cache after it happens it might show something, but a logcat as it happens would likely be the best...
 

IzaacJ

Inactive Recognized Developer
Sep 2, 2008
688
91
33
Eskilstuna
izaacj.github.io
That means that both magiskd and magisklogd are killed off somehow. Otherwise one would respawn the other. If you can pull the Magisk log from /cache after it happens it might show something, but a logcat as it happens would likely be the best...
When this started to happen I tried to see anything in the log inside MM, but since I had to restart to get Magisk to work (and to access the log in MM) it was cleared and only showed since reboot.

Can't access /cache when the root+Magisk ain't working, and after reboot the Magisk log seems to be cleared. The backed up one is only showing init messages and hide_list and proc_monitor messages.

Is there some way to get access to /cache w/o reboot or is it automatically backed up at reboot? If so, there doesn't seem to be any errors.
 
Last edited:
Status
Not open for further replies.

Top Liked Posts

  • There are no posts matching your filters.
  • 1775
    Hello, welcome to the beta Magisk thread! First check the main thread before starting.
    I expect users reporting to at least have basic debug skills, this thread is heavily moderated so refrain from spamming with "useless" reports!


    Latest Magisk Beta: v16.7 (code: 1671)
    Bundled Magisk Manager: v5.8.3

    Release Note | Changelogs | Download

    If you need a clean start, use the uninstaller in the main thread to uninstall any verison of Magisk installation

    Symptoms and Diagnose Procedure:
    • Installing Magisk fails:
      If you're flashing in TWRP: Upload the recovery logs (pull the file /tmp/recovery.log, or select "Advanced > Copy Log" and upload)
      If you're installing in MagiskManager: Choose to save logs after installation and upload
    • I want to report a Magisk bug:
      Magisk logs are placed in /cache/magisk.log
      If you face any issue, please upload /cache/magisk.log
      Starting from v16.6, /data/adb/magisk_debug.log is NOT USED anymore!
    • Magisk Manager is crashing:
      Grab LOGCAT (NOT magisk logs) when the crash occurs, upload the logs and report how to reproduce
    • SafetyNet / CTS / XXX app won't work after enabling MagiskHide:
      If it worked in previous versions, please at least upload /cache/magisk.log
      Please do NOT SPAM the forum with these kind of issues! It is NOT a priority to fix
    Donation
    I spent endless hours to create Magisk. If you like my work, feel free to donate.
    https://www.paypal.me/topjohnwu
    428
    New Stable Release Coming In a Few Hours!
    Thanks for everyone involved in testing the brand new Magisk and provide useful information for me to fix the bugs :)

    And here I give the moderators a sincere respect, please accept my highest appreciation!
    Everyone on the Internet has a real life, not only me but also the moderators. It's very heartwarming to see them willing to sacrifice their time just to give me a better time on the forums.
    I cannot be more grateful, so thanks to all of you again :good:

    Thread will be temporarily closed until a next beta is available, all future releases (except quick hotfixes) should go through a beta stage before directly going to the masses.
    229
    2017.8.13 Magisk v13.5 (1350)(beta)
    Here comes another public beta!
    As most of you should know, Magisk is a fairly young project, and only recently does it undergo a complete rewrite on v13, so I place stability and compatibility first before I kept adding more features into it. This release comes with several major under-the-hood changes, both in native Magisk and Magisk Manager sides.

    Busybox Fights Back Strong
    Previously I had completely removed busybox from Magisk for causing too many troubles, and also the difficulty to build it myself. But after dealing with so many compatibility issues, and the need of reliable and feature packed command-line tools pushed me to add this gem back. I spent quite a lot of time integrating busybox sources into Magisk's building system, and believe me this isn't an easy task: busybox's config is based on Linux kernel, which itself is a complex topic. I created a tool (ndk-busybox-kitchen) to automatically handle the generation of config-based headers, and parse those files into Android.mk to support building with ndk-build command. To be honest this is super dope IMO, and I'm really proud of it lol.

    The next effort is to maximize compatibility for the Magisk installation process. I decided instead of adding busybox directly into the flashable zip, I would directly embed busybox into update-binary, which is now a specially crafted shell script to dump the correct binary for the CPU architecture, and then execute the installation process completely on the busybox's shell and command-line tools. The extracted busybox will also be utilized in many other places such as boot scripts (yes, the boot scripts will now run in a complete busybox environment) and Magisk Manager. The busybox binary will be installed only for internal use, if you want to install busybox to your device, @osm0sis already uploaded a Magisk Module on the repo, please install that instead.

    Finalizing Magisk Procedures
    Magisk hijacks specific points in the boot process, and will go through its own procedures to fulfill all the features. The order of these procedures are now be finalized, which means it is very less likely to change in the future. For post-fs-data mode, general scripts (scripts under post-fs-data.d) and modules scripts (post-fs-data.sh in each module) are executed before magic mount happens. This means experienced developers can now customize magic mount's behavior to a certain degree. However, I still suggest that most scripts should be run in service mode unless necessary such as time critical commands. Service mode will guarantee SELinux patches are finished, and setting props with proper init triggers will not block the device's boot or lead to a crash.

    Samsung Stock Kernel Workarounds
    Well, apparently Samsung is always here to break everything. On stock kernels, it places a restriction on how binaries can behave if they are executed from /data. An additional magisk binary mirror is created to overcome this issue, and will be used extensively in Magisk Manager (it will not effect recovery). Unfortunately, even though I had offloaded most of the functionality into a shell script function collection that can be upgraded through Magisk updates, the template itself still has to be slightly updated to reflect the changes. Magisk Module Template v5 is already live on another branch. However, before you go and upgrade all your modules to v5, please think twice and consider it as a Developer Preview. It depends on the updated util_functions.sh in this beta, so if you upgrade them into the Online Repo, your module won't install on users running the latest stable Magisk version (v13.3). It will be the default template version once the next stable release is live.

    A Small Mistake
    There was a small mistake in v13.3, which the SHA1 of the stock image cannot be acquired, and also the SHA1 backed up within ramdisk is also not extracted. This leads to stock boot image restoration (happens when uninstalling) fails, and will only revert your device by ramdisk backups. This mean you will be able remove Magisk, but the boot image will not be 100% reverted. If you are concern about the backups, restore your boot image back to stock, and reflash this current build to re-create the Magisk's stock boot image backup.
    227
    Beta releases are no longer "development oriented", this thread will be closed and replaced with a more "experimental channel" thread.
    Thank you to all reported useful logs and info, and I highly appreciate all moderators involved in moderating this thread extensively.