Database Develop

[Q] 'Correct' way to compile a permissive SELinux kernel?

As the title suggests, I'm attempting to compile a (Lollipop) Nexus 5 kernel with SELinux in permissive mode by default. For reference, I am using the msm kernel source tree at commit 8a80a0e.
I have managed to accomplish this by modifying msm/security/selinux/selinuxfs.c and inserting new_value = 0; into sel_write_enforce to prevent the mode being changed:
Code:
length = -EINVAL;
if (sscanf(page, "%d", &new_value) != 1)
goto out;
new_value = 0; /* inserted this line */
if (new_value != selinux_enforcing) {
length = task_has_security(current, SECURITY__SETENFORCE);
if (length)
goto out;
audit_log(current->audit_context, GFP_KERNEL, AUDIT_MAC_STATUS,
"enforcing=%d old_enforcing=%d auid=%u ses=%u",
This method, however, doesn't seem particularly good, as it relies on the intricacies of the specific implementation of SELinux used in this kernel, and prevents the mode being changed later.
This post suggests changing the CONFIG_ALWAYS_ENFORCE flag for a Samsung device, however the Nexus 5 kernel does not appear to have such an option. Setting the default state of SELinux using various menuconfig options and kernel command line parameters does not appear to have any effect, and disabling it entirely causes the device to crash after boot, before any logcat output is produced.
I have noticed than when started with a kernel with SELinux enabled, one of the first messages from logcat is from auditd, of the form enforcing=1 old_enforcing=0 auid=... ses=..., indicating that something is setting the SELinux mode to enforcing almost immediately after boot.
Thus, I am wondering if anyone knows where this command to set SELinux to enforcing comes from, how to disable it, or another way to compile a kernel with SELinux set to permissive?

I believe you need to change the kernel config to allow command line switching of SELinux:
Code:
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
then modify the boot parameters of your boot.img adding to the cmdline:
Code:
enforcing=0 androidboot.selinux=permissive
I think that's the way. I went through all this but ended up just disabling SELinux altogether so I can't remember for sure if that's all.

Gene Poole said:
I believe you need to change the kernel config to allow command line switching of SELinux:
Code:
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
then modify the boot parameters of your boot.img adding to the cmdline:
Code:
enforcing=0 androidboot.selinux=permissive
I think that's the way. I went through all this but ended up just disabling SELinux altogether so I can't remember for sure if that's all.
Click to expand...
Click to collapse
Doesn't work. The system boots up in permissive mode, but immediately switches to enforcing, as it usually does. The first few lines of logcat:
Code:
--------- beginning of main
I/installd( 0): installd firing up
W/auditd ( 169): type=2000 audit(0.0:1): initialized
I/auditd ( 169): type=1403 audit(0.0:2): policy loaded auid=4294967295 ses=4294967295
W/auditd ( 169): type=1404 audit(0.0:3): enforcing=1 old_enforcing=0 auid=4294967295 ses=4294967295

Are you using the google boot image, or the AOSP image (they're quite different)? I just checked mine (built from source) and init has -DALLOW_DISABLE_SELINUX=1 which may not be present in the distro version of init.

Gene Poole said:
Are you using the google boot image, or the AOSP image (they're quite different)? I just checked mine (built from source) and init has -DALLOW_DISABLE_SELINUX=1 which may not be present in the distro version of init.
Click to expand...
Click to collapse
I wasn't aware there was a difference. I compiled the kernel from source, enabling the relevant config options, then got boot.img from the Nexus 5 factory image, and extracted and replaced the kernel and boot parameters as suggested by this document.

The boot.img built as part of the AOSP build (with USERDEBUG flag) is not locked down the way the factory boot image is. There may be something built-in to the init process to ensure selinux is available in the kernel and cannot be disabled.
I wish I knew more about this. My original goal was to implement the things I needed in the AOSP build and set up selinux permissions to allow it, but I gave up and ended up just removing selinux from the kernel altogether.

Hmm... I'll take a look in the initrd of the Android boot images to see if there's anything in there that might be setting the SELinux mode.
Update: Bah. It seems the AOSP source of init can be configured to accept a ro.boot.selinux parameter, but I see no indication that the code is present in the stock init binary. The code also explains why the phone immediately reboots into recovery when SELinux support is disabled in the kernel.
Update 2: After attempting to download 18GB of AOSP source code, I think my dodgy way of disabling SELinux is really the best method.

Gene Poole said:
I believe you need to change the kernel config to allow command line switching of SELinux:
Code:
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
then modify the boot parameters of your boot.img adding to the cmdline:
Code:
enforcing=0 androidboot.selinux=permissive
I think that's the way. I went through all this but ended up just disabling SELinux altogether so I can't remember for sure if that's all.
Click to expand...
Click to collapse
bootloop ¯\_(ツ)_/¯

Just disable it in the config?
Why do you need it if you don't use it?

Jo_Jo_2000 said:
Just disable it in the config?
Why do you need it if you don't use it?
Click to expand...
Click to collapse
I prefer CONFIG_ALWAYS_ENFORCE = false instead of new_value = 0

Dead Moto-x, wont even fastboot. Help?

SO, i have a 1st gen Moto X, the 2013 model. Verizon if that matters.
I havent used it in a while, and it was working when i replaced it. I decided to tinker with it a bit a few months ago, and was trying an unlock method i found online, and appear to have bricked it in the process. I figured, no big deal, and tossed it in a cabinet and figured i'd come back to it later. Well now is later. I'd like to get the thing working so my daughter might be able to play with it.
It wont power on, if you connect it to power, either USB or a wall plug, it does nothing, no charging indicator, nothing. I cant power it on, cant fastboot, cant get to recovery, nothing.
In my attempts to restore it, i've got the moto drivers and whatnot installed, and my Windows laptop will recognise it and add it to device manager, as "Qualcomm HS-USB QDLoader 9008 (COMx)". Which makes be believe there is hope.
I tried the procedure here: https://forum.xda-developers.com/moto-x/general/how-to-resurrecting-bricked-moto-x-t2629057, with no success, i get an error while it's trying to get an handshake from the device.
Code:
C:\Users\war\Desktop\MotoX Recovery\blankflash\blankflash>qflash -com7 -ramload MPRG8960.hex -mbn 33 MSM8960_bootloader_singleimage.bin -v -o
Motorola qflash Utility version 1.3
COMPORT :COM7
RAMLOADER :MPRG8960.hex
type is 0x21
7 mbn file name MSM8960_bootloader_singleimage.bin type 33
verbose mode on
Motorola qflash dll version 1.6
RAMLOADER VERSION: PBL_DloadVER2.0
------------------------------------------------------
DEVICE INFORMATION:
------------------------------------------------------
Version : 0x8
Min Version : 0x1
Max Write Size: 0x600
Model : 0x90
Device Size : 0
Description : Intel 28F400BX-TL or Intel 28F400BV-TL
------------------------------------------------------
Using passed in packet size, changing from 0x600 -> 0x600
EXTENDED_LINEAR_ADDRESS_REC @ 0x2a000000
Write 65536 bytes @ 0x2a000000
100EXTENDED_LINEAR_ADDRESS_REC @ 0x2a010000
Write 11840 bytes @ 0x2a010000
100START_LINEAR_ADDRESS_REC @ 0x2a000000
EOF_REC
Sleeping for 3s
No data read from USB. This may not be an error. Trying again...
No data read from USB. This may not be an error. Trying again...
No data read from USB. This may not be an error. Trying again...
No data read from USB. This may not be an error. Trying again...
No data read from USB. This may not be an error. Trying again...
Still no data, giving up!
sdl_hello() - Failed to receive ACK
sdl_hello() - Invalid response: 7e030003331b7e
sdl_hello() - This is a NAK response from ROM code, which means the device has been reset back to blank flash mode. Usually this is caused by power supply issues. Please try again with battery eliminator if it persists
I've had no luck finding a way around that.
If i hold the power button for 10 seconds, while plugged into my PC's usb port, the green indicator light behind the speaker lights up for a second, and then goes out. Same deal if I try to do power+vol-up or vol-down.
Any suggestion that might help me move this along? If i can get it to fastboot, or a recovery image, I think I can get it from there.
Thanks!

That's obsolete, and won't work for your lastest bootloader. See next thread. And don't flash Moto at random next time)

Thanks for the response. I'll give that thread a look!

flash recovery partition from android system/userland

I'm having trouble with fastboot (see my thread here: https://forum.xda-developers.com/xperia-xz1-compact/help/issues-fastboot-t3971227, maybe you can help). However, I can seem to flash sony signed software in sony-service mode using newflasher. That's nice, but I haven't used stock android in years. I am very used to lineageos without gapps---nice and clean. So, for me, until I get rid of stock and get a clean flash of lineage, I'm really not happy.
Given my state of affairs, I'm wondering about flashing one of the exploitable sony stocks and to get root, then flashing the recovery partition with twrp from userland. Then, potentially, i could boot to that recovery and maybe (idk) flash a new system ROM. Does anyone have any tips or suggestions?

It should work as you outlined.
Still having BL unlocked and not usable fastboot seems like a major disadvantage to me.
Did you try with different PC to see if it is not due to usb chipset or something?
Preferably using usb 2.0 only chipset?
Maybe trying that from different OSes too - linux vs win?

Thanks for the reply. I got the exploitable firmware downloaded and flashed as well as your renosploit kit. Hasn't found a root shell yet although I'm hopeful it will eventually (I haven't read the details but I understand that the underlying vuln is a race condition).
One question: I suppose that given that tmp root status, it should be possible to copy a su binary over and make root permanent, that would make experimentation easier, I think. And if whatever I try fails the first time I wouldn't want to have to wait for the race condition exploit every time I wanted to reboot. Am I on the right track? If so, I suppose I need to either compile or download a su binary and possibly a supersu.apk in order to manage it. Are those already available for the xz1 compact?

@apexofservice, planting su binary is possible into /oem for example, it would switch the user to root, but without any better permissions, due to selinux, so it is useless.
But since you have your BL unlocked, you do not need that. As soon as you have twrp, you can flash magisk to have root on runtime easily. Or just enter twrp to have root in recovery.

j4nn said:
@apexofservice, planting su binary is possible into /oem for example, it would switch the user to root, but without any better permissions, due to selinux, so it is useless.
But since you have your BL unlocked, you do not need that. As soon as you have twrp, you can flash magisk to have root on runtime easily. Or just enter twrp to have root in recovery.
Click to expand...
Click to collapse
Got it. Thank you for this detail. So you think my best bet is to just use the root shell to `dd` the twrp image directly to some /dev? And then I would just `adb reboot recovery` and in theory I'm good to go.

Cool. I got a root shell with your exploit kit. I've got two questions at this point.
1) If my bootloader unlock had fully succeeded, would I have expected to find all 0x0 in the TA partition? In fact, there is data in there, so I went ahead and downloaded it. I skimmed the data with xxd and there are some sections of 0x0 as well though.
2) Second question, I've read that xperia's don't have a proper "recovery" partition the way some other boards do. So is FOTAkernel actually where I want to write twrp.img? Also, it would seem that this info is actually encoded somewhere in the fastboot client since on a working fastboot, you can just say "flash recovery" and it knows what part of the disk to write to. Any info about partition layouts on lilac and xperia's in general would be greatly appreciated.

apexofservice said:
Cool. I got a root shell with your exploit kit. I've got two questions at this point.
1) If my bootloader unlock had fully succeeded, would I have expected to find all 0x0 in the TA partition? In fact, there is data in there, so I went ahead and downloaded it. I skimmed the data with xxd and there are some sections of 0x0 as well though.
2) Second question, I've read that xperia's don't have a proper "recovery" partition the way some other boards do. So is FOTAkernel actually where I want to write twrp.img? Also, it would seem that this info is actually encoded somewhere in the fastboot client since on a working fastboot, you can just say "flash recovery" and it knows what part of the disk to write to. Any info about partition layouts on lilac and xperia's in general would be greatly appreciated.
Click to expand...
Click to collapse
1 - The TA partition contains significant amounts of other information as well. So it won't be empty.
The standard way of dealing with it is to not mess with it at all.
2 - The FOTAkernel is the recovery.
2a - The partition layout can be found from the stock firmware image in the "partition-image-LUNZ_X-FLASH-ALL-C93B.sin" file where "Z" is the LUN number. Once you extract the SIN file, you're left with an EFI partition header.
I've attached a CSV file that contains the layout as specified in the "partition-image-LUN0_X-FLASH-ALL-C93B.sin" file.
The layout for LUNs 1 and 2 both contain a single 4MB partition for "xbl" and "xblbak" respectively, so they're not as interesting.

@pbarrette, thanks! I tried the naive approach:
Code:
d if=twrp-3.2.1-0-lilac-10-patchlevel-2018-05-05.img of=/dev/block/bootdevice/by-name/FOTAKernel <
60128+0 records in
60128+0 records out
30785536 bytes transferred in 2.100 secs (14659779 bytes/sec)
G8441:/data/local/tmp # sync
G8441:/data/local/tmp # sync
G8441:/data/local/tmp # reboot recovery
Alas, it just rebooted back to system. It did seem to take a bit longer, so it's possible that it tried to boot from FOTAKernel and failed then fell back to system. I've just got a new root shell so I can look in startup logs from dmesg to see if there's anything of interest.
Also, I'm probably missing something really obvious. Thanks for any insight!
Reading dmesg now, this seems quite relevant (I recall booting to recovery on my z3 compact by touching a file in /cache/recovery). I'll post it here but I'm still reading the dmesg.
Code:
[ 7.406109] bs_roots: recovery filesystem table
[ 7.406120] bs_roots: =========================
[ 7.406125] bs_roots: 0 /data ext4 /dev/block/bootdevice/by-name/userdata
[ 7.406130] bs_roots: 1 /oem ext4 /dev/block/bootdevice/by-name/oem
[ 7.406134] bs_roots: 2 /cache ext4 /dev/block/bootdevice/by-name/cache
[ 7.406139] bs_roots: 3 /rca ext4 /dev/block/bootdevice/by-name/appslog
[ 7.406143] bs_roots: 4 /idd ext4 /dev/block/bootdevice/by-name/diag
[ 7.406148] bs_roots: 5 /storage/sdcard1 vfat /devices/soc/c0a4900.sdhci/mmc_host*
[ 7.406153] bs_roots: 6 none swap /dev/block/zram0
[ 7.406157] bs_roots: 7 /persistent emmc /dev/block/bootdevice/by-name/frp
[ 7.406162] bs_roots: 8 /misc emmc /dev/block/bootdevice/by-name/misc
[ 7.406167] bs_roots: 9 /firmware vfat /dev/block/bootdevice/by-name/modem
[ 7.406172] bs_roots: 10 /bt_firmware vfat /dev/block/bootdevice/by-name/bluetooth
[ 7.406177] bs_roots: 11 /dsp ext4 /dev/block/bootdevice/by-name/dsp
[ 7.406182] bs_roots: 12 /persist ext4 /dev/block/bootdevice/by-name/persist
[ 7.406187] bs_roots: 13 /boot/modem_fs1 emmc /dev/block/bootdevice/by-name/modemst1
[ 7.406191] bs_roots: 14 /boot/modem_fs2 emmc /dev/block/bootdevice/by-name/modemst2
[ 7.406195] bs_roots: 15 auto auto /devices/soc/a800000.ssusb/a800000.dwc3/xhci-hcd.0.auto/usb*
[ 7.406199] bs_roots: 16 /qns ext4 /dev/block/bootdevice/by-name/Qnovo
[ 7.406203] bs_roots: 17 /tmp ramdisk ramdisk
[ 7.406206] bs_roots:
[ 7.408585] MR: Mounting /cache ourselves
[ 7.412318] EXT4-fs (sda53): recovery complete
[ 7.412666] EXT4-fs (sda53): mounted filesystem with ordered data mode. Opts:
[ 7.413213] MR: fopen() failed -/cache/recovery/command (No such file or directory)
[ 7.413219] MR: Unmounting /cache
[ 7.413959] MR: Fail to get command from /cache/recovery/command, trying /misc
[ 7.414272] MR: Unknown wipe command
[ 7.414280] MR: Buffer is empty from /dev/block/bootdevice/by-name/misc with command 0
[ 7.417568] MR: TA_MASTER_RESET value = 0
[ 7.418475] init: Service 'exec 3 (/sbin/mr)' (pid 605) exited with status 0 waiting took 0.022997 se
conds
[ 7.418513] init: starting service 'exec 4 (/sbin/ffu)'...
[ 7.418846] init: SVC_EXEC pid 609 (uid 0 gid 0+0 context u:r:recovery:s0) started; waiting...
[ 7.419833] init: Service 'exec 4 (/sbin/ffu)' (pid 609) exited with status 255 waiting took 0.001316
seconds
------
One more update, I did a sanity check that that dd command is actually overwriting FOTAkernel. It doesn't look like it's working:
Code:
G8441:/data/local/tmp # dd if=/dev/block/bootdevice/by-name/FOTAKernel of=FOTAKernel-extracted.img
131072+0 records in
131072+0 records out
67108864 bytes transferred in 0.812 secs (82646384 bytes/sec)
G8441:/data/local/tmp # chown shell:shell FOTAKernel-extracted.img
G8441:/data/local/tmp # dd if=twrp-3.2.1-0-lilac-10-patchlevel-2018-05-05.img of=/dev/block/bootdevice/by-name/FOTAKernel
60128+0 records in
60128+0 records out
30785536 bytes transferred in 2.037 secs (15113174 bytes/sec)
G8441:/data/local/tmp # sync
G8441:/data/local/tmp # sync
=/dev/block/bootdevice/by-name/FOTAKernel of=FOTAKernel-extracted-2.img <
131072+0 records in
131072+0 records out
67108864 bytes transferred in 0.846 secs (79324898 bytes/sec)
And there's no `diff` on the device, so I pulled the files back to a laptop then:
Code:
$ diff FOTAKernel-extracted-2.img FOTAKernel-extracted.img
$ diff FOTAKernel-extracted.img twrp-3.2.1-0-lilac-10-patchlevel-2018-05-05.img
Binary files FOTAKernel-extracted.img and twrp-3.2.1-0-lilac-10-patchlevel-2018-05-05.img differ

@j4nn @pbarrette doing some more reading, I found some interesting details about booting to recovery stored on FOTAKernel here:
https://twrp.me/sony/sonyxperiaxz.html
https://twrp.me/sony/sonyxperiaz3compact.html
Looks like you really need a kernel that has the ramdisk extraction setup. So I'm guessing that once I figure out why dd isn''t working as I expected (see above) that I need to overwrite the main stock kernel with an alternative.

Yes, a dd extraction of the partition will be different than the TWRP image.
That's because the TWRP image is only ~35MB, while "dd" is extracting the entire 64MB partition.
So, if you do a visual diff on the files, you should see that what's actually different is the fact that the partition extraction is filled with zeros after the end of the TWRP image.
You're doing a "reboot recovery", but have you tried:
1 - Turn the phone off
2 - Press and hold [Vol-Down].
3 - Press and hold [Power].
4 - Release [Power] at power on.
5 - Release [Vol-Down] when you see an actual boot screen (after the bootloader unlocked screen).
I don't remember the "reboot recovery" command ever working right for me.
Edit to add: That's also a really old version of TWRP that you seem to be using.

pbarrette said:
Yes, a dd extraction of the partition will be different than the TWRP image.
That's because the TWRP image is only ~35MB, while "dd" is extracting the entire 64MB partition.
So, if you do a visual diff on the files, you should see that what's actually different is the fact that the partition extraction is filled with zeros after the end of the TWRP image.
You're doing a "reboot recovery", but have you tried:
1 - Turn the phone off
2 - Press and hold [Vol-Down].
3 - Press and hold [Power].
4 - Release [Power] at power on.
5 - Release [Vol-Down] when you see an actual boot screen (after the bootloader unlocked screen).
I don't remember the "reboot recovery" command ever working right for me.
Edit to add: That's also a really old version of TWRP that you seem to be using.
Click to expand...
Click to collapse
Hot damn. Thanks, I'm booted to twrp!
Note: i was using the older version for android 8 since I'm currently on the android 8 exploitable rom!

apexofservice said:
@j4nn @pbarrette doing some more reading, I found some interesting details about booting to recovery stored on FOTAKernel here:
https://twrp.me/sony/sonyxperiaxz.html
https://twrp.me/sony/sonyxperiaz3compact.html
Looks like you really need a kernel that has the ramdisk extraction setup. So I'm guessing that once I figure out why dd isn''t working as I expected (see above) that I need to overwrite the main stock kernel with an alternative.
Click to expand...
Click to collapse
XZ1 compact never needed the recovery with this extraction stuff. But according to
https://twrp.me/sony/sonyxperiaxzpremium.html
XZ Premium (which is also yoshino platform, the same as xz1c is) seems to need that - but I am not sure if it is still valid.
It might got fixed even in xzp case with some bootloader update to have it working the same as with other yoshino phones.
Sorry for my late answer, it's good you already have it working.
But I still wonder about that usb problem with fastboot - have you tried a different pc with different usb controller, preferably usb 2.0 type (not 3.0 one)?

j4nn said:
XZ1 compact never needed the recovery with this extraction stuff. But according to
https://twrp.me/sony/sonyxperiaxzpremium.html
XZ Premium (which is also yoshino platform, the same as xz1c is) seems to need that - but I am not sure if it is still valid.
It might got fixed even in xzp case with some bootloader update to have it working the same as with other yoshino phones.
Sorry for my late answer, it's good you already have it working.
But I still wonder about that usb problem with fastboot - have you tried a different pc with different usb controller, preferably usb 2.0 type (not 3.0 one)?
Click to expand...
Click to collapse
I haven't yet. Well, I have sorta. When I first ran into issues, I tried it with a different laptop, got the same result. Now that laptop was also a thinkpad (although a newer model) and was also running debian linux. I don't have any computers with Windows. I was going to reboot this laptop with usb3.0 kernel mod blacklisted and only using hci but I didn't get around to it yet (especially once I got twrp flashed and working, then I mainly wanted to get started actually using the phone i bought ). However, if it were a usb thing, wouldn't we expect that newflasher would fail too? Still, it is very curious about the fastboot thing, however, so I'm willing to keep playing with it.

@apexofservice, I am not sure if blacklisting usb3 drivers would help. Sometime there may be present multiple usb ports, some connected to usb 3.0 host controller, others just usb 2.0 controller.
Even if newflasher works, it is not that simple, that fastboot should work too.
Fastboot (including it's usb support) is implemented in UEFI bootloader, the ABL component of it (Android Boot Loader).
So usb stack is implemented by UEFI fw.
While newflasher uses flash mode, which is running XFL - a linux (bare bone android) kernel, running the lilo/loader userspace application. So there is in my opinion quite good usb stack implemented by linux kernel.
So it can easily be some incompatibility within UEFI usb stack implementation used with fastboot.

[Q] How to debug soft brick (SONY logo)

I'm building my own LineageOS from source for a while now. Updating it via `repo sync`, adding own patches and rebuilding has always worked fine. Until recently the phone gets soft bricked, stuck at the SONY logo on white screen and I can't figure out why.
Now I'm looking for a way to find the issue, i.e. debug that brick, get some logs or anything which allows me to fix that. `adb logcat` doesn't work as it is stuck way to early for that.
What are my options for getting logs, messages, errors, anything that may help?

With help from @linckandrea I got the following to work which I document here for others to benefit:
1. Create a file `init.log.sh` with following content and executable permission
Bash:
#! /vendor/bin/sh
_date=`date +%F_%H-%M-%S`
logcat -b all -v time -f /cache/logcat_${_date}.txt &
cat /proc/kmsg > /cache/kmsg_${_date}.txt
2. Copy it to /vendor/bin e.g. via
Bash:
PRODUCT_COPY_FILES += $(PLATFORM_PATH)/config/init/init.log.sh:$(TARGET_COPY_OUT_VENDOR)/bin/init.log.sh
in the makefiles
3. Add the following to (any) init.rc, e.g. init.yoshino.rc:
Code:
service logx /vendor/bin/init.log.sh
user root
group root system
seclabel u:r:su:s0
oneshot
on post-fs
start logx
4. Either find a context with access to /cache (maybe "system_app") and use that in "seclabel" instead of "su" or disable SELinux with
Bash:
BOARD_KERNEL_CMDLINE += androidboot.selinux=permissive
This will dump kernel logs to /cache which can be accessed with e.g. TWRP after a failed boot.

How To Guide How to "fix" the error Cannot load Android system. Your data may be corrupt.

If a serious error occurs when booting Android, Android boots the phone from the recovery installed on the phone. The standard Android recovery then aborts the boot process with an error message similar to this one:
Cannot load Android system. Your data may be corrupt.
and the only options to continue are "Try again" or "Factory data reset".
The error message is not really useful and most documentation on the Internet that I found recommends a factory reset to fix the problem. In most cases, factory reset works, but it has the disadvantage that you lose all the settings and data on the phone. So in most cases this is the worst option.
However, if the error is not caused by an invalid or missing file in the partitions for /data or /metadata, resetting to factory defaults will not fix the problem, but the data from the phone will still be gone.
Therefor I wrote this little HowTo.
This HowTo is not about how to fix that error -- it only contains some hints to find the reason for the error.
To get more information about the error and also the possibility to backup the phone's data, TWRP can be used:
Just poweroff the phone, reboot the phone into the bootloader, and then reboot the phone from the TWRP image, e.g:
Bash:
sudo fastboot boot /data/backup/ASUS_ZENFONE8/twrp/twrp-3.7.0_12-0-I006D-enhanced.img
Note:
In most cases, there is no option to turn off the phone in this dialog, so the phone must be turned off using the phone keys.
The key combination to turn off the phone during this dialog depends on the phone; on an ASUS Zenfone 8, this key combination must be used:
Press Volume UP + Volume DOWN + Power for 20 or more seconds
After the phone booted into the TWRP image connect via adb to the phone and check the TWRP logfile for a more detailed error message. The logile used by TWRP is /data/recovery/log.gz. Search for the string "Android Rescue Party trigger" in the TWRP logfile.
Note:
/data/recovery/log.gz is a compressed file ; use gzip to uncompress it.
Example:
Code:
ASUS_I006D:/ # gzip -cd /data/recovery/log.gz | more
Starting TWRP 3.7.0_12-0-d07fdb3c on Sat Jan 10 00:53:15 1970
(pid 403)
I:Lun file '/config/usb_gadget/g1/functions/mass_storage.0/lun.0/file'
PRODUCT_USE_DYNAMIC_PARTITIONS := true
TW_INCLUDE_CRYPTO := true
I:TW_BRIGHTNESS_PATH := /proc/lcd_brightness
I:Found brightness file at '/proc/lcd_brightness'
I:TWFunc::Set_Brightness: Setting brightness control to 420
I:TW_EXCLUDE_ENCRYPTED_BACKUPS := true
I:LANG: en
I:AB_OTA_UPDATER := true
Starting the UI...
Skipping adf graphics -- not present in build tree
setting DRM_FORMAT_XBGR8888 and GGL_PIXEL_FORMAT_RGBA_8888
setting DRM_FORMAT_XBGR8888 and GGL_PIXEL_FORMAT_RGBA_8888
....
I:Switching packages (TWRP)
boot command: boot-recovery
I:Startup Commands:
Android Rescue Party trigger! Possible solutions? Either:
1. Wipe caches, and/or
2. Format data, and/or
3. Clean-flash your ROM.
The reported problem is:
'--reason=set_policy_failed:/data/misc'
'--reason=set_policy_failed:/data/misc'
ro.boot.bootreason=shutdown
ro.boot.id.rf=1
If the error message is still not helpful in finding the reason for the error, try a Google search.
And if a factory reset is necessary, you can at least back up your data on the phone before performing the reset.
More infos about Android Rescue Party Trigger
The Android Rescue Party Trigger is an error handling process from Android (see here for more details about this Android functionality)
Android Rescue Party Trigger can also be triggered by Android while the OS is running :
In this case there should be some additional messages in the logfile /data/system/uiderrors.txt.
In addition, and if Magisk is installed, it might be useful to write the logcat messages to a file using the script from this post:
https://gist.github.com/niikoo/3f6bd13a69f2d68f3dd51cc667e79bdc
File: /data/adb/post-fs-data.d/0001logcatboot
Code:
#!/system/bin/sh
mkdir -p /cache/logs
/system/bin/logcat -r 1024 -n 9 -v threadtime -f /cache/logs/log >info.log 2>err.log &
The script can also be "installed" after the error already occured, to do this:
Boot the phone from the TWRP image; copy the script to the directory /data/adb/post-fs-data.d; make it executable and reboot the phone again from the installed OS to trigger the error again.
Note that logcat is not yet running if the error occurs in the early boot phase.
Caution:
If possible, TWRP will mount /data into the partition used for /data in the Android OS. Therefore, you can view the recovery boot logs in /data/recovery even after restarting the Android operating system as the user root.
However, if mounting the partition for /data in TWRP does not work, /data will be a directory in the root file system, e.g.:
Code:
130|ASUS_I006D:/ # df -h /data
Filesystem Size Used Avail Use% Mounted on
rootfs 3.2G 101M 3.1G 4% /
ASUS_I006D:/ #
In this case the contents of /data/reocvery are lost after rebooting the phone!
Notes:
The Android kernel uses the device /dev/block/by-name/misc to store the kernel parameter for the recovery kernel. The kernel from the recovery TWRP will clean the device /dev/block/by-name/misc . Therefor the error message is only visible in the logs of the first boot of TWRP.
The active log file for TWRP is /tmp/recovery.log; you can also use that file for the checks. Note that /tmp is mounted on a ramdisk.
On the page https://source.android.com/docs/core/tests/debug/rescue-party are instructions to force an Android Rescue Partry trigger by setting some properties but I did not get that to work neither in the OmniROM 13 nor in the ASUS Android 12.
To avoid the reboot from the TWRP image, install the TWRP recovery on the phone. In this case, Android will automatically boot into the installed TWRP recovery when a fatal error occurs.