Related
It seems to be quite problematic to implant compression formats into SuperSU systemless install other than gzip.
Here is a method i used for lz4 compression on my lg k8 (mt6753) http://www.chinaphonearena.com/forum/Thread-root-lg-k8 and https://forum.xda-developers.com/lg-k10/how-to/twrp-root-lg-k8-k350n-t3475807.
I guess it must work on other devices and also with other compression methods.
1. Unlock your bootloader
2. Boot to TWRP
3. Backup your boot image
4. Tweak your boot image with Carliv Image Kitchen (http://forum.xda-developers.com/and...-cika-carliv-image-kitchen-android-t3013658):
-Unpack it, open "boot.img-ramdisk-compress" file with a text editor (notepad++) and change the first (and only) line from "lz4" (or whatever you have here) to "gz"
-Repack image
5. Flash the tweaked boot image in TWRP - from now on you must not leave TWRP but use a microsd card to put files from phone to PC and back. You have to stay in TWRP until last step otherwise you might get bricked...!
6. Install SuperSU - do not restart or boot up your phone!
7. Backup boot image again
8. Tweak boot image in Carliv
-Unpack it, open "boot.img-ramdisk-compress" file and change the first line from "gz" to "lz4" (or whatever you had there)
-Repack image
9. Flash boot image in TWRP
10. Restart (this will take a bit longer and also expect bootloop a few times)
Before you proceed you have to check if your boot partition has enough space to accept a bit bigger boot image than the stock one.
In my case the boot partition is 16Mb and my boot image is only 12Mb so after the patching it's still safe to flash it. (After you backed up the boot image try unpack and repack first to see its reel size - sometimes backup takes the whole partition not only the boot.img)
Lz4 is about 1Mb bigger (in my case) than gzip, however other compression methods might differ...
No promises... and no responsibility i take...
Working devices so far:
LG K8 k350n
LG K10 k430Y
The whole story got developed a bit farther by now:
https://forum.xda-developers.com/apps/supersu/ramdisk-compression-exchanger-t3533327
Why can you upload the two boot.imgs
rickwyatt said:
Why can you upload the two boot.imgs
Click to expand...
Click to collapse
What do you mean?
How do you install twrp on the lg k8?
ahmdaini said:
How do you install twrp on the lg k8?
Click to expand...
Click to collapse
You cant install it but you can boot into it. Read the related threads in the k8 and the k10 sections regarding the 2016 models. However there is no twrp for the 2017 models yet.
My phone (3T) has an unlocked bootloader, is encrypted, not rooted, and running stock OOS 5.0.
I flashed TWRP and discovered that stock OOS restores the stock recovery in boot.
I saw the Oreo dm-verity thread by xenet, had a look at the zip file, noticed that it just modified fstab to prevent force encrypt, so I flashed it to see what happens.
And nothing happens. After the system had booted, fstab is unchanged from the original stock copy.
So I'm wondering whether this file is also restored when booting up on stock.
I get aggressive and go back to TWRP and delete /system/etc and /system/bin and modify build.prop.
Surely now the phone won't boot!
Wrong! It boots up and everything is back to normal in /system.
I go back to TWRP and have a look at /system and it shows me one without the etc and bin folders and has the modified build.prop.
What's going on? How can I see one version of /system in TWRP but a different version (ie, stock) when the phone has booted?
By the way I've been an Android user for many years and have rooted and flashed custom ROMs on a variety of phones and I've never seen anything like what's happening on my 3T. I'm sure that dm-verity is somehow involved in this.
Happened to me on my earlier OOS 5.0 attempts...
But i suspected Magisk is involved in my case.
I downloaded Magisk Module "System Terminal Debloater,"
remove some apps like Duo, Chrome, and Google Play Movies.
Some restarts, they magically re-appear again on Apps Drawer...
Haven't touch them yet again after....
nicknacknuke said:
Happened to me on my earlier OOS 5.0 attempts...
But i suspected Magisk is involved in my case.
I downloaded Magisk Module "System Terminal Debloater,"
remove some apps like Duo, Chrome, and Google Play Movies.
Some restarts, they magically re-appear again on Apps Drawer...
Haven't touch them yet again after....
Click to expand...
Click to collapse
Thanks.
I should have mentioned that I'm also not rooted. So stock OOS 5.0.
Sent from my OnePlus 3T using XDA Labs
When you boot TWRP for the first time, it should ask you if you want to put the /system in read/write mode or if you want to leave it unchanged, did you choose the right option?
Jackhass said:
When you boot TWRP for the first time, it should ask you if you want to put the /system in read/write mode or if you want to leave it unchanged, did you choose the right option?
Click to expand...
Click to collapse
No, I don't get that message because my phone is encrypted with a password. So the first thing I see in TWRP is the request for the password and then I'm presented with the menus.
However, in the Mounted menu, system isn't mounted and I have the option of mounting it in read-only mode.
Sent from my OnePlus 3T using XDA Labs
BillGoss said:
No, I don't get that message because my phone is encrypted with a password. So the first thing I see in TWRP is the request for the password and then I'm presented with the menus.
However, in the Mounted menu, system isn't mounted and I have the option of mounting it in read-only mode.
Click to expand...
Click to collapse
After first time flashing TWRP a folder gets created on your internal storage, with a hidden file called .twrps, go delete it and reboot recovery to trigger the message "allowing system modifications" on TWRP's first boot...
It's not about encryption, it's just that TWRP remember the decision you made due to the file I pointed out...
Sent from my OnePlus 3T using XDA Labs
Sam Nakamura said:
After first time flashing TWRP a folder gets created on your internal storage, with a hidden file called .twrps, go delete it and reboot recovery to trigger the message "allowing system modifications" on TWRP's first boot...
It's not about encryption, it's just that TWRP remember the decision you made due to the file I pointed out...
Click to expand...
Click to collapse
Somehow the attachment strikes on previous post
Edit: still not working, check your TWRP Folder on storage to find the file
Sent from my OnePlus 3T using XDA Labs
Sam Nakamura said:
Somehow the attachment strikes on previous post
Edit: still not working, check your TWRP Folder on storage to find the file
Click to expand...
Click to collapse
Thanks, you are correct. I'd forgotten that that TWRP remembers. Deleting .twrps does bring up the RO prompt after decrypting storage.
Jackhass said:
When you boot TWRP for the first time, it should ask you if you want to put the /system in read/write mode or if you want to leave it unchanged, did you choose the right option?
Click to expand...
Click to collapse
I had allowed changes to the system otherwise I couldn't have made changes to it, which includes the ability to restore the system partition.
But I'm still unclear why if I make changes to the system partition and boot with the stock kernel, then after the boot none of the changes are present in the system partition, but if I boot back into TWRP then the changes are all there.
I recall someone in another OOS 5 thread saying that the stock kernal replaces TWRP with stock recovery if you don't flash root (magisk/superSU). Is it possible that the kernel re-flashes system on boot? Another possibility is that TWRP thinks it's making changes to system but it's not actually? Not quite sure, I've never heard of anything like this before either, just throwing other ideas out there.
I've never read anything about the OP3T or any oneplus phones for that matter having A/B system partitions like the pixels. *shrug*
@nhshah7, something's like what you suggest must be going on to account for what I'm seeing. I'm hoping that someone can confirm my observations and provide a definite answer.
@BillGoss
My thread has been updated relating to all your queries...
Thank you...
https://forum.xda-developers.com/oneplus-3t/how-to/disable-dm-verity-force-encryption-op3t-t3688748
Xennet said:
@BillGoss
My thread has been updated relating to all your queries...
Thank you...
https://forum.xda-developers.com/oneplus-3t/how-to/disable-dm-verity-force-encryption-op3t-t3688748
Click to expand...
Click to collapse
Actually it doesn't explain how TWRP can make changes to system yet the phone boots up on an unmodified system if using the stock kernel. And then, when you boot back into TWRP and look at system, the changes are still there.
Where does the unmodified system come from?
Where does the modified system live?
Why doesn't modifying system result in a failed boot due to dm-verity, while restoring a backup of system does result in a failed boot?
So many questions with no answers.
BillGoss said:
....So many questions with no answers.
Click to expand...
Click to collapse
Not sure if this is applicable in your case but the following possibilities may be worth considering for you:
1. Are you sure that the system image is actually getting modified? If the system partition is not mounted before flashing the zip and the zip being flashed does not mount the system partition in read / write, then no changes to system partitions will actually be written.
2. If dm-verity is enabled, then restoring system could result in an error as this is different from restoring a system-image (nandroid copy of the whole partition and not just the files in the system partition). DM-verity can be triggered if the files are all the same but the dm-verity signature computed by hashing the system partition has changed.
3. For boot partitions, strange behaviour can occur if remnants of the previous boot.img are still in the partition (...e.g. if the previous boot.img was of larger size and a new boot.img of a smaller is flashed, then there will be some bytes after the new boot.img that are from the previous boot.img). To verify this, format the boot partition from fastboot and see if you notice anything different with the new boot.img.
4. In Oreo / 8.0, dm-verity flags are stored in dtb (device tree blobs) inside the kernel and not in the fstab file. Only data encryption can be changed from the fstab file and dm-verity needs to be changed from changing the dtb (...Magisk beta v1456 and SuperSu 2.82 SR4 do this, I think).
rk2612 said:
Not sure if this is applicable in your case but the following possibilities may be worth considering for you:
1. Are you sure that the system image is actually getting modified? If the system partition is not mounted before flashing the zip and the zip being flashed does not mount the system partition in read / write, then no changes to system partitions will actually be written.
2. If dm-verity is enabled, then restoring system could result in an error as this is different from restoring a system-image (nandroid copy of the whole partition and not just the files in the system partition). DM-verity can be triggered if the files are all the same but the dm-verity signature computed by hashing the system partition has changed.
3. For boot partitions, strange behaviour can occur if remnants of the previous boot.img are still in the partition (...e.g. if the previous boot.img was of larger size and a new boot.img of a smaller is flashed, then there will be some bytes after the new boot.img that are from the previous boot.img). To verify this, format the boot partition from fastboot and see if you notice anything different with the new boot.img.
4. In Oreo / 8.0, dm-verity flags are stored in dtb (device tree blobs) inside the kernel and not in the fstab file. Only data encryption can be changed from the fstab file and dm-verity needs to be changed from changing the dtb (...Magisk beta v1456 and SuperSu 2.82 SR4 do this, I think).
Click to expand...
Click to collapse
I'll come back to 1.
2. That makes sense and accounts for why a restore of the system partition with the stock boot image causes me to get dumped back in fastboot mode. If I flash the stock system zip file then the system boots properly.
3. I've not had any issues with strange boot behaviour. I'm always starting with stock or flashing kernels that modify the stock boot image, like Blu Spark.
4. I gathered this from my reading of various threads. If I want to make changes to the system partition and get them to stick and not fail dm-verity then I have to flash a custom kernel. I've proven this in my testing. (A rooting solution would also work, but I've not done this).
Back to 1:
Here's what I've done:
Starting with pure stock image (flash OOS 5.0).
Boot into fastboot and flash TWRP.
Boot into recovery.
Mount system as rw. (In ro mode the next step fails)
Delete the bin, etc, and lib folders in system using the TWRP file manager. (Screenshot a)
Reboot system.
... First interesting fact ...
System boots ok, deleted folders are present in file manager. (Screenshot b)
Boot into fastboot and flash TWRP. (Booting with stock restores stock recovery)
Mount system.
... Second interesting fact ...
TWRP file manager shows that deleted folders are missing. (Screenshot c)
Flash custom kernel or patched boot image
Reboot system
... Third interesting fact ...
System fails to boot. Hangs on splash screen.
So TWRP made the changes (otherwise how could they be visible between reboots, including a replacement of recovery) and I only did them once.
Yet they don't actually take effect until I replace the stock boot image.
So, where are the changes hiding? What did TWRP actually change?
Screenshots (note that TWRP has the wrong timezone set so the time shown is wrong):
BillGoss said:
....
Back to 1:
Here's what I've done:
Starting with pure stock image (flash OOS 5.0).
Boot into fastboot and flash TWRP.
Boot into recovery.
Mount system as rw. (In ro mode the next step fails)
Delete the bin, etc, and lib folders in system using the TWRP file manager. (Screenshot a)
Reboot system.
... First interesting fact ...
System boots ok, deleted folders are present in file manager. (Screenshot b)
Boot into fastboot and flash TWRP. (Booting with stock restores stock recovery)
Mount system.
... Second interesting fact ...
TWRP file manager shows that deleted folders are missing. (Screenshot c)
Flash custom kernel or patched boot image
Reboot system
... Third interesting fact ...
System fails to boot. Hangs on splash screen.
So TWRP made the changes (otherwise how could they be visible between reboots, including a replacement of recovery) and I only did them once.
Yet they don't actually take effect until I replace the stock boot image.
So, where are the changes hiding? What did TWRP actually change?
Screenshots (note that TWRP has the wrong timezone set so the time shown is wrong):
Click to expand...
Click to collapse
Some more thoughts for you to consider:
1. Have you tried this with the official TWRP recovery version 3.2.0-0?
2. Is there anything inside the folders that you see using the file manager after a regular boot? Folders of same name may exist in the boot ramdisk and these are merged with system folders after boot.
3. Try wiping cache between reboots and see if that changes any of your observations.
rk2612 said:
Some more thoughts for you to consider:
1. Have you tried this with the official TWRP recovery version 3.2.0-0?
2. Is there anything inside the folders that you see using the file manager after a regular boot? Folders of same name may exist in the boot ramdisk and these are merged with system folders after boot.
3. Try wiping cache between reboots and see if that changes any of your observations.
Click to expand...
Click to collapse
Good questions. They got me thinking more about how this could possibly work.
I had a look at the cache and there's definitely no copy of the system hiding there.
I also unpacked the ramdisk in the boot image and it had nothing in system. Furthermore, the boot position is only 64 MB, no where near enough to hold the system.
Then I installed Magisk so that I could browse around the phone's partitions and take copies.
I learnt two things from this:
1. If there's a second copy of the system there are only three partitions large enough to hold it (/proc/partitions shows the sizes in 1 kB blocks). The system is about 1 GB. There is space in the system partition (sde20) for 3 GB. There's also space in the data partition (sca15). And there's space in the major partition holding the modems (sdf).
I could eliminate the data partition by formatting it but restoring the internal storage (sdcard) is such a a pain.
So I'll just accept that there is space for a copy, but I'm unlikely to find out exactly where.
2. When I had Magisk installed installed and the system boot, I added a folder and file to /system/priv-app using a file manager (so not using TWRP). I then booted into recovery, flashed the stock boot image, and rebooted. I was expecting it to fail dm-verity (modified system) but it didn't. After booting up there's no evidence of the folder I added to priv-app.
And if I restore the Magisk boot image then the additions show up again.
I'm actually very impressed with how the stock system (kernel, recovery, system) protects itself from modification. Very cool!
I attempted to go from Magisk v16 to Magisk v17 from the app, Install > Patch Boot Image File > Magisk-v17(1700).zip and I get the below .
I opened up Root Checker and it let me know that the device no longer has Root.
- Copying image to cache
- Device platform: arm64-v8a
- Existing zip found
- Extracting files
! Installation Failed
Magisk Log File
- Copying image to cache
- Device platform: arm64-v8a
- Existing zip found
- Extracting files
boot_patch.sh[73]: can't create /proc/self/fd/: Is a directory
MagiskBoot v17.0(17000) (by topjohnwu) - Boot Image Modification Tool
Parsing boot image: [/data/user_de/0/com.topjohnwu.magisk/install/boot.img]
No boot image magic found!
boot_patch.sh[91]: can't create /proc/self/fd/: Is a directory
boot_patch.sh[91]: can't create /proc/self/fd/: Is a directory
! Installation failed
Device Stats
Nexus 6P
Lineage 15.1
TWRP - latest
Any help would be greatly appreciated.
monteie2016 said:
I attempted to go from Magisk v16 to Magisk v17 from the app, Install > Patch Boot Image File > Magisk-v17(1700).zip and I get the below .
I opened up Root Checker and it let me know that the device no longer has Root.
- Copying image to cache
- Device platform: arm64-v8a
- Existing zip found
- Extracting files
! Installation Failed
Magisk Log File
- Copying image to cache
- Device platform: arm64-v8a
- Existing zip found
- Extracting files
boot_patch.sh[73]: can't create /proc/self/fd/: Is a directory
MagiskBoot v17.0(17000) (by topjohnwu) - Boot Image Modification Tool
Parsing boot image: [/data/user_de/0/com.topjohnwu.magisk/install/boot.img]
No boot image magic found!
boot_patch.sh[91]: can't create /proc/self/fd/: Is a directory
boot_patch.sh[91]: can't create /proc/self/fd/: Is a directory
! Installation failed
Device Stats
Nexus 6P
Lineage 15.1
TWRP - latest
Any help would be greatly appreciated.
Click to expand...
Click to collapse
Happened with me also...i gues the only solution is you have to uninstall mafisk via magisk uninstaller and flash it once again via whatever recovery you are using...i am also using lineage os 15.1 but with RN4....
Happened to me as well. HTC u11, ViperU 1.8.0, Android 7.1.1, TWRP 3.2.2. Tried flashing it though TWRP got a bootloop. Had to revert back to my previous nan which luckily I made yesterday.
I attempted the same, now my galaxy s6 is in a boot loop
Look other posts in this section - you should flash latest uninstaller before Magisk v17 package. It seems that some residues from v16 prevent v17 from installing correctly.
^^^^^^^^^^
how to uninstall magisk completely without custom recoery
Hello Guys
I can not install Magisk v17.1
I delete it complete with the uninstaller
And then flashed again in TWRP, but dont work
Magisk icon is not visible and I can not manually install the Magisk Manager
Pls Help
edkmho said:
how to uninstall magisk completely without custom recoery
Click to expand...
Click to collapse
I had to reflash stock (OTA sideload version, in stock recovery) via adb sideload. Essential phone. Wifi is working now, didn't lose any data.
I'm also having the issue on my OnePlus 5T. I was running v16.0, and when I tried to flash the v17.1 zip in TWRP like usual, but it said zip signature verification failed. I flashed the Magisk uninstaller zip and tried again, but still had the same problem. I've lost root, but all my data is still intact and it never had boot issues.
After using uninstaller in recovery, restart into recovery to flash v17
aydinbahadir88 said:
And then flashed again in TWRP, but dont work
Magisk icon is not visible and I can not manually install the Magisk Manager
Click to expand...
Click to collapse
Do you update from 16.0? If Yes test following:
Download the seperate MagiskManager-v5.9.1.apk
Make sure that you adb is working, connect your phone to computer
Code:
adb devices
must show your phone, if not adb is not proper set
Code:
adb install MagiskManager-v5.9.1.apk
if you get a error message like
the sign with the installed apk has not matsched..aborted
Click to expand...
Click to collapse
the uninstaller not proper delete the old magisk manager
try
Code:
adb uninstall com.topjohnwu.magisk
the result must be an sucess
then again
Code:
adb install MagiskManager-v5.9.1.apk
result must also sucess
Reboot, voiala its done....
You see the Magisk Manager
Does anyone have a working solution?
1.download magisk 17.zip from inside magisk 16
2. uninstall magisk 16 (i do from inside, not twrp)
3. instal magisk 17.zip from twrp
4. open magisk 17 and get notification for downloaded magisk 17.apk
5. download and instal it,
tested by my phone
mi5 Lineage Os 15.1
How I recovered from this on a Pixel 2 XL
I'll chime in with my experience here, as it might save someone else a lot of time if they are at my skill level with this stuff (which is only moderate, I suppose, although I do always get things to work eventually!).
As of yesterday, I had a Pixel 2 XL, rooted with Magisk, and working great. This morning, during the middle of the night, Magisk innocently asks if I want to upgrade to a new version. I was very tired (in fact, I think I was sleeping when my phone buzzed to alert me of the upgrade message) and don't even know how I responded except that it was "yes" to the upgrade part. By the time I'd fully awakened, I had a phone that waw in a boot loop. I went back to sleep, figuring I'd have better luck looking at it after a little rest.
Getting out of the boot loop was easy: I just reinstalled the August 2018 factory image for the phone. However, getting Magisk reinstalled was an adventure. I saw posts that said I should run the Magisk uninstaller, but when I did it just said that Magisk was already uninstalled. And yet, whenever I tried to apply either v16.0 or v17.1, I got errors (error codes 1, 2, and 255 at different times).
Up until this event, I'd always upgraded Magisk by installing it via TWRP. However, that was not working, so I thought I needed to try patching the boot image, something I'd never done before. Because I'd never done it before, it took me a while to understand the steps, which are actually quite simple. This is where I'm hoping I might save someone some time. Basically, my fear was not knowing which file the "boot image" was. Seasoned Android veterans might get a chuckle out of this, and that's fine, but I was looking at the file in the factory image download and basically saw only two image files: bootloader-taimen-tmz20j.img and radio-taimen-g8998-00253-1805232234.img. I was trying to figure out if either of those could be the boot image, and they both seemed pretty big to be a boot image! Finally it dawned on me that the much larger file in the directory was a zip archive (named image-taimen-ppr1.180610.009.zip). I looked inside there, and sure enough, there was a rather small file named boot.img. I was pretty sure that was the "boot image" file!
Here's what I did after that, again just hoping to help anyone who finds themselves in the same predicament I was in: Magisk is broken, root isn't working, and I can't install any of the Magisk *.zip images via TWRP.
- First, I downloaded a copy of Magisk Manager: this version is named MagiskManager-v5.9.1.apk.
- Next, I ran a couple adb commands to send the Magisk Manager apk and the stock boot.img to my phone:
Code:
adb push MagiskManager-v5.9.1.apk /sdcard/Download
adb push boot.img /sdcard/Download
- Next, I installed /sdcard/Download/Magisk-Manager-v5.9.1.apk by nagivating to it (I use ES File Manager) and launching it from there.
- Next I opened Magisk Manager
- Magisk Manager detects that there is a newer version available and asks if I want to upgrade
- I said yes
- I told it that I wanted to patch a boot image
- I chose /sdcard/Download/boot.img as the "unpatched" (stock) boot image
- Magisk Manager churned away for maybe half a minute and then produced a new file called patched_boot.img, saved in the same directory as boot.img.
After that, all I had to do was run these commands:
Code:
adb reboot bootloader
fastboot flash boot patched_boot.img
fastboot reboot
As soon as the phone restarted, I opened Magisk Manager again and it verified that its upgrade was successful, and root began working for me again also.
Like I said, I hope this helps someone else. If not, it's probably good for me to just write it all out anyway.
Cheers,
Sky Captain
_sky.captain_ said:
I'll chime in with my experience here, as it might save someone else a lot of time if they are at my skill level with this stuff (which is only moderate, I suppose, although I do always get things to work eventually!).
As of yesterday, I had a Pixel 2 XL, rooted with Magisk, and working great. This morning, during the middle of the night, Magisk innocently asks if I want to upgrade to a new version. I was very tired (in fact, I think I was sleeping when my phone buzzed to alert me of the upgrade message) and don't even know how I responded except that it was "yes" to the upgrade part. By the time I'd fully awakened, I had a phone that waw in a boot loop. I went back to sleep, figuring I'd have better luck looking at it after a little rest.
Getting out of the boot loop was easy: I just reinstalled the August 2018 factory image for the phone. However, getting Magisk reinstalled was an adventure. I saw posts that said I should run the Magisk uninstaller, but when I did it just said that Magisk was already uninstalled. And yet, whenever I tried to apply either v16.0 or v17.1, I got errors (error codes 1, 2, and 255 at different times).
Up until this event, I'd always upgraded Magisk by installing it via TWRP. However, that was not working, so I thought I needed to try patching the boot image, something I'd never done before. Because I'd never done it before, it took me a while to understand the steps, which are actually quite simple. This is where I'm hoping I might save someone some time. Basically, my fear was not knowing which file the "boot image" was. Seasoned Android veterans might get a chuckle out of this, and that's fine, but I was looking at the file in the factory image download and basically saw only two image files: bootloader-taimen-tmz20j.img and radio-taimen-g8998-00253-1805232234.img. I was trying to figure out if either of those could be the boot imag, and they both seemed pretty big to be a boot image! Finally it dawned on me that the much larger file in the directory was a zip archive (named image-taimen-ppr1.180610.009.zip). I looked inside there, and sure enough, there was a rather small file named boot.img. I was pretty sure that was the "boot image" file!
Here's what I did after that, again just hoping to help anyone who finds themselves in the same predicament I was in: Magisk is broken, root isn't working, and I can't install any of the Magisk *.zip images via TWRP.
- First, I downloaded a copy of Magisk Manager: this version is named MagiskManager-v5.9.1.apk.
- Next, I ran a couple adb commands to send the Magisk Manager apk and the stock boot.img to my phone:
Code:
adb push MagiskManager-v5.9.1.apk /sdcard/Download
adb push boot.img /sdcard/Download
- Next, I installed /sdcard/Download/Magisk-Manager-v5.9.1.apk by nagivating to it (I use ES File Manager) and launching it from there.
- Next I opened Magisk Manager
- Magisk Manager detects that there is a newer version available and asks if I want to upgrade
- I said yes
- I told it that I wanted to patch a boot image
- I chose /sdcard/Download/ as the "unpatched" (stock) boot image
- Magisk Manager churned away for maybe half a minute and then produced a new file called patched_boot.img, saved in the same directory as boot.img.
After that, all I had to do was run these commands:
Code:
adb reboot bootloader
fastboot flash boot patched_boot.img
fastboot reboot
As soon as the phone restarted, I opened Magisk Manager again and it verified that its upgrade was successful, and root began working for me again also.
Like I said, I hope this helps someone else. If not, it's probably good for me to just write it all out anyway.
Cheers,
Sky Captain
Click to expand...
Click to collapse
I too have a Pixel 2XL but had a much easier upgrade experience. I downloaded the latest version of Magisk files (3 files: MagiskManager-v5.9.1.apk, Magisk-uninstaller-20180901, and Magisk-v17.1 from here https://www.xda-developers.com/magisk-v17-1-android-pie-a-b-support/) and put them on my phone.
Rebooted into recovery TWRP run the Magisk-uninstaller-2018090 file, then ran Magisk-v17.1 rebooted and all worked (thanks to ALL the developers out there!!!)
I'm running rooted Pie (standard google Pie) with Rootchecker, 4.4.153-FlashKernal-Wahoo-v3.06, Greenify, AdAway, and of course Magisk 17.1.
Hope this helps.
akohle said:
After using uninstaller in recovery, restart into recovery to flash v17
Click to expand...
Click to collapse
flashed uninstaller in recovery
flashed v17
rebooted
it worked
If patch boot image is getting failed in magisk latest version v17.1 then enable storage permission for magisk app manually in Device/OS setting. Now patch boot image again, It will get patched successfully.
I
pierro78 said:
flashed uninstaller in recovery
flashed v17
rebooted
it worked
Click to expand...
Click to collapse
OK...im a relative newbie here...first post actually....but Im a bit stuck in a fastboot boot loop
LG G5 tmobile running fulmics
I decided to try this exact process to get my root back by updating Magisk
booted into TWRP through ADB
flashed uninstaller using TWRP
(cleared cache/dalvik)
flashed v 17.1 (not 17) using TWRP
(cleared cache/dalvik)
rebooted
now i'm stuck in fastboot bootloop….can reboot from fastboot but nothing else
any advice would be appreciated!
update: I am able to get to TWRP using reboot command and holding power and volume down. flashed uninstaller wiped cache/dalvik...rebooted into TWRP long way and then installed 17....still fastboot at startup again
Art1mis said:
If patch boot image is getting failed in magisk latest version v17.1 then enable storage permission for magisk app manually in Device/OS setting. Now patch boot image again, It will get patched successfully.
Click to expand...
Click to collapse
many thanks for the tip!!
spent like an hour trying to figure out why my pixel 2 was failing to patch the boot image.
Allowed storage permissions, flashed the patched boot and now im rooted
Hello everybody.
I've read that 18.1 supports 4.2+ so I've tried to install in two MTK6589T devices I've. One running 4.2, the other running 4.4
CMW/TWRP gave an error mounting system, so I mounted system manually and it started flashing. Firstly it detected old root installed and disabled the old root. But when it tried to find the boot, installation was aborted because installator claims cannot find the boot on both phones.
Then I though, okay, lets reboot back to android, I will try to install a few days later, maybe its buggy now, but both phones cannot boot.
I can easily fix them by flashing rom again I guess, but I would like to know where's the issue and also post it for more people could face the same problem.
Any idea where's the problem/how to fix without rom reflashing? I've tried magisk uninstaller but after mounting system in recovery it is also giving error.
Thanks
UPDATE: For now, if no other solution is found, bootloop can be bypassed by dirty installing the rom again. But it has to be an easier workaround...
We know now that the problem is caused because of two factors merging:
1- Using Magisk.zip installer through custom recovery
2-In the case that the custom recovery CMW/TWRP installed in the phone is very old (for instance, CMW automade for MTK6589X or TWRP 2.5.0).
While installing, Magisk tries to send commands to the custom recovery that cant be understood by it, leaving the installation incomplete after some modifications in /system (read below recovery log).
Acording to the recovery, it seems that Magisk did some modifications without running correctly survival script - Adding addon.d survival script ("Unrecognized option '-Xnodex2oat'") and .zip installer is not designed to revert actions in this case.
Also, Magisk couldn't reach the boot modification step, so boot is not damaged, therefore workarounds for restoring boot won't work.
Using Magisk Unistaller.zip is also not possible as the uninstaller is mainly designed for boot backup restoration, and again, this is not the case.
Currently needed: Find what's wrong in system due to the incomplete Magisk installation to revert it back to the original state (before faulty magisk.zip installation).
Recovery log:
************************
* Magisk v18.1 Installer
************************
- Mounting /system, /vendor
- Target image: /dev/bootimg
- Device platform: arm
- Removing system installed root
- Constructing environment
- Adding addon.d survival script
Unrecognized option '-Xnodex2oat'
up!
I' also having the same problem. My Samsung J2 Prime stuck at logo after updating to 18.1. Any tips on how to fix it without resetting my phone? Thanks.
Update: Bootloop fixed. I used TWRP to restore boot image. I then update Magisk by flashing zip file from TWRP. Everything went back to normal. Hope this help.
trol_sg said:
Hello everybody.
I've read that 18.1 supports 4.2+ so I've tried to install in two MTK6589T devices I've. One running 4.2, the other running 4.4
CMW/TWRP gave an error mounting system, so I mounted system manually and it started flashing. Firstly it detected old root installed and disabled the old root. But when it tried to find the boot, installation was aborted because installator claims cannot find the boot on both phones.
Then I though, okay, lets reboot back to android, I will try to install a few days later, maybe its buggy now, but both phones cannot boot.
I can easily fix them by flashing rom again I guess, but I would like to know where's the issue and also post it for more people could face the same problem.
Any idea where's the problem/how to fix without rom reflashing? I've tried magisk uninstaller but after mounting system in recovery it is also giving error.
Thanks
Click to expand...
Click to collapse
If you have a backup of your boot image, you can just restore it using TWRP. But in case that you have no backup of boot image, you can try to get boot image from the internet and restoring using it. In my case, this is what I did.
1. Go to TWRP and then make backup of boot image of the faulty phone*. (Folder 1)
2. I used another J2 prime to create a boot image backup. (Folder 2)
3. Once that is done, copy and replace the files inside the Folder 2 into Folder 1.
4. Reboot to TWRP again then use that to restore the boot image on my stuck J2.
Tips: make backup in SD card so you can easily swap it in between the bad and good phone.
*This is to create a folder of the backup file. I did tried to directly copy and paste the backup boot image file from another good phone but TWRP didn't detect it. So this is the workaround that I come with. And it worked for me.
Thanks for your answer but I doubt your case is mine. Your device is much newer than mine and according to your comment, you've sucesfully installed previous version of Magisk without issues. This is not a problem while updating, as Magisk v. earlier than 18.1 was not compatible with android 4.2+. I think Magisk is not compatible with MT6589T even if they run 4.2 or 4.4.
I think that it cannot be a boot problem as TWRP/CWM displayed msg 'Boot cannot be found' while installing Magisk, so that I don't think boot was replaced or modified in any ways. Moreover, the bootloop is not in the boot loading, as phone can pass boot image without any problem, but it is stuck in android loading image. I'm thinking in some script or root modification that Magisk did before trying to unpack the boot, however I'm not that deep into the Magisk install to find the proper workaround.
I can restore boot backup and also I can take boot file from the original rom and flash, because in Mediatek-based devices, boot.img is inside de zip, but I dont think it will solve the problem. Anyhow I'll get back ASAP with the answer.
Any more ideas??
Nothing, boot/uboot restoration or flashing again just the boot won't fix the problem, so it's something that Magisk installator touch in /system or /data I guess, but what?
trol_sg said:
Nothing, boot/uboot restoration or flashing again just the boot won't fix the problem, so it's something that Magisk installator touch in /system or /data I guess, but what?
Click to expand...
Click to collapse
Have you read/tried this?
didgeridoohan(dot)com/magisk/MagiskIssues
Ato09 said:
Have you read/tried this?
didgeridoohan(dot)com/magisk/MagiskIssues
Click to expand...
Click to collapse
Yes, I've read them before I made the post. I've also looked for a solution in some of the threads and using search, but couldn't find a way.
Here I attach recovery.log if someone is interested to see the detailed problem.
Also, here below I attach the lines concerning the installation. All other is uninstallation tries and so on:
************************
* Magisk v18.1 Installer
************************
- Mounting /system, /vendor
- Target image: /dev/bootimg
- Device platform: arm
- Removing system installed root
- Constructing environment
- Adding addon.d survival script
Unrecognized option '-Xnodex2oat'
dalvikvm: [options] class [argument ...]
dalvikvm: [options] -jar file.jar [argument ...]
The following standard options are recognized:
-classpath classpath
-Dproperty=value
-verbose:tag ('gc', 'jni', or 'class')
-ea[:<package name>... |:<class name>]
-da[:<package name>... |:<class name>]
(-enableassertions, -disableassertions)
-esa
-dsa
(-enablesystemassertions, -disablesystemassertions)
-showversion
-help
The following extended options are recognized:
-Xrunjdwp:<options>
-Xbootclasspath:bootclasspath
-Xcheck:tag (e.g. 'jni')
-XmsN (min heap, must be multiple of 1K, >= 1MB)
-XmxN (max heap, must be multiple of 1K, >= 2MB)
-XssN (stack size, >= 1KB, <= 256KB)
-Xverify:{none,remote,all}
-Xrs
-Xint (extended to accept 'ortable', ':fast' and ':jit')
These are unique to Dalvik:
-Xzygote
-Xdexopt:{none,verified,all,full}
-Xnoquithandler
-Xjniopts:{warnonly,forcecopy}
-Xjnitrace:substring (eg NativeClass or nativeMethod)
-Xstacktracefile:<filename>
-Xgc:[no]precise
-Xgc:[no]preverify
-Xgc:[no]postverify
-Xgc:[no]concurrent
-Xgc:[no]verifycardtable
-XX:+DisableExplicitGC
-X[no]genregmap
-Xverifyopt:[no]checkmon
-Xcheckdexsum
-Xincludeselectedop
-Xjitop:hexopvalue[-endvalue][,hexopvalue[-endvalue]]*
-Xincludeselectedmethod
-Xjitthreshold:decimalvalue
-Xjitcodecachesize:decimalvalueofkbytes
-Xjitblocking
-Xjitmethod:signature[,signature]* (eg Ljava/lang/String\;replace)
-Xjitclass:classname[,classname]*
-Xjitoffsetffset[,offset]
-Xjitconfig:filename
-Xjitcheckcg
-Xjitverbose
-Xjitprofile
-Xjitdisableopt
-Xjitsuspendpoll
Configured with: debugger profiler hprof jit(armv7-a-neon) smp show_exception=1
Failed to initialize runtime (check log for details)
- Unpacking boot image
MagiskBoot v18.1(18100) (by topjohnwu) - Boot Image Modification Tool
Parsing boot image: [/dev/bootimg]
No boot image magic found!
! Unable to unpack boot image
- Unmounting partitions
E:Error executing updater binary in zip '/sdcard/Magisk-v18.1.zip'
Error flashing zip '/sdcard/Magisk-v18.1.zip'
@trol_sg I'm gonna guess it's got to do with the absolutely ancient TWRP you're using. It just can't handle everything that the Magisk installation script is trying to do...
Your best bet (if Magisk will work at all on your device) is to patch the boot image with the Magisk Manager and then flash the patched image manually. There are new and shiny installation instructions available here: https://topjohnwu.github.io/Magisk/
Didgeridoohan said:
@trol_sg I'm gonna guess it's got to do with the absolutely ancient TWRP you're using. It just can't handle everything that the Magisk installation script is trying to do...
Your best bet (if Magisk will work at all on your device) is to patch the boot image with the Magisk Manager and then flash the patched image manually. There are new and shiny installation instructions available here: https://topjohnwu.github.io/Magisk/
Click to expand...
Click to collapse
Thank you so much for your answer. So it's the recovery, but can't find newer ones, sadly. Too old phones I know, but just curious if I could make Magisk working on them, lol.
I was going into the boot modification manually right now, but in order to patch the boot I need manager installed first, and phone couldn't boot so I did dirty flash of the rom to be able to boot into it again.
Lets see what happens then. I'll be right back.
Anyhow, this is not a solution to fix the problem of bootloop that I am requesting help in case someone could face the same and did not make a backup of the phone and didn't want to make dirty re-flash. Any idea?
Update: After I did dirty flash of the rom, and now Jiayu g3s android 4.4 booted.
UPDATE: So, after patching manually boot and installing (using restore in TWRP 2.5 as image flash is not yet implemented AFAIK), phone booted and yes Magisk is working.
Magisk installation .zip through a very old recovery is making the bootloop. So that, a thing learnt now.
But, for other people facing this bootloop, can we do a research to find what magisk.zip did to the phones to leave them in bootloop? Maybe we can revert without rom flashing easily if we knew what's the issue...
Thanks in advance!
Doing a bit more tests I found that magisk.zip did something in /system so that it is left in bootloop, but still no idea why/whats causing that...
There are delay complete boot like 4 5 second in j7 prime. I didn't love this version
any more help?? up!!
trol_sg said:
Yes, I've read them before I made the post. I've also looked for a solution in some of the threads and using search, but couldn't find a way.
Click to expand...
Click to collapse
Try this.
Quote:
Originally Posted by void74
I faced this problem too this morning.
I have a Redmi Note 5 with AOSiP ROM, I don't know if it's the right way to do it, but I solved the bootloop problem this way:
- volume up and then boot to TWRP
- copied magisk uninstall to phone memory
- installed magisk uninstall
- rebooted in fastboot/bootloader mode
- flashed original boot.img extracted from stock image zip file ("fastboot flash boot boot.img")
- rebooted to TWRP
- installed magisk 17.0 zip file
- rebooted to system, all OK!
Only problem is that I lost previous magisk configuration, but it's a snap to reconfigure it!
Quote:
Originally Posted by Mangraviti
Here is what to do, if you HAVE NOT installed the new version:
1) Do not update via Magisk Manager.
2) Do not update via TWRP using the zip you can download via Magisk Manager.
3) Uninstall Magisk using Magisk uninstaller (ZIP).
4) Boot to Android.
5) Reboot to TWRP
6) Install V17 ZIP via TWRP and boot to Android.
If you HAVE INSTALLED and got a bootloop:
1) Download the uninstaller ZIP.
2) Enter TWRP during the bootloop.
3) Uninstall using the uninstaller ZIP.
4) Boot to Android.
5) Download V17.
6) Reboot to TWRP and flash the V17.
7) Boot to Android it it should be working.
-------------
Original post. https://forum.xda-developers.com/apps/magisk/bootloop-magisk-update-t3836904
Hope it help.
Ato09 said:
Try this.
Quote:
Originally Posted by void74
I faced this problem too this morning.
I have a Redmi Note 5 with AOSiP ROM, I don't know if it's the right way to do it, but I solved the bootloop problem this way:
- volume up and then boot to TWRP
- copied magisk uninstall to phone memory
- installed magisk uninstall
- rebooted in fastboot/bootloader mode
- flashed original boot.img extracted from stock image zip file ("fastboot flash boot boot.img")
- rebooted to TWRP
- installed magisk 17.0 zip file
- rebooted to system, all OK!
Only problem is that I lost previous magisk configuration, but it's a snap to reconfigure it!
Quote:
Originally Posted by Mangraviti
Here is what to do, if you HAVE NOT installed the new version:
1) Do not update via Magisk Manager.
2) Do not update via TWRP using the zip you can download via Magisk Manager.
3) Uninstall Magisk using Magisk uninstaller (ZIP).
4) Boot to Android.
5) Reboot to TWRP
6) Install V17 ZIP via TWRP and boot to Android.
If you HAVE INSTALLED and got a bootloop:
1) Download the uninstaller ZIP.
2) Enter TWRP during the bootloop.
3) Uninstall using the uninstaller ZIP.
4) Boot to Android.
5) Download V17.
6) Reboot to TWRP and flash the V17.
7) Boot to Android it it should be working.
-------------
Original post. https://forum.xda-developers.com/apps/magisk/bootloop-magisk-update-t3836904
Hope it help.
Click to expand...
Click to collapse
Hello, thanks
This method won't work in my case as in the step:
- installed magisk uninstall = gives error
Note 5 is much newer phone with a recent recovery TWRP that allows all Magisk.zips commands, but unluckyly not this case.
Also, this method is for wrong boot installation/damaged boot. In my case what Magisk damage is /system, not boot.
I wish it could be boot, because that is very easy to fix (flashing through fastboot/SP Flash tools in the case of MTK, recovering boot twrp "backup" even if you didn't make backup...) as you mentioned.
Hope someone have a great idea to revert system to origin, then we could post the solution for those who would like to install Magisk in 4.2+ old phones, and instead of doing boot flash manually, they try to flash magisk.zip and they got bootloop.
Main post updated with all thread information. Up!
Nothing?? Up!!
trol_sg said:
Hope someone have a great idea to revert system to origin, then we could post the solution for those who would like to install Magisk in 4.2+ old phones, and instead of doing boot flash manually, they try to flash magisk.zip and they got bootloop.
Click to expand...
Click to collapse
The only part of the Magisk installation that actually touches /system is if it installs the addon.d survival script. The log you posted earlier shows that it's trying to do this, for some reason, and failiing. I'd start looking there...
Hi,
my Samsung GT-I9001 runs with LineageOS 14.1 (Nougat 7.1.2):
https://forum.xda-developers.com/ga...opment/i9001-lineageos-galaxy-s-plus-t3793783
As recovery TWRP 2.8.1.0 (F2FS-support) is installed.
Wenn trying to install Magisk 19.3 using magisk-v19.3.zip via TWRP it does not work: Error message ""Error execute updater binary in zip" and no flash is done.
Any idea what is the reason? The TWRP 2.8.1.0 is the latest version I found for the I9001.
The I tried patching the stock-bootloader via the Magisk-Manager. The bootloader-file is a .tar-file, e.g. in
https://forum.xda-developers.com/showpost.php?p=24831012&postcount=1330.
Magisk works with .tar, too, but seems to exspect an .img-file inside. But inside the I9001-"Boot_loader.tar" is no .img-file but 3 .mbn-files and 1 .bin-file.
So I am asking for help. Is there no way using Magisk with the I9001 (and LineageOS 14.1/TWRP)?
You're not supposed to use the bootloader, but the boot image. Two very different parts of the system setup...
And since you have such an old TWRP you're going to have to use the patching method, but it is very far from certain that your device is compatible. Only way to know is to try though.
Oops. Sorry, my mistake. I am a newbie with this and until I was not aware of boot.img ... I supposed it as the "real" filename of the bootloader. And again learning something new. Thank a lot for teaching.
Fortunately I have made a backup of the stock-ROM with TWRP before flashing the ROM. In the backup I find the file boot.emmc.win. This seems to be the stock-boot.img. Is it corrcect that I only have to rename the file to boot.img?
If the I9001 is not compatible with Magisk, means patching of the boot.img would result in a not working code/boot.img (the patching-procedure itself worked w/o errors, but does thos mean, that the result is o.k.?) - is the real risk bricking the device?
That should be the boot image and it should work fine by just renaming it. But, if it's the boot image from the stock Samsung system it won't work with LineageOS. You'll find the boot image for the ROM inside the ROM zip.
If the boot image is incompatible the Manager will let you know by an error message. Save the installation log if that happens and it could possibly tell you in more detail what went wrong.
If everything goes smoothly and the Manager manages to patch the file without issue and you still end up not being able to boot your device after flashing it you can simply restore the unpatched boot image and everything will be back to normal again.
Thanks for the further explanations. But I am not sure understanding correct.
In my understanding of the Magisk-installation manual I have to use the original boot.img always, in every case.
Do I understand correct that this understanding is wrong and that I have to use for patching with the Magisk-Manager the specific boot.img of the actual running OS? So I have to extract the boot.img of the lineageos-14.1-.tar-file (or rename the boot.emmc.win from one of my later backups of the lineagos-14.1-system)?
I have tested patching meanwhile with the "original" boot.img from the old ("original") backup and also with a boot.img extracted from a complete stock-ROM I have found in the web. Magisk Manager patched both fles w/o problems.
btw: Need the patched file the name "boot.img" or doesn´t matter the ame of the patched file (when flashing with fastboot or Odin)?
Unfortunately - or fortunately - I was not able to flash the patched boot.img to the i9001:
adb can communicate with the i9001 when it is running normal (USB debug enabled) and attached via USB. But although Odin is realizing the i9001 attached in download-mode (what means that the USB-cable is working and the driver are installed) fastboot does not realize the i9001 attached in download-mode. I have tested a lot of cables, ports and USB-drivers - no success.
So I tried to flash the boot.img with Odin. For this the boot.img must be converted to a .tar- (or .tar.md5-)file. When searching for converting-tools I found the explanation how to change the output-format of the patched boot.img in Magisk-Manager to .tar. Unfortunately I do not find this option in the current/latest version of Magisk-Manager. What is wrong - is there a secret, a hidden way to activate this option or is this option available in older versions of Magisk Manager only - and if so can I use an older version only for patching and getting a .tar-boot-image-file?
What the documentation is talking about is indeed the untouched boot image of your currently running OS. Don't mix and match.
When flashing with Odin the image indeed need to be in tar-format. With the current Manager there is no option to change the output format because the Manager will take care of that itself. Feed it a tar file and it'll output a tar file. Unfortunately you'll likely get plain image files from the TWRP backups, so those files will be no good unless you convert them before patching.
But, you might not have to use Odin since you have TWRP. It can flash the patched boot image for you. No computer required...
Again thanks a lot for this teaching. I am a newbie in modifying, tuning, flashing smartphones, and although I have learned a lot in the last weeks there are yet a lot of thing I do not know.
I know that I can flash new OS as .zip-file with TWRP (and other files if the manual says that I have/can do it with TWRP ) but I did not know that I can flash with TWRP a boot.img-file. So I would like to ask for a brief guide how to do this. Or is this the same procedure as flashing any .zip-file?
Addition 1: TWRP 2.8.1.0 does not see/list the .img-Files ....
O.k., found in the web: Directly flashing .img: Version 2.8.4.0 and above ....
So I am back again where I started ... fastboot does not see the i9001 and Odin needs a .tar ...
Addition 2: In reg. of the boot.img of the actual used OS:
I have looked into the "original" flashed lineage-14.1-20180523-UNOFFICIAL-ariesve.zip and found the boot.img. But this boot.img is smaller (4.670 byte) than the boot.emmc.win of it´s backup (5.120 byte). In fact every boot.emmc.win of every TWRP-backup (doesn´t matter what OS I have tested) ist 5.120 bytes and larger than the boot.img of the .tar/.zip-file for flashing (different sizes). So if the files are not identical - how can just simply renaming the boot.emmc.win in boot.img result in a valid boot.img?
It's practically the same thing. You just have to switch to "Image" after choosing the install option and then pick what partition to flash to after selecting the file.
Didgeridoohan said:
It's practically the same thing. You just have to switch to "Image" after choosing the install option and then pick what partition to flash to after selecting the file.
Click to expand...
Click to collapse
But not in version 2.8.1.0 - and there is no newer TWRP for the i9001.
MarkFalk said:
But not in version 2.8.1.0 - and there is no newer TWRP for the i9001.
Click to expand...
Click to collapse
Yes. I'm going to forcefully introduce my palm to my face for a moment... Forgot about that tiny but crucial detail.
Just use the boot image file from the LineageOS zip. Patch it and flash the patched image to your device. If you can't get that working I'm going to have to hand this over to someone else, because I have practically zero knowledge on working with Samsung devices and their shenanigans.
Thanks. The small detail of "flashing" into the i9001 is the remaining problem.
As said fastboot does not see the i9001 in it´s download-mode although Odin sees the device and can flash e.g. the bootloader. Odin on the other hand needs a .tar-file and I do not find a way how to converting the (patched) boot.img into a .tar-file that Odin would accept as valid file.
In these cases I usually ask someone like @jenslody or @ianmacd. They usually have a lot more knowledge about Samsung stuff...
I have found a workaround:
1. Make a pure boot-backup with TWRP
2. Copy the backup-folder into/with a new name
3. Copy boot.emmc.win and boot.emmc.win.md5 from the backup to pc or root
4. Rename boot.emmc.win to boot.img
5. Patch boot.img with Magisk-Manager
6. Rename the result to boot.emmc.win
7. Copy boot.emmc.win to the new backup-folder
8. Make a RD5-hash of boot.emmc.win
9. Replace the hash in boot.emmc.win.rd5 with the new hash
10. Copy boot.emmc.win.rd5 to the new backup-folder
11. Boot into TWRP and restore boot from the new folder
It works with the i9001 and lineageOS14.1 and TWRP 2.8.1.0 and the newest Magisk, but it should work with all devices.