Error opening operation not permitted twrp - Исправление ошибок и поиск оптимальных решений проблем

I need some advice and or possibly an explanation on what I did wrong and if possibly some solution. I had some errors in TWRP after the latest weekly (20.12.09) installation (Cannot read.., Operation not permitted) but the decryption was working as usual -in Official TWRP 3.4.0-1. I decided to format data and install the ROM a new.
Installed, set up and restored data, but when I went to TWRP to check if the errors are gone it did not ask me for a decryption key and data is encrypted. Tried manually entering the pin number but it says decryption failed.
The ROM is still working I am accessing it fine with the PIN, I tried changing to pattern, tried formatting data again with the same results TWRP doesn’t ask for decryption. And the errors are still there.
Any suggestions on how to handle it?
Thank you in advance.

Same problem. I also can’t install any custom kernel and I guess it’s related to this issue. I tried different recoveries and no luck. I hope someone will help us.

Same problem . I tried fastboot to flash the latest version of recovery, but this problem still exists.

Last edited: Jan 14, 2021

Same problem . I tried fastboot to flash the latest version of recovery, but this problem still exists. I tried the official Chinese version and everything is normal. It seems to be a problem with the xiaomi.eu version.

Can you send the link of the official chinese twrp?

I solved the issue by permanently disabling Force Encryption. I erased /data using fastboot (fastboot erase userdata) then I formatted it again in TWRP. After that, I flashed the rom and lastly, I flashed the zip that will disable the force encryption.

Here’s the link of the zip:

I need some advice and or possibly an explanation on what I did wrong and if possibly some solution. I had some errors in TWRP after the latest weekly (20.12.09) installation (Cannot read.., Operation not permitted) but the decryption was working as usual -in Official TWRP 3.4.0-1. I decided to format data and install the ROM a new.
Installed, set up and restored data, but when I went to TWRP to check if the errors are gone it did not ask me for a decryption key and data is encrypted. Tried manually entering the pin number but it says decryption failed.
The ROM is still working I am accessing it fine with the PIN, I tried changing to pattern, tried formatting data again with the same results TWRP doesn’t ask for decryption. And the errors are still there.
Any suggestions on how to handle it?
Thank you in advance.

I had me too. I had to format the date and reinstall the firmware. But all the same, the phone slows down and everything is buggy. Not strong, but tangible

Same issue here after updating Xiaomi.EU MIUI from 20.11.11 to 20.12. Any advice?

Can you send the link of the official chinese twrp?

Sorry，I mean the latest Chinese version of ROM 20.12.02, not TWRP… I gave up and flashed the old version 20.11.25.

Last edited: Jan 14, 2021

From what I can tell, IF you flash the latest eu ROM (20.12.09) decryption in TWRP works…partially but the «format data» command does not work. AT ALL. The only way to make it work is flash a previous ROM first, then do a format data (possibly a ‘fastboot erase userdata’ as well). Reason is unknown at the moment.

Moreover, the ONLY way I see for someone to rollback to a previous ROM (other than 20.12.09) successfully, is to flash it, then format data (it should now work), then restore /data partition from a nandroid taken prior to flashing the 20.12.09, then possibly re-flashing the ROM again (if system doesn’t boot to MIUI).

FYI flashing the latest China ROM (20.12.09) produces the exact same results when it comes to TWRP decryption, meaning the issue is not eu related. Xiaomi clearly did *something* that prevents TWRP from locating the device user keys (usually located in data/misc/…), which is also the reason that TWRP does not ask for a password/PIN after flashing the latest ROM and supposedly formatting data, regardless if you have specified one in MIUI or not. It simply cannot tell if the device is locked or not and whether it should use a key to decrypt the data. Like I said, no one knows why Xiaomi did this. It could be that they are preparing the device for the Android 11 transition or it could be a bug. It’s anyone’s guess right now.

Last edited: Dec 13, 2020

From what I can tell, IF you flash the latest eu ROM (20.12.09) decryption in TWRP works…partially but the «format data» command does not work. AT ALL. The only way to make it work is flash a previous ROM first, then do a format data (possibly a ‘fastboot erase userdata’ as well). Reason is unknown at the moment.

Moreover, the ONLY way I see for someone to rollback to a previous ROM (other than 20.12.09) successfully, is to flash it, then format data (it should now work), then restore /data partition from a nandroid taken prior to flashing the 20.12.09, then possibly re-flashing the ROM again (if system doesn’t boot to MIUI).

FYI flashing the latest China ROM (20.12.09) produces the exact same results when it comes to TWRP decryption, meaning the issue is not eu related. Xiaomi clearly did *something* that prevents TWRP from locating the device user keys (usually located in data/misc/…), which is also the reason that TWRP does not ask for a password/PIN after flashing the latest ROM and supposedly formatting data, regardless if you have specified one in MIUI or not. It simply cannot tell if the device is locked or not and whether it should use a key to decrypt the data. Like I said, no one knows why Xiaomi did this. It could be that they are preparing the device for the Android 11 transition or it could be a bug. It’s anyone’s guess right now.

Thank you for the information. I thought I messed something up and tried everything but to no good. The phone is working fine on this ROM and it will be OK to use as it is until A11 comes out. Hopefully we will know what to do then. While formatting and restoring I found out that Google backup doesn’t work when you have lock enabled, not sure if related.

Same problem here as well with OrangeFox recovery (not surprising since they have the same code base). Can anyone confirm that this issue is device-specific? If not, then Xiaomi is forcing us to bid farewell to MIUI. As a sidenote, as another user has mentioned, performance is not all that great on MIUI 12. It looks like Xiaomi has priotised fancy and taxing animations to the detriment of fluidity and longevity on weaker devices like the RN8.

Same problem here as well with OrangeFox recovery (not surprising since they have the same code base). Can anyone confirm that this issue is device-specific? If not, then Xiaomi is forcing us to bid farewell to MIUI. As a sidenote, as another user has mentioned, performance is not all that great on MIUI 12. It looks like Xiaomi has priotised fancy and taxing animations to the detriment of fluidity and longevity on weaker devices like the RN8.

It also happened to violet, so it’s not device specific

Same problem here as well with OrangeFox recovery (not surprising since they have the same code base). Can anyone confirm that this issue is device-specific? If not, then Xiaomi is forcing us to bid farewell to MIUI. As a sidenote, as another user has mentioned, performance is not all that great on MIUI 12. It looks like Xiaomi has priotised fancy and taxing animations to the detriment of fluidity and longevity on weaker devices like the RN8.

The performance on my RN8 is great, very smooth. But I also tried Orange Fox with the same results.

It also happened to violet, so it’s not device specific

That actually is bad news since someone suggested that the change was due to the migration to A11 and if I am not mistaken violet is not going to be upgraded… So they might have messed something up by mistake or they will be upgrading violet as well.

Mystery solved. The issue with the TWRP on the latest ROM for ginkgo occured due to changes in the boot image. This is also the reason that flashing to a previous ROM (which would obviously write a new boot image) would automatically correct the issue. Xiaomi, in their not so infinite wisdom, saw fit to implement changes in the kernel so that the recovery would not be able to read the decryption keys, at least not without recompiling the kernel. The problem was investigated and fixed over @Xiaomi-miui.gr.

You can try flashing this TWRP: https://www.mediafire.com/file/ma34dbgir2hbnvi/twrp_ginkgo-willow_3.4A9_23-12-2020_BL.img/file

It should work for ROM 20.12.09 (and only this ROM for now).

Hello,

Can someone update the recovery of LR TEAM for begonia?

For QGGEUXM 12.0.3.0 update :

thank you in advance

Hello,

Can someone update the recovery of LR TEAM for begonia?

For QGGEUXM 12.0.3.0 update :

thank you in advance

LR Team didn’t release an update for the begonia TWRP. The one you mentioned above, is the latest TWRP.

is there a TWRP mod for violet too? i just updated from 20.10.30 to latest 20.12.28 and my recovery doesn’t ask the key to decrypt data, so no file is accessible

is there a TWRP mod for violet too? i just updated from 20.10.30 to latest 20.12.28 and my recovery doesn’t ask the key to decrypt data, so no file is accessible

try this recovery twrp_violet_test_01-01-2021
install from fastboot mode
fastboot flash recovery violet01-01-2021test.img
fastboot reboot ( use the volume + button to boot)

try this recovery twrp_violet_test_01-01-2021
install from fastboot mode
fastboot flash recovery violet01-01-2021test.img
fastboot reboot ( use the volume + button to boot)

it’s working, thank you

try this recovery twrp_violet_test_01-01-2021
install from fastboot mode
fastboot flash recovery violet01-01-2021test.img
fastboot reboot ( use the volume + button to boot)

Any tips on what patches you made to get this working?

Thanks very much. But when you say «update kernel», is there anything specific that needs to be enabled (or disabled) in the kernel sources, or just update with MIUI prebuilt kernel?

Many Xiaomi devices suffer from this problem, and it would be great if twrp can easily be updated for all these devices. Thanks,

Mystery solved. The issue with the TWRP on the latest ROM for ginkgo occured due to changes in the boot image. This is also the reason that flashing to a previous ROM (which would obviously write a new boot image) would automatically correct the issue. Xiaomi, in their not so infinite wisdom, saw fit to implement changes in the kernel so that the recovery would not be able to read the decryption keys, at least not without recompiling the kernel. The problem was investigated and fixed over @Xiaomi-miui.gr.

You can try flashing this TWRP: https://www.mediafire.com/file/ma34dbgir2hbnvi/twrp_ginkgo-willow_3.4A9_23-12-2020_BL.img/file

It should work for ROM 20.12.09 (and only this ROM for now).

you are a ****in god, thanks man

Hey friends, I had the same problem when tried to install the latest weekly on RN8 too, any of you are facing the same?

Источник

В этом руководстве мы покажем вам шаги по исправлению невозможности смонтировать хранилище в TWRP Recovery. Экосистема Android, благодаря своей природе с открытым исходным кодом, допускает множество настроек.

Единственное требование — разблокировать загрузчик устройства. Как только вы этого добьетесь, вы сможете запустить множество пользовательских двоичных файлов, модов, пользовательских ПЗУ и даже Magisk для рутирования вашего устройства. Однако стандартное восстановление не может установить эти файлы. Вам нужно будет установить кастомное рекавери, например TWRP.

После того, как ваше устройство загрузится в это восстановление, вы можете стереть различные разделы устройства, выполнить резервное копирование Nandroid и, конечно, прошить вышеупомянутые файлы. Однако несколько раз вы можете столкнуться с ошибкой или двумя.

Среди них самые распространенные и пугающие, похоже, не могут смонтировать ошибку хранилища при отображении TWRP. В этом руководстве мы рассмотрим различные причины этой ошибки, а затем перечислим возможные исправления для исправления этой ошибки. Следуйте.

Первая причина, по-видимому, связана с тем, что внутреннее хранилище вашего устройства зашифровано. В результате TWRP не может расшифровать его на ходу и, следовательно, не может получить доступ к файлам, хранящимся на вашем устройстве.

Это причина, по которой эта ошибка чаще всего возникает, когда вы собираетесь прошить файл с помощью этого восстановления.

В других случаях ваш раздел данных может быть поврежден из-за того, что мигает неправильный файл или файл в неправильном разделе. Во всех этих сценариях ваш TWRP может отображать внутреннее хранилище как имеющее 0 МБ занятого места.

Но не волнуйтесь, это не так, и ваши данные на данный момент могут быть все еще нетронутыми. Итак, с учетом сказанного, вот различные методы исправления невозможности монтировать хранилище в TWRP Recovery.

Как исправить невозможность смонтировать хранилище в TWRP Recovery

Мы поделимся тремя разными способами решения этой проблемы. Следуйте инструкциям в том же порядке, как указано. Просто убедитесь, что ваше устройство уже загружено в TWRP. Е

Исправление 1: удалить экран блокировки

Если вы используете графический ключ на своем устройстве, TWRP не сможет его расшифровать. Рекомендуется переключиться на пин-код или пароль.

Для этого, если вы загружены в TWRP, перезагрузите устройство в Системе.
После загрузки перейдите в Настройки > Безопасность и экран блокировки > Блокировка экрана.
Выберите из списка PIN-код или пароль. Теперь перезагрузите устройство обратно в TWRP.
Теперь программа восстановления попросит вас ввести PIN-код / пароль. Введите его, и ваше хранилище будет зашифровано.

Теперь попробуйте прошить нужные файлы и посмотрите, исправлена ли проблема с невозможностью монтировать хранилище в TWRP Recovery.

Исправление 2: восстановить или изменить файловую систему

Вы также можете попробовать восстановить или изменить файловую систему вашего устройства. Все это можно было сделать прямо из самого TWRP.

Итак, загрузите ваше устройство в TWRP Recovery.
Затем перейдите в Wipe > Advanced Wipe, нажмите Wipe и нажмите Advanced Wipe.
Теперь выберите раздел данных и нажмите на опцию «Восстановить» или «Изменить файловую систему». Затем нажмите «Восстановить файловую систему» и дождитесь завершения процесса. Проверьте, может ли он исправить проблему с монтированием.
Если он все еще там, то снова зайдите в «Восстановить или изменить файловую систему» и на этот раз нажмите «Изменить файловую систему».
В появившемся меню выберите EXT 2 и проведите пальцем вправо для подтверждения.
После этого вернитесь к EXT 4 и проведите пальцем вправо, чтобы подтвердить это.
Теперь перейдите в главное меню TWRP и перейдите к опции Mount
Выберите раздел Data и попробуйте прошить нужные файлы.

Убедитесь, что вы по-прежнему получаете сообщение об ошибке «Невозможно смонтировать хранилище при восстановлении TWRP».

Исправление 3: форматирование внутренней памяти

Если ни один из вышеперечисленных методов не помог устранить проблему с монтированием, возможно, вам придется выбрать ядерный вариант. Форматирование внутреннего хранилища кажется единственным выходом. Это, в свою очередь, сотрет все данные, имеющиеся на вашем устройстве.

Убедитесь, что вы создали эту резервную копию на SD-карте или USB OTG, а не в памяти телефона, так как мы собираемся полностью стереть этот раздел. Когда вы закончите резервное копирование, выполните следующие действия.

Загрузите устройство в TWRP Recovery.
Перейдите в Wipe > Advanced Wipe и выберите Internal Storage.
Наконец, проведите пальцем вправо, чтобы отформатировать этот раздел (все данные будут стерты).
Как только это будет сделано, ошибка монтирования будет исправлена. Имейте в виду, что внутреннее хранилище может по-прежнему отображаться как 0 МБ. Но на этот раз это данные в реальном времени (ваше внутреннее хранилище очищается, следовательно, используется 0 МБ пространства).

Мы поделились тремя разными методами для одного и того же, дайте нам знать, какой из них сработал за вас.

Источник

Stuck in an unrooted non stock rom. OEM unlocked. USB Debugging ON. getenforce permissive. Full log. Everything works up till run-as. Offering $50 to whoever can help fix this. Full log of adb command:

`C:UsersdarkseidDesktopLG_stuff>adb push dirtycow /data/local/tmp
dirtycow: 1 file pushed. 0.2 MB/s (9984 bytes in 0.042s)

C:UsersdarkseidDesktopLG_stuff>adb push recowvery-applypatch /data/local/tmp
recowvery-applypatch: 1 file pushed. 1.7 MB/s (18472 bytes in 0.011s)

C:UsersdarkseidDesktopLG_stuff>adb push recowvery-app_process64 /data/local/tmp
recowvery-app_process64: 1 file pushed. 1.0 MB/s (10200 bytes in 0.009s)

C:UsersdarkseidDesktopLG_stuff>adb push recowvery-run-as /data/local/tmp
recowvery-run-as: 1 file pushed. 0.9 MB/s (10192 bytes in 0.011s)

C:UsersdarkseidDesktopLG_stuff>adb shell
elsa:/ $ cd /data/local/tmp
elsa:/data/local/tmp $ ls
dirtycow recowvery-app_process64 recowvery-applypatch recowvery-run-as
elsa:/data/local/tmp $ chmod 0777 *
elsa:/data/local/tmp $ ./dirtycow /system/bin/applypatch recowvery-applypatch
warning: new file size (18472) and file old size (165144) differ

size 165144

[] mmap 0x79eac35000
[] exploit (patch)
[] currently 0x79eac35000=10102464c457f
[] madvise = 0x79eac35000 165144
[] madvise = 0 1048576
[] /proc/self/mem 1367343104 1048576
[*] exploited 0x79eac35000=10102464c457f
elsa:/data/local/tmp $ ./dirtycow /system/bin/app_process64 recowvery-app_process64
warning: new file size (10200) and file old size (18600) differ

size 18600

[] mmap 0x7280bda000
[] exploit (patch)
[] currently 0x7280bda000=10102464c457f
[] madvise = 0x7280bda000 18600
[] madvise = 0 1048576
[] /proc/self/mem -1971322880 1048576
[*] exploited 0x7280bda000=10102464c457f
elsa:/data/local/tmp $ exit

C:UsersdarkseidDesktopLG_stuff>adb logcat -s recowvery
——— beginning of system
——— beginning of main
——— beginning of crash
01-21 19:34:18.696 7457 7457 I recowvery: Welcome to recowvery! (app_process64)
01-21 19:34:18.696 7457 7457 I recowvery: ————
01-21 19:34:18.697 7457 7457 I recowvery: Current selinux context: u:r:zygote:s0
01-21 19:34:18.697 7457 7457 I recowvery: Set context to ‘u:r:system_server:s0’
01-21 19:34:18.698 7457 7457 I recowvery: Current security context: u:r:system_server:s0
01-21 19:34:18.698 7457 7457 I recowvery: Setting property ‘ctl.start’ to ‘flash_recovery’
01-21 19:34:18.708 7457 7457 I recowvery: ————
01-21 19:34:18.708 7457 7457 I recowvery: Recovery flash script should have started!
01-21 19:34:18.708 7457 7457 I recowvery: Run on your PC or device to see progress: adb logcat -s recowvery
01-21 19:34:18.708 7457 7457 I recowvery: Waiting 120 seconds…
01-21 19:34:18.756 7461 7461 I recowvery: Welcome to recowvery! (applypatch)
01-21 19:34:18.757 7461 7461 I recowvery: ————
01-21 19:34:18.757 7461 7461 I recowvery: Loading boot image from block device ‘/dev/block/bootdevice/by-name/boot’…
01-21 19:34:18.871 7461 7461 I recowvery: Loaded boot image!
01-21 19:34:18.871 7461 7461 I recowvery: ————
01-21 19:34:18.871 7461 7461 I recowvery: Saving old ramdisk to file
01-21 19:34:18.892 7461 7461 I recowvery: Writing to file ‘/cache/ramdisk.gz’…
01-21 19:34:18.930 7461 7461 I recowvery: Wrote OK: 7100944 bytes
01-21 19:34:18.930 7461 7461 I recowvery: Decompressing ramdisk (gzip -d)
01-21 19:34:19.357 7461 7461 I recowvery: Checking ‘/cache/ramdisk.cpio’ for validity (size >= 4194304 bytes)
01-21 19:34:19.357 7461 7461 I recowvery: ‘/cache/ramdisk.cpio’: 18494316 bytes
01-21 19:34:19.357 7461 7461 I recowvery: File OK
01-21 19:34:19.357 7461 7461 I recowvery: Decompression of ramdisk successful
01-21 19:34:19.357 7461 7461 I recowvery: Deleting ‘/cache/ramdisk.gz’ (no longer needed)
01-21 19:34:19.363 7461 7461 I recowvery: ————
01-21 19:34:19.363 7461 7461 I recowvery: Opened cpio archive ‘/cache/ramdisk.cpio’ (18494316 bytes)
01-21 19:34:19.363 7461 7461 I recowvery: Wrote new file (308 bytes) to cpio archive,
01-21 19:34:19.363 7461 7461 I recowvery: Final size: 18494624 bytes
01-21 19:34:19.363 7461 7461 I recowvery: ————
01-21 19:34:19.363 7461 7461 I recowvery: Compressing cpio to ramdisk (gzip -9 -c)
01-21 19:34:25.911 7461 7461 I recowvery: Checking ‘/cache/ramdisk.gz’ for validity (size >= 2097152 bytes)
01-21 19:34:25.912 7461 7461 I recowvery: ‘/cache/ramdisk.gz’: 7079535 bytes
01-21 19:34:25.912 7461 7461 I recowvery: File OK
01-21 19:34:25.912 7461 7461 I recowvery: Compression of ramdisk successful
01-21 19:34:25.912 7461 7461 I recowvery: Deleting ‘/cache/ramdisk.cpio’ (no longer needed)
01-21 19:34:25.930 7461 7461 I recowvery: Loading new ramdisk into boot image
01-21 19:34:25.942 7461 7461 I recowvery: ————
01-21 19:34:25.942 7461 7461 I recowvery: cmdline: «console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0 user_debug=31 ehci-hcd.park=3 lpm_levels.sleep_disabled=1 cma=32M@0-0xffffffff androidboot.hardware=elsa androidboot.selinux=permissive enforcing=0»
01-21 19:34:25.942 7461 7461 I recowvery: Setting permissive arguments on cmdline
01-21 19:34:25.942 7461 7461 I recowvery: cmdline: «console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0 user_debug=31 ehci-hcd.park=3 lpm_levels.sleep_disabled=1 cma=32M@0-0xffffffff androidboot.hardware=elsa androidboot.selinux=permissive enforcing=0»
01-21 19:34:25.942 7461 7461 I recowvery: ————
01-21 19:34:25.942 7461 7461 I recowvery: Updating boot image hash
01-21 19:34:26.363 7461 7461 I recowvery: Writing modified boot image to block device ‘/dev/block/bootdevice/by-name/recovery’…
01-21 19:34:26.581 7461 7461 I recowvery: Done!
01-21 19:34:26.581 7461 7461 I recowvery: ————
01-21 19:34:26.581 7461 7461 I recowvery: Permissive boot has been has been flashed to /dev/block/bootdevice/by-name/recovery successfully!
01-21 19:34:26.581 7461 7461 I recowvery: You may use ‘reboot recovery’ now to enter a permissive system.
01-21 19:34:26.581 7461 7461 I recowvery: ***********************************************
01-21 19:34:26.581 7461 7461 I recowvery: * give jcadduono a hug, will ya? *
01-21 19:34:26.581 7461 7461 I recowvery: ***********************************************
^C
C:UsersdarkseidDesktopLG_stuff>adb shell reboot recovery

C:UsersdarkseidDesktopLG_stuff>adb shell
elsa:/ $ getenforce
Permissive
elsa:/ $ cd /data/local/tmp
elsa:/data/local/tmp $ ./dirtycow /system/bin/run-as recowvery-run-as
warning: new file size (10192) and file old size (14360) differ

size 14360

[] mmap 0x7864c47000
[] exploit (patch)
[] currently 0x7864c47000=10102464c457f
[] madvise = 0x7864c47000 14360
[] madvise = 0 1048576
[] /proc/self/mem -2122317824 1048576
[*] exploited 0x7864c47000=10102464c457f
elsa:/data/local/tmp $ run-as exec ./recowvery-applypatch boot
Welcome to recowvery! (run-as)

Current uid: 2000
Setting capabilities
Could not set capabilities
Error 1: Operation not permitted`

Источник

In this guide, we will show you the steps to fix the Fastboot FAILED (remote: Operation not permitted) error. “The only thing that remains constant is change”- this quotation fits perfectly in the custom development. In the past couple of years, we have seen a plentitude of new and intriguing changes in this domain.

Flashing of files in FastbootD Mode as opposed to Fastboot, flashing vbmeta_vendor, vbmeta_system, and vendor_boot IMG files, and using the flash-all command instead of manually specifying the slots are just some of those changes. In more technical terms, you are now more likely to interact with the following commands:

fastboot reboot bootloader // for booting to FastbootD
fastboot --disable-verity --disable-verification flash vbmeta_system vbmeta_system.img // for flashing vbmeta system file
fastboot flash --slot=all abl abl.img  // instead of fastboot flash abl_a abl.img and fastboot flash abl_b abl.img

So with such drastic changes happening in custom development, your PC should also be having all its ADB and Fastboot binaries up to date. However, with such a plethora of drivers and software scattered all around, users might end up missing an update or two. And when that happens, errors such as the one shown below are bound to happen. If you are also currently facing the Fastboot FAILED (remote: Operation not permitted) error, then this guide shall help you fix it once and for all. Follow along.

Sending sparse 'system_a' 1/6 (262140 KB) OKAY [ 7.812s]
Writing sparse 'system_a' 1/6 OKAY [ 1.291s]
Sending sparse 'system_a' 2/6 (262140 KB) OKAY [ 7.735s]
Writing sparse 'system_a' 2/6 OKAY [ 1.345s]
Sending sparse 'system_a' 3/6 (262140 KB) OKAY [ 7.645s]
Writing sparse 'system_a' 3/6 OKAY [ 1.295s]
Sending sparse 'system_a' 4/6 (262140 KB) OKAY [ 8.050s]
Writing sparse 'system_a' 4/6 FAILED (remote: 'Operation not permitted')
Finished. Total time: 35.338s

The reason for this error is the fact that you are still using an older version of Google’s Android SDK Platform Tools. So you need to update it to the latest build right away, using the instructions given below:

To begin with, download the latest version of Android SDK Platform Tools
Then extract it to any convenient location on your PC. This shall give you the platform-tools folder.
Copy all the files inside that folder and transfer them to your older platform-tools folder.
It will now ask if you wish to replace the existing files, reply YES for all the files.
With this, the Platform Tools are successfully updated and this should fix the fastboot error as well.

One question you might ask is why did we update it this way? Well, you could have left the newer platform tools at a different location. But this would then lead to further complications. First off, you will then have to add the new ADB path to your PC’s environmental variables. Secondly, having two instances of ADB and Fastboot binaries is never a good idea.

So to avoid these issues in the first place, we decided to replace the older files with the newer ones inside the same folder. This way, the path of the environmental variables remains preserved and you only have a single ADB directory on your PC.

On that note, we round off the guide on how you could fix the Fastboot FAILED (remote: Operation not permitted) error as well. If you have any queries concerning the aforementioned steps, do let us know in the comments. We will get back to you with a solution at the earliest.

About Chief Editor

Sadique Hassan

administrator

A technical geek by birth, he always has a keen interest in the Android platform right since the birth of the HTC Dream. The open-source environment always seems to intrigue him with the plethora of options available at his fingertips. “MBA by profession, blogger by choice!”

Источник

В этом руководстве мы покажем вам, как исправить ошибку «Не удалось смонтировать / system (недопустимый аргумент)» в TWRP. Каждое устройство имеет довольно много разделов. Некоторые из них включают в себя загрузку, восстановление (только для устройства A), поставщика, vbmeta, пользовательские данные, систему и т. д. Хотя количество, тип и размер разделов могут различаться на разных устройствах, вышеупомянутые разделы можно найти почти на всех устройствах. о каждом устройстве.

И хотя каждый из этих разделов важен сам по себе, именно системный раздел можно отнести к категории наиболее важных. Причина довольно проста: он содержит вашу ОС. Однако, если есть проблема с этим разделом, обязательно будут проблемы. Среди различных проблем наиболее распространенная связана с TWRP.

Многие заинтересованные пользователи жалуются, что не могут смонтировать системный раздел на своем устройстве. В результате каждый раз, когда они собираются прошить пользовательское ПЗУ, TWRP отображает сообщение об ошибке не удалось смонтировать /систему (недопустимый аргумент). Хотя эта проблема по праву вызывает беспокойство, к счастью, ее можно решить с помощью нескольких обходных путей. Итак, без лишних слов, давайте проверим их.

Прежде чем попробовать какое-либо из перечисленных ниже исправлений, настоятельно рекомендуется сделать резервную копию всех данных на вашем устройстве. Droidwin и его участники не будут нести ответственность в случае термоядерной войны, если ваш будильник не разбудит вас, или если что-то случится с вашим устройством и данными, выполнив следующие шаги.

Исправление 1: установите стандартную прошивку через TWRP

В этом методе мы будем стирать все разделы устройства, а затем прошивать стандартную ОС через TWRP. Хотя большинство устройств поставляются с ПЗУ для восстановления (включая OxygenOS от OnePlus и ПЗУ для восстановления MIUI от Xiaomi), есть некоторые, у которых нет специального флэш-ПЗУ с поддержкой восстановления.

Для этого набора устройств им следует обратиться к нашему руководству по Flash Stock Firmware с помощью команд Fastboot. В то время как для других пользователей, которые могут прошить стандартную прошивку через TWRP, им следует выполнить следующие инструкции:

Для начала загрузите свое устройство в TWRP Recovery. Затем перейдите к Wipe и нажмите Advanced Wipe.
Выберите разделы Dalvik/ART Cache, System, Data и Vendor и проведите пальцем вправо, чтобы стереть их. [if you cannot select the System partition, then refer to the FAQ at the end of this guide].
Как только это будет сделано, перенесите Recovery ROM на свое устройство. Для этого перейдите в «Монтировать» и нажмите «Включить MTP». Точно так же вы можете использовать боковую загрузку ADB или попробовать через USB-OTG. Все это было объяснено в руководстве: 3 метода передачи или установки файлов через TWRP Recovery.
После того, как файл будет передан, перейдите в «Установить». Выберите ZIP-файл ROM и проведите пальцем вправо, чтобы прошить его.
После этого вы можете перезагрузить устройство в ОС. Для этого перейдите в «Перезагрузить» и выберите «Система». Проверьте, может ли он исправить ошибку не удалось смонтировать /систему (недопустимый аргумент) в TWRP.

Исправление 2: восстановить системный раздел через TWRP

Вы также можете использовать встроенную функцию восстановления файловой системы TWRP для восстановления системного раздела на вашем устройстве. Вот как:

восстановить-файловую-систему-twrp-fix-failed-to-mount-system-invalid-argument

Загрузите свое устройство в TWRP Recovery и перейдите к Wipe.
Затем выберите Advanced Wipe и отметьте системный раздел.
После этого нажмите «Восстановить или изменить файловую систему», а затем нажмите кнопку «Восстановить файловую систему».
Наконец, проведите пальцем вправо, чтобы восстановить системный раздел.
После этого перейдите в «Перезагрузить» и выберите «Система». Теперь ваше устройство должно быть загружено в ОС и посмотреть, была ли исправлена ошибка неудавшегося монтирования / системы (недопустимый аргумент) в TWRP или нет.

Исправление 3: обновить файловую систему EXT4 через TWRP

По умолчанию ваше устройство будет иметь файловую систему EXT4. В этом разделе мы изменим его на EXT2, а затем вернемся к исходному EXT4. Вот как это можно сделать:

изменить файловую систему twrp не удалось смонтировать систему (неверный аргумент)

В TWRP перейдите в Wipe и выберите Advanced Wipe.
Выберите системный раздел и нажмите «Восстановить» или «Изменить файловую систему».
Проверьте верхнюю часть меню, если файловая система говорит: EXT4 (как и в случае с большинством устройств, тогда мы переключимся на EXT2, а затем обратно на EXT4).
С другой стороны, если написано EXT2, то вам следует переключиться на EXT4 и обратно на EXT2. Что касается этого руководства, мы продолжим с первым (поскольку наше устройство имеет EXT4 по умолчанию).
Поэтому нажмите кнопку «Изменить файловую систему», выберите EXT2 и проведите пальцем вправо, чтобы подтвердить это.
После этого снова перейдите на этот экран и на этот раз нажмите на EXT4, чтобы переключиться на исходную файловую систему.
Как только это будет сделано, перезагрузите устройство в ОС через Reboot > System. Теперь проблема должна быть исправлена.

Итак, на этом мы завершаем руководство о том, как исправить ошибку «Не удалось смонтировать / system (недопустимый аргумент)» в TWRP. Если у вас есть какие-либо вопросы относительно вышеупомянутых шагов, сообщите нам об этом в комментариях. Мы вернемся к вам с решением в ближайшее время.

Часто задаваемые вопросы: очистка системного раздела с помощью команд Fastboot

Если вы не можете выбрать системный раздел через TWRP, вам придется стереть его с помощью команд Fastboot. Вот как это можно сделать:

Для начала заходим в раздел Reboot TWRP и выбираем System.
Затем установите Android SDK Platform Tools на свой компьютер.
Перейдите в папку с инструментами платформы, введите CMD в адресной строке и нажмите Enter. Это запустит окно CMD.
Подключите ваше устройство к ПК через USB-кабель.
Теперь введите приведенную ниже команду в окне CMD, чтобы стереть системный раздел: fastboot format system
После этого вам нужно будет перезагрузить устройство в TWRP. Для этого используйте следующую команду: fastboot reboot recovery
Как только ваше устройство загрузится в TWRP, сотрите другие разделы (Dalvik/ART Cache, Data и Vendor).
Теперь вы можете прошить ZIP-файл ПЗУ, как указано выше, и исправить ошибку «Не удалось смонтировать / system (недопустимый аргумент)» в TWRP.

Источник

В этой статье мы покажем вам, как исправить ошибку Невозможно смонтировать хранилище при восстановлении TWRP. Операционная система Android — это операционная система с открытым исходным кодом, которая позволяет выполнять различные настройки операционной системы. Для всех настроек вам нужно только разблокировать загрузчик телефона и установить пользовательское восстановление, потому что стандартное восстановление устройства не может установить эти файлы. Если у вас есть оба этих требования, вы сможете прошить широкую коллекцию пользовательских двоичных файлов, различных модов и таможенных ROM, а также рутировать свое устройство, установив приложение Magisk.

Восстановление TWRP оказалось очень полезным для пользователей Android. После того, как вы установили восстановление TWRP на свое устройство, вы можете использовать его для очистки различных разделов устройства, выполнения полных резервных копий Nandroid вместе с прошивкой файлов, упомянутых выше. Но ваши задачи и операции иногда могут быть прерваны из-за некоторых ошибок в кастомном рекавери. Наиболее часто встречающаяся и тревожная ошибка — это ошибка невозможности смонтировать хранилище в TWRP. В этой статье мы рассмотрим возможные причины этого сообщения об ошибке, а затем обсудим возможные решения этой проблемы, ставшей жертвами многих несчастных пользователей.

Есть разные причины возникновения ошибки невозможности смонтировать хранилище при восстановлении TWRP. Во-первых, внутренняя память вашего устройства может быть зашифрована. Почему это вызывает ошибку? Ну, это потому, что в этом случае TWRP не может расшифровать внутреннее хранилище вашего устройства, пока он выполняет задачу, поэтому он не может использовать или получить доступ к любым файлам, которые доступны или загружены во внутреннем хранилище вашего устройства. Вот почему эта ошибка в основном возникает, когда вы используете TWRP-восстановление для прошивки файла, который загружается во внутреннее хранилище вашего файла.

Если проблема, упомянутая выше, не так, возможно, раздел данных вашего устройства поврежден. Это может произойти из-за неправильной прошивки файла, прошивки неправильного типа файла или из-за прошивки файла в неправильном разделе данных. Как узнать, что это действительно проблема? В этих случаях ваш интерфейс TWRP показывает, что внутренняя память вашего устройства полностью пуста и имеет 0 МБ занятого места. Но вам не о чем беспокоиться, потому что это не так, и ваши данные могут быть в безопасности. Поскольку мы уже обсудили возможные причины ошибки TWRP не удается смонтировать хранилище, давайте обсудим способы решения проблемы.

Как исправить ошибку невозможности смонтировать хранилище в TWRP Recovery

Ниже мы упомянули три различных метода, с помощью которых вы можете исправить ошибку невозможности смонтировать хранилище при восстановлении TWRP. Вам необходимо следить за тем, чтобы вы следовали методам в том порядке, в котором мы их упомянули. Кроме того, не забудьте загрузить устройство в режиме TWRP.

Исправление 1: удалить экран блокировки

Если вы используете графический ключ блокировки на своем устройстве, вы должны либо удалить его, либо изменить его на PIN-код или пароль, потому что восстановление TWRP не может расшифровать блокировки шаблона. Заменить блокировку на устройстве очень просто, но мы показали вам, как это сделать:

ШАГ 1: Прежде всего, выйдите из режима TWRP и загрузите телефон в систему.

ШАГ 2: Когда вы вернетесь в систему, перейдите в «Настройки»> «Безопасность», а оттуда — в «Блокировка экрана»> «Блокировка».

ШАГ 3: Оттуда выберите ПИН-код или Пароль или снимите блокировку. После этого загрузите устройство обратно в режим TWRP.

ШАГ 4: После этого восстановление TWRP попросит вас ввести ПИН-код или пароль вашего устройства. Это расшифрует внутреннюю память вашего телефона.

Теперь вы можете попробовать прошить некоторые файлы на свое устройство, чтобы проверить, исправлена ли ошибка невозможности подключения хранилища при восстановлении TWRP или она все еще возникает. Если вы все еще видите сообщение об ошибке, перейдите к следующему способу.

Исправление 2: восстановить или изменить файловую систему

Второй способ, который вы можете попробовать, — это восстановить или изменить файловую систему вашего устройства. Сделать это можно прямо из TWRP.

ШАГ 1: Прежде всего, загрузите ваше устройство в режим TWRP.

ШАГ 2: Затем перейдите в Wipe> Advanced Wipe и там нажмите на опцию Wipe и Advanced Wipe.

ШАГ 3: После этого нажмите «Раздел данных», а затем нажмите «Восстановить или изменить файловую систему». Там нажмите на кнопку Восстановить файловую систему и дождитесь завершения процесса. Затем проверьте, исправляет ли он ошибку Невозможно смонтировать хранилище в TWRP.

ШАГ 4: Если проблема решена, все в порядке, но если ошибка все еще существует, вернитесь в Восстановление или изменение файловой системы. На этот раз выберите опцию «Изменить файл».

ШАГ 5: Вы увидите меню, в котором вам нужно выбрать EXT 2 и подтвердить его, проведя пальцем вправо.

ШАГ 6: После этого вам нужно снова переключиться на EXT 4 и подтвердить его.

ШАГ 7: После этого вернитесь на главный экран TWRP и перейдите к опции Mount.

ШАГ 8: Откройте раздел с данными и попробуйте снова прошить несколько файлов.

Проверьте, сталкиваетесь ли вы по-прежнему с ошибкой невозможности смонтировать хранилище в TWRP или нет. Если вы все еще сталкиваетесь с ошибкой, перейдите к следующему способу.

Исправление 3: форматирование внутренней памяти

Если вы попробовали два вышеуказанных метода и по-прежнему сталкиваетесь с ошибкой невозможности смонтировать хранилище при восстановлении TWRP, вам следует попробовать этот последний вариант, который обязательно исправит ошибку невозможности смонтировать хранилище в TWRP. Этот метод включает форматирование вашего внутреннего хранилища, при котором вам придется стереть все данные вашего устройства. Итак, поскольку вы теперь знаете, что этот метод будет включать удаление ваших данных, вам следует ознакомиться с нашим руководством о том, как выполнить резервное копирование ваших данных, чтобы избежать потери некоторых важных файлов или данных.

Когда вы закончите резервное копирование, выполните шаги, указанные ниже:

ШАГ 1: Загрузите ваше устройство в режим TWRP.

ШАГ 2: Затем перейдите в Wipe> Advanced Wipe и там выберите внутреннюю память.

ШАГ 3: Затем проведите пальцем вправо, чтобы отформатировать этот раздел, и все ваши данные будут удалены.

ШАГ 4: Как только вы закончите, ошибка невозможности смонтировать хранилище в TWRP будет исправлена. Ваше внутреннее хранилище в TWRP по-прежнему будет показывать вам 0 МБ, но на этот раз это будет правда.

Так что с нашей стороны! Мы надеемся, что эта статья оказалась для вас полезной. Если у вас есть какие-либо вопросы или вопросы, не стесняйтесь размещать их в разделе комментариев ниже.

Источник