yashsingh1/xdaforums huggingface dataset:
[Android Q&A, Help & Troubleshooting] gintama_me:
I have tried Magisk+Manager_v7.0.0.apk. After start, it checks update and then all icons disappear and the screen starts blinking slowly and smoothly. But I can hold power button and able to see power-off and reboot buttons. All above happens if wi-fi is up. If I turn off wi-fi it works normal but can't download Magisk to install.
[Android Q&A, Help & Troubleshooting] osm0sis:
Why do you think the Magisk zip would suddenly start working? We had to manually patch because it didn't recognize your ramdisk.img format. That's not going to magically stop happening.

The contents of your init.rc and /sbin suggest the ramdisk-uboot-magisk_patched.img flash with cat did not work. Both should have Magisk visible in them.

I would try to dd the patched ramdisk to the partition from TWRP recovery terminal.

Try flashing this Magisk zip from recovery: https://github.com/topjohnwu/magisk_files/blob/master/canary_builds/magisk-debug.zip. It will fail, but that's fine since we just want to clean up SuperSU.

Then:

`dd if=/dev/zero of=/dev/block/platform/15540000.dwmmc0/by-name/ramdisk`

And:

`dd if=ramdisk-uboot-magisk_patched.img of=/dev/block/platform/15540000.dwmmc0/by-name/ramdisk`

Also uninstall all Magisk Manager apps and install the latest Canary apk like I told you: https://github.com/topjohnwu/magisk_files/blob/master/canary_builds/app-debug.apk
[Android Q&A, Help & Troubleshooting] gintama_me:
[1]

done

[2]

done (it deletes SuperSU binary but doesn't delete SuperSU-App)

[3]Then:

`dd if=/dev/zero of=/dev/block/platform/15540000.dwmmc0/by-name/ramdisk`

`dd if=ramdisk-uboot-magisk_patched.img of=/dev/block/platform/15540000.dwmmc0/by-name/ramdisk`

done

seems doesn't work

in log I renamed ramdisk-uboot-magisk_patched.img to ramdisk-p.img

log attached
[Android Q&A, Help & Troubleshooting] osm0sis:
So same problem in recovery as when booted. Maybe your TWRP has selinux problems.. try `setenforce 0` and then try dd again, both booted and in recovery terminal.

If that doesn't work then give me `ls -alR /sys/block/mmcblk0p23`
[Android Q&A, Help & Troubleshooting] gintama_me:
Wait. I am going to do that. But I wanted to ask. I'd like do all stuff with adb. I can't connect to shell via adb in TWRP until mount /system manually. After mount I can use shell via adb on my PC. But command su doesn't give me root user. I have busy box installed. Can I launch some another command to get root under TWRP via adb ?
[Android Q&A, Help & Troubleshooting] osm0sis:
You say they're done. Did `setenforce 0` do anything? Did the dd command work or is it still "operation not permitted"?

Maybe `setenforce 0` will help that too. `adb root` on your PC might also help. Check the adb command help.
[Android Q&A, Help & Troubleshooting] gintama_me:
here is a log
[Android Q&A, Help & Troubleshooting] osm0sis:
Best way to know if setenforce worked is to type getenforce

If getenforce shows Permissive then you should try the dd commands again.
[Android Q&A, Help & Troubleshooting] gintama_me:
or

??
[Android Q&A, Help & Troubleshooting] osm0sis:
I repeat: Best way to know if setenforce worked is to type getenforce.

In the time it took to ask me this and get a response you could have tried it already and figured out I know what I'm saying.
[Android Q&A, Help & Troubleshooting] gintama_me:
Sorry.

Ander Android

127|root@mx4pro:/ # getenforce
Permissive
root@mx4pro:/ #

Under TWRP the answer is the same
[Android Q&A, Help & Troubleshooting] gintama_me:
TWRP log

I:operation_start: 'CommandOutput'
/ # getenforce
I:Actual command is: 'cd "/" && getenforce 2>&1'
Permissive
I:TWFunc::Set_Brightness: Setting brightness control to 5
I:TWFunc::Set_Brightness: Setting brightness control to 0
I:TWFunc::Set_Brightness: Setting brightness control to 1680
I:Set overlay: ''
I:operation_start: 'CommandOutput'
/ # ls -alR /sys/block/mmcblk0p23
I:Actual command is: 'cd "/" && ls -alR /sys/block/mmcblk0p23 2>&1'
/sys/block/mmcblk0p23: No such file or directory
I:operation_start: 'CommandOutput'
/ # ls -alR /dev/block/mmcblk0p23
I:Actual command is: 'cd "/" && ls -alR /dev/block/mmcblk0p23 2>&1'
brw------- root root 259, 2 2019-05-01 15:31 mmcblk0p23
[Android Q&A, Help & Troubleshooting] osm0sis:
What about dd? I told you to dd again if it says Permissive.

Also, give me from a root prompt: `ls -al /sys/block`
[Android Q&A, Help & Troubleshooting] gintama_me:
under android

1|root@mx4pro:/ # setenforce 0
root@mx4pro:/ # getenforce
Permissive
dd if=/sdcard/leo/ramdisk-uboot-magisk_patched.img of=/dev/block/mmcblk0p23
dd: /dev/block/mmcblk0p23: Operation not permitted
1+0 records in
0+0 records out
0 bytes transferred in 0.003 secs (0 bytes/sec)
1|root@mx4pro:/ #

1|root@mx4pro:/ # ls -al /sys/block
lrwxrwxrwx root root 2019-05-01 15:41 loop0 -> ../devices/virtual/block/loop0
lrwxrwxrwx root root 2019-05-01 15:41 loop1 -> ../devices/virtual/block/loop1
lrwxrwxrwx root root 2019-05-01 15:41 loop2 -> ../devices/virtual/block/loop2
lrwxrwxrwx root root 2019-05-01 15:41 loop3 -> ../devices/virtual/block/loop3
lrwxrwxrwx root root 2019-05-01 15:41 loop4 -> ../devices/virtual/block/loop4
lrwxrwxrwx root root 2019-05-01 15:41 loop5 -> ../devices/virtual/block/loop5
lrwxrwxrwx root root 2019-05-01 15:41 loop6 -> ../devices/virtual/block/loop6
lrwxrwxrwx root root 2019-05-01 15:41 loop7 -> ../devices/virtual/block/loop7
lrwxrwxrwx root root 2019-05-01 15:41 mmcblk0 -> ../devices/15540000.dwmmc0/mmc_host/mmc0/mmc0:0001/block/mmcblk0
lrwxrwxrwx root root 2019-05-01 15:41 ram0 -> ../devices/virtual/block/ram0
lrwxrwxrwx root root 2019-05-01 15:41 ram1 -> ../devices/virtual/block/ram1
lrwxrwxrwx root root 2019-05-01 15:41 ram10 -> ../devices/virtual/block/ram10
lrwxrwxrwx root root 2019-05-01 15:41 ram11 -> ../devices/virtual/block/ram11
lrwxrwxrwx root root 2019-05-01 15:41 ram12 -> ../devices/virtual/block/ram12
lrwxrwxrwx root root 2019-05-01 15:41 ram13 -> ../devices/virtual/block/ram13
lrwxrwxrwx root root 2019-05-01 15:41 ram14 -> ../devices/virtual/block/ram14
lrwxrwxrwx root root 2019-05-01 15:41 ram15 -> ../devices/virtual/block/ram15
lrwxrwxrwx root root 2019-05-01 15:41 ram2 -> ../devices/virtual/block/ram2
lrwxrwxrwx root root 2019-05-01 15:41 ram3 -> ../devices/virtual/block/ram3
lrwxrwxrwx root root 2019-05-01 15:41 ram4 -> ../devices/virtual/block/ram4
lrwxrwxrwx root root 2019-05-01 15:41 ram5 -> ../devices/virtual/block/ram5
lrwxrwxrwx root root 2019-05-01 15:41 ram6 -> ../devices/virtual/block/ram6
lrwxrwxrwx root root 2019-05-01 15:41 ram7 -> ../devices/virtual/block/ram7
lrwxrwxrwx root root 2019-05-01 15:41 ram8 -> ../devices/virtual/block/ram8
lrwxrwxrwx root root 2019-05-01 15:41 ram9 -> ../devices/virtual/block/ram9
root@mx4pro:/ #
[Android Q&A, Help & Troubleshooting] gintama_me:
what if to delete supersu under TWRP and install superSU under twrp at once ?

perhaps flyme os has some protection installed via meizu root permission?
[Android Q&A, Help & Troubleshooting] osm0sis:
Yes. Some things are clearly blocked by Meizu somehow. It's not SELinux however because we just ruled it out.

You would need system SuperSU since your ramdisk image can't be patched, so I'm not sure how the SuperSU installer would behave. Worth a try though.

Now give me `ls -al /sys/block/mmcblk0`
[Android Q&A, Help & Troubleshooting] gintama_me:
root@mx4pro:/ # ls -al /sys/block/mmcblk0
lrwxrwxrwx root root 2019-05-01 15:41 mmcblk0 -> ../devices/15540000.dwmmc0/mmc_host/mmc0/mmc0:0001/block/mmcblk0
[Android Q&A, Help & Troubleshooting] osm0sis:
Hmm..

ls -al /sys/block/mmcblk0/

then. Trailing slash is important.
[Android Q&A, Help & Troubleshooting] gintama_me:
root@mx4pro:/ # ls -al /sys/block/mmcblk0/
-r--r--r-- root root 4096 2019-05-01 16:07 alignment_offset
lrwxrwxrwx root root 2019-05-01 16:07 bdi -> ../../../../../../virtual/bdi/179:0
-r--r--r-- root root 4096 2019-05-01 16:07 capability
-r--r--r-- root root 4096 2019-05-01 16:07 dev
lrwxrwxrwx root root 2019-05-01 16:07 device -> ../../../mmc0:0001
-r--r--r-- root root 4096 2019-05-01 16:07 discard_alignment
-r--r--r-- root root 4096 2019-05-01 16:07 ext_range
-r--r--r-- root root 4096 2019-05-01 16:07 force_ro
drwxr-xr-x root root 2019-05-01 15:41 holders
-r--r--r-- root root 4096 2019-05-01 16:07 inflight
drwxr-xr-x root root 2019-05-01 15:41 mmcblk0p1
drwxr-xr-x root root 2019-05-01 15:41 mmcblk0p2
drwxr-xr-x root root 2019-05-01 15:41 mmcblk0p21
drwxr-xr-x root root 2019-05-01 15:41 mmcblk0p22
drwxr-xr-x root root 2019-05-01 15:41 mmcblk0p23
drwxr-xr-x root root 2019-05-01 15:41 mmcblk0p24
drwxr-xr-x root root 2019-05-01 15:41 mmcblk0p25
drwxr-xr-x root root 2019-05-01 15:41 mmcblk0p26
drwxr-xr-x root root 2019-05-01 15:41 mmcblk0p27
drwxr-xr-x root root 2019-05-01 15:41 mmcblk0p28
drwxr-xr-x root root 2019-05-01 15:41 mmcblk0p29
drwxr-xr-x root root 2019-05-01 15:41 mmcblk0p3
drwxr-xr-x root root 2019-05-01 15:41 mmcblk0p4
drwxr-xr-x root root 2019-05-01 15:41 mmcblk0p41
drwxr-xr-x root root 2019-05-01 15:41 mmcblk0p42
drwxr-xr-x root root 2019-05-01 15:41 mmcblk0p43
drwxr-xr-x root root 2019-05-01 15:41 mmcblk0p44
drwxr-xr-x root root 2019-05-01 15:41 mmcblk0p5
drwxr-xr-x root root 2019-05-01 15:41 power
drwxr-xr-x root root 2019-05-01 15:41 queue
-r--r--r-- root root 4096 2019-05-01 16:07 range
-r--r--r-- root root 4096 2019-05-01 16:07 removable
-r--r--r-- root root 4096 2019-05-01 16:07 ro
-r--r--r-- root root 4096 2019-05-01 16:07 size
drwxr-xr-x root root 2019-05-01 15:41 slaves
-r--r--r-- root root 4096 2019-05-01 16:07 stat
lrwxrwxrwx root root 2019-05-01 16:07 subsystem -> ../../../../../../../class/block
-rw-r--r-- root root 4096 2019-05-01 15:41 uevent
root@mx4pro:/ #
[Android Q&A, Help & Troubleshooting] osm0sis:
F*ck yes! :victory::D

`cat /sys/block/mmcblk0/force_ro`
[Android Q&A, Help & Troubleshooting] gintama_me:
root@mx4pro:/ # cat /sys/block/mmcblk0/force_ro
root@mx4pro:/ # cat /sys/block/mmcblk0/force_ro
root@mx4pro:/ # ls /sys/block/mmcblk0/force_ro
/sys/block/mmcblk0/force_ro
root@mx4pro:/ #

Some partition makes some partitions read only ?
[Android Q&A, Help & Troubleshooting] osm0sis:
Yep! Like I guessed a few pages back. ;)

We can't read the file though, but that doesn't mean it won't accept our input.

`ls -al /sys/block/mmcblk0/mmcblk0p23`

Just so we know what we're dealing with better, then I'll have a possible fix for you.
[Android Q&A, Help & Troubleshooting] gintama_me:
root@mx4pro:/ # ls -al /sys/block/mmcblk0/mmcblk0p23
-r--r--r-- root root 4096 2019-05-01 16:17 alignment_offset
-r--r--r-- root root 4096 2019-05-01 16:17 dev
-r--r--r-- root root 4096 2019-05-01 16:17 discard_alignment
drwxr-xr-x root root 2019-05-01 15:41 holders
-r--r--r-- root root 4096 2019-05-01 16:17 inflight
-r--r--r-- root root 4096 2019-05-01 16:17 partition
drwxr-xr-x root root 2019-05-01 15:41 power
-r--r--r-- root root 4096 2019-05-01 16:17 ro
-r--r--r-- root root 4096 2019-05-01 16:17 size
-r--r--r-- root root 4096 2019-05-01 16:17 start
-r--r--r-- root root 4096 2019-05-01 16:17 stat
lrwxrwxrwx root root 2019-05-01 16:17 subsystem -> ../../../../../../../../class/block
-rw-r--r-- root root 4096 2019-05-01 15:41 uevent
root@mx4pro:/ #

perhaps I need to dd if=/sys/block/mmcblk0/force_ro of=/leo/sdcard/dd_sys_block_mmcblk0_force_ro.img ? And it's better under TWRP I suppose.
[Android Q&A, Help & Troubleshooting] osm0sis:
No. Don't do that. I posted how force_ro works a few pages back, I just didn't know the path on your device, but we do now.

1) Uninstall SuperSU app.

2) Go to TWRP recovery.

3) Flash the Magisk Canary zip to clean up SuperSU root.

4) `setenforce 0` to make sure we're Permissive.

5) `chmod 777 /sys/block/mmcblk0/force_ro` then

6) `echo 0 > /sys/block/mmcblk0/force_ro` to allow writing to your block devices.

7) `dd if=/dev/zero of=/dev/block/platform/15540000.dwmmc0/by-name/ramdisk`

8) `dd if=ramdisk-uboot-magisk_patched.img of=/dev/block/platform/15540000.dwmmc0/by-name/ramdisk`

9) Reboot and cross your fingers.

10) Install Magisk Canary apk.

If it won't boot then go back to recovery and follow the same steps but dd your backup of unrooted ramdisk to fix.
[Android Q&A, Help & Troubleshooting] gintama_me:
1) Uninstall SuperSU app.

went to SuperSU app >settings > full unroot

2) Go to TWRP recovery.

can't go to TWRP recovery after that bc TWRP need root to launch

Without deleting superSU:

/data/media/0/leo # setenforce 0
I:Actual command is: 'cd "/data/media/0/leo" && setenforce 0 2>&1'
I:operation_start: 'CommandOutput'
/data/media/0/leo # getenforce
I:Actual command is: 'cd "/data/media/0/leo" && getenforce 2>&1'
Permissive
Truncating string cache entries.
I:operation_start: 'CommandOutput'
/data/media/0/leo # echo 0 > /sys/block/mmcblk0/force_ro
I:Actual command is: 'cd "/data/media/0/leo" && echo 0 > /sys/block/mmcblk0/force_ro 2>&1'
sh: can't create /sys/block/mmcblk0/force_ro: Permission denied
I:TWFunc::Set_Brightness: Setting brightness control to 5
I:TWFunc::Set_Brightness: Setting brightness control to 0
I:TWFunc::Set_Brightness: Setting brightness control to 1680
I:Set overlay: ''
Truncating string cache entries.
Truncating string cache entries.
I:operation_start: 'CommandOutput'
/data/media/0/leo # dd if=/dev/zero of=/dev/block/platform/15540000.dwmmc0/by-name/ramdisk
I:Actual command is: 'cd "/data/media/0/leo" && dd if=/dev/zero of=/dev/block/platform/15540000.dwmmc0/by-name/ramdisk 2>&1'
dd: writing '/dev/block/platform/15540000.dwmmc0/by-name/ramdisk': Operation not permitted
1+0 records in
0+0 records out
0 bytes (0B) copied, 0.000579 seconds, 0B/s
[Android Q&A, Help & Troubleshooting] osm0sis:
You never explained that TWRP was reliant on SuperSU before, so how was I to know that?

Anyway, try `chmod 777 /sys/block/mmcblk0/force_ro` and `chown root:root /sys/block/mmcblk0/force_ro` then try `echo 0 > /sys/block/mmcblk0/force_ro` again.

If that doesn't work I'm out of ideas and we've gone as far as we can here.

Until you can write 0 to force_ro you won't be able to do any writing to your block partitions.

Good luck!
[Android Q&A, Help & Troubleshooting] gintama_me:
well, I didn't know myself. When SuperSU is installed I could start TWRP both from APK and with volume+power-button. After I have uninstalled supersu I found out I can't use buttons anymore. So sorry about that.

Gonna try.

Thanks a lot, buddy, anyway, really.
[Android Q&A, Help & Troubleshooting] gintama_me:
As far as I can't install supersu and I need reflash firmware I have tried install kingroot

D:\>adb -d shell
shell@mx4pro:/ $ su
root@mx4pro:/ # chmod 777 /sys/block/mmcblk0/force_ro
root@mx4pro:/ # chown root:root /sys/block/mmcblk0/force_ro
root@mx4pro:/ # echo 0 > /sys/block/mmcblk0/force_ro
v/zero of=/dev/block/platform/15540000.dwmmc0/by-name/ramdisk <
dd: /dev/block/platform/15540000.dwmmc0/by-name/ramdisk: No space left on device
16385+0 records in
16384+0 records out
8388608 bytes transferred in 0.655 secs (12807035 bytes/sec)
magisk_patched.img of=/dev/block/platform/15540000.dwmmc0/by-name/ramdisk <
1844+1 records in
1844+1 records out
944425 bytes transferred in 0.287 secs (3290679 bytes/sec)
root@mx4pro:/ #

Dude, seems to me you hacked it :)
[Android Q&A, Help & Troubleshooting] osm0sis:
Sweet! So flash the Magisk Canary zip, reboot and install the Canary Magisk Manager APK and you may hopefully have working Magisk root. :cool:
[Android Q&A, Help & Troubleshooting] gintama_me:
I have tried without rebooting after patching to install canary build and it ends with error.

.

.

.

brick....

f*ck.

after reboot black screen
[Android Q&A, Help & Troubleshooting] osm0sis:
I told you the Magisk installer would never work because it will never be able to handle the ramdisk.img format.

Ah crappy.. either an issue with Magisk or maybe dtb needed to be patched after all.

You'll have to dd your ramdisk.img backup from TWRP to restore it to working order.
[Android Q&A, Help & Troubleshooting] gintama_me:
well, update. I have disassemble the smart and disconnect the battery. After that I could ebter recovery and reflash. Si everything is allright. I am going install king root and after that install TWRP, go there, flash patched ramdisk then install magisk , flash original ramdisk and reboot. How is idea ?
[Android Q&A, Help & Troubleshooting] gintama_me:
my bad :confused:

I can't it's meizu recovery with two buttons. And it's just reflash firmware for 5 mins.
[Android Q&A, Help & Troubleshooting] osm0sis:
Your idea is bad. You still aren't understanding that Magisk's installer will never be able to recognize your ramdisk.img even though I've told you 3 or 4 times.

It's literally why we manually patched it in the first place.

So no, just go dd your unrooted ramdisk partition backup and go back to using SuperSU.
[Android Q&A, Help & Troubleshooting] osm0sis:
Well you'll probably just have to reflash your firmware zip then.
[Android Q&A, Help & Troubleshooting] gintama_me:
Don't you mean I can't install Magisk under Magisk Manager ?

And doesn't your suggestion mean to install canary_magisk-release.zip under TWRP ?
[Android Q&A, Help & Troubleshooting] osm0sis:
Yeah I told you before, you were just flashing it so it will clean up SuperSU. The zip will not fully work in any form, from anywhere, ever. Manually patching was your only hope and we tried it and it didn't work.

Perhaps manually patching dtb might get it working (it's the only thing we left out), but I don't have experience unpacking dtbs and editing them by hand so I can't help you there.
[Android Q&A, Help & Troubleshooting] gintama_me:
Do you mean patching ramdisk wasn't for making an ability to install Magisk but patching ramdisk it is actually installing the core of Magisk itself?

If so , then:

flash the Magisk Canary zip

- did you mean magisk-debug.zip or magisk-release.zip ? Cause I thought magisk-debug.zip is for root deleting and magisk-release.zip it is a core of Magisk
[Android Q&A, Help & Troubleshooting] osm0sis:
Maybe go read back in the thread. I've explained all this before. I told you to use debug and yes we put the core of Magisk into the ramdisk. I've told you this 5 times now.

debug is canary with debug logging enabled. release is canary with debug logging disabled. It's otherwise the exact same zip.
[Android Q&A, Help & Troubleshooting] gintama_me:
What about custom ROMs ? Is there a chance Magisk will work ?
[Android Q&A, Help & Troubleshooting] osm0sis:
Not if it uses the same ramdisk.img, which it probably does.

Anyway, look into patching the dtb by hand, that's your only hope to get my patched ramdisk.img to boot on your device.

I've helped you all I can. If you have any more questions reread this thread, since I've probably already answered them a few times for you.

Good luck!
[Android Q&A, Help & Troubleshooting] gintama_me:
Sorry if I was annoying. Perhaps my English is really poor (

Anyway thanks a lot, man. :good:
[Android Q&A, Help & Troubleshooting] osm0sis:
I got [MENTION=4470081]topjohnwu[/MENTION] to take a look at your dtb and he tells me it doesn't have any fstab or verity flags in it, so sadly that probably rules it out as an easy fix to the problem.

Next test would be to just try a repack of your ramdisk.img without any modifications, and then with cosmetic changes to see if it'll accept a repack and/or changes at all.

If you want I can help with that. Let me know when you've recovered your device and give me a fresh dump of your current ramdisk partition. :good:
[Android Q&A, Help & Troubleshooting] gintama_me:
It can show whether repacking is working or not.
[Android Q&A, Help & Troubleshooting] osm0sis:
I just want to make sure to start with that we're using the exact ramdisk.img your device expects.
[Android Q&A, Help & Troubleshooting] gintama_me:
is ramdisk from firmware counted ?
[Android Q&A, Help & Troubleshooting] gintama_me:
I have recovered my device
[Android Q&A, Help & Troubleshooting] osm0sis:
If this is the firmware you recovered from, yes. I'd still prefer a dd dump just to be certain however.
[Android Q&A, Help & Troubleshooting] gintama_me:
yes. that was ramdisk from firmware zip.

dd if=/dev/block/mmcblk0p23 of=/sdcard/dd_ramdisk.img
[Android Q&A, Help & Troubleshooting] osm0sis:
Okay perfect. dd_ramdisk.img is identical to ramdisk-uboot.img (except for some unimportant null padding).

I repacked ramdisk-uboot.img with the exact same ramdisk, so just a new U-Boot container for it (should be just the creation timestamp is different). Give it a try and let me know if it boots.

[ Attachment removed ]
[Android Q&A, Help & Troubleshooting] gintama_me:
It's interesting. I can't find out how to use adb with twrp but I have written a small sh script and somehow script gets root user. Looks like typing in TWRP terminal doesn't has root permission as it have to be.

What do you say ?

/data/media/0 # sh data_media.sh
I:Actual command is: 'cd "/data/media/0" && sh data_media.sh 2>&1'
data_media.sh: line 1: ﻿#!/sbin/sh
: not found
usage: setenforce [ Enforcing | Permissive | 1 | 0 ]
data_media.sh: line 3: can't create /sys/block/mmcblk0/force_ro
: nonexistent directory
Truncating string cache entries.
dd: writing '/dev/block/platform/15540000.dwmmc0/by-name/ramdisk
': No space left on device
2851081+0 records in
2851080+0 records out
1459752960 bytes (1.4GB) copied, 19.565943 seconds, 71.2MB/s
1399+1 records in
1399+1 records out
716731 bytes (699.9KB) copied, 0.725352 seconds, 965.0KB/s

looks like under twrp there is no blocking /sys/block/mmcblk0/force_ro

but what the f*ck 1.4 Gb.

it works and should I try patched ramdisk now?
[Android Q&A, Help & Troubleshooting] osm0sis:
I'm not sure that worked... 1.4gb could be you wiping the whole mmcblk0 device. :eek:

Can you do it with the manual steps we know work? I really don't trust all those errors your script is generating.

1) Go to TWRP recovery terminal.

2) `setenforce 0` to make sure we're Permissive.

3) `chmod 777 /sys/block/mmcblk0/force_ro` then

4) `echo 0 > /sys/block/mmcblk0/force_ro` to allow writing to your block devices.

5) `dd if=/dev/zero of=/dev/block/platform/15540000.dwmmc0/by-name/ramdisk`

6) `dd if=ramdisk-orig-repack.img of=/dev/block/platform/15540000.dwmmc0/by-name/ramdisk`

7) Reboot and cross your fingers.
[Android Q&A, Help & Troubleshooting] gintama_me:
did it under kingroot, doesnt boot (

if we only could use adb shell under TWRP with root permissions
[Android Q&A, Help & Troubleshooting] osm0sis:
What didn't boot? ramdisk-orig-repack.img?
[Android Q&A, Help & Troubleshooting] gintama_me:
TWRP shell does not have root permissions as it was before always

So I did all stuff under kingroot in Android. It can't boot after that. The device is recovered again.

I need to do it under TWRP adb shell. But if I use shell under Android via adb I am getting root typing 'su' . The same command doesn't work while using adb shell under TWRP. And I can connect to shell under TWRP if I'd mounted/system manually in TWRP.
[Android Q&A, Help & Troubleshooting] osm0sis:
Okay, so presuming the commands worked like before and you only flashed ramdisk-orig-repack.img and didn't break anything else in the process, then one thing I noticed while doing the repacks is a 256-byte chunk of data on the end, which is unfortunately likely a signature.

We can try the repack with the 256 bytes added and try the complete original ramdisk-uboot.img with the 256 bytes removed, but if both don't work we're definitely out of luck due to signature enforcement.

[ Attachments removed ]
[Android Q&A, Help & Troubleshooting] gintama_me:
Should I do it under king-root in Android or there is a method to get root working under TWRP ADB SHELL ? ?
[Android Q&A, Help & Troubleshooting] osm0sis:
I've never seen a device with TWRP hacked on as a root app like that, so you're the expert on that, not me. Probably something with SuperSU.

Easiest way to test that doing it with KingRoot isn't the problem would be to flash the untouched ramdisk-uboot.img from your firmware zip and see that it still boots fine.

I've just added the repack with the signature to my last post, so those are our last 2 attempts. If neither of those work you're out of options.