Related
Hi
Archos G9 devices are quite new so we should create some developement guidelines/standards to avoid total mess.
This thread is meant to be the place to create those, feel free to contribute.
1. Firmware file name- archos.ext4/squashfs/img
as propposed by letama (source) and agreed by suduru_petru (source)
2. Firmware updating
letama in his builds added a mechanism to painlessly update system image: new image is called [...].update, kernel initrd deletes "old" file and renames new one- there is no need to boot or install stock firmware.
My opinion- this should be the standard but subject is to be discussed
However updating/downgrading firmware may cause problems so-
3. Recovering from problems (bootloop, FC's etc)
This subject is to be discussed.
Archos G9 has specific system structure and "non-standard" Recovery. For now the only way to fix app FC's or a bootloop is to wipe data (Reset Android option in recovery) but this deletes all system data. Better solution is to wipe dalvik-cache- this deletes some files used by system but they are rebuilt during boot- but there is no way to do it now.
After talking with letama we've come to an idea: kernel init looks for .update files and
-if it's archos.ext4/squashfs/img.update kernel updates system image
-if it has another but predefined name- .update file is a shell script that is executed
This would give us a substitute for a "standard" recovery. Best way would be to use external SD-card for this task but first we have to check if there are any problematic cards (seems that letama has such card)
Please post your opinions/ideas/suggestions but keep in mind that this is not a system/app feature request topic
And if you have a better idea for the topic title- let me know
My idea how .update files should be handled:
during boot check if external sd card is present
1)yes- check for .update files
a)archos.[...].update present- delete current system image from /data/media, copy new one, delete archos.[...].update files from card AND from /data/media
b) .update script file present- run script, delete script .update from sd AND /data/media
2) no- check /data/media for .update files
a)archos.[...].update- delete current system image, rename update file
b).update script- run script and delete .update file
Notes:
-both types of .update files should be handled if found- when updating firmware wiping dalvik-cache (rm -r -f /data/dalvik-cache) is always advised and this can be done using a script since we don't have a "standard" recovery
-using external sd as the first choice- if adb can't be accessed (no PC, no USB cable, bootloop etc) there is no way to access internal storage
gen_scheisskopf said:
My idea how .update files should be handled:
during boot check if external sd card is present
1)yes- check for .update files
a)archos.[...].update present- delete current system image from /data/media, copy new one, delete archos.[...].update files from card AND from /data/media
b) .update script file present- run script, delete script .update from sd AND /data/media
2) no- check /data/media for .update files
a)archos.[...].update- delete current system image, rename update file
b).update script- run script and delete .update file
Notes:
-both types of .update files should be handled if found- when updating firmware wiping dalvik-cache (rm -r -f /data/dalvik-cache) is always advised and this can be done using a script since we don't have a "standard" recovery
-using external sd as the first choice- if adb can't be accessed (no PC, no USB cable, bootloop etc) there is no way to access internal storage
Click to expand...
Click to collapse
First...Thanks @gen_scheisskopf for your idea....ofcourse is very important for us to have a standard "language".....and you are rigt ( is also my opinion ) - is very unpleasant to take it from zero for an future update or custom rom , considering that many users have installed many custom applications ( games, contacts-data, calendar-data and other personalizated-data....or other stuff).
I hope that together , we'll found the right way for this inconvenience ......and what you began is a necessary and welcome environment to improve programming and use.
Without portability not succeed to have its own development !
I hope in a close collaboration among you especially as you have one of the best developers (Thanks @LeTama) .. but I hope to help us and other developers ....See you soon ! and you started a great job anyway !
Problems like bootloop or FC's can occur even if firmware wasn't changed but there is no *easy* way to fix this yet- so we should make one
One more thing from my side- [email protected] image should be mounted RO by default:
-system RO is a standard (also in official firmware)
-nobody can do any harm to system by accident- any changes will require remounting RW first and no app does this by itself
-all root apps that can make changes to system (TitaniumBackup, RootExplorer, Abslute Root Tools, SUFBS etc) will function properly for remounting RO/RW
gen_scheisskopf said:
-system RO is a standard (also in official firmware)
Click to expand...
Click to collapse
Agreed, it would be nice. However, Archos has not the android standard way of managing partitions, they don't mount a /system partition on top of initrd , they mount a root partition that contains a system directory and chroot it. In short, we mount /dev/loop0 on /new-sys then chroot /new-sys, we don't /dev/block/mmcblkp1 on /system.
More, /dev/loop0 is becoming /dev/block/loop0 when android is booted, so it's a bit tricky to remount r/w after that. I think most root applications are confused with this layout and can't remount properly, that's why I left default to r/w in my build.
It would be good to test it a bit more with few root apps to see if some are working, I didn't do much tests.
I understand.
How about "ln -s /dev/block/loop0 /"? This can be done in init.rc (both kernel initrd and in system image init), not sure if this will work properly
Another idea about .update files- possibly safer way would be to add a predefined set of scripts to initrd- like it's done in recovery- and to use .update files with a different names (like wipe-dalivik.update).
letama said:
It would be good to test it a bit more with few root apps to see if some are working, I didn't do much tests.
Click to expand...
Click to collapse
TitaniumBackup has problems with integrating updated apps into rom- device rebooted during Maps.apk processing (2nd of 4) and now Market is missing from /system/app
Can't say however what caused this- system img file location (loop0) or RW by default. Ext4 is not the cause, I've used ext2 and ext4 for /system on the other device before and there was no problem.
EDIT:
TB restored Market from backup straight to /system/app and it seems that manual integration works fine. Maybe that was just a system error.
Dalvik-cache wipe in init:
Code:
# Do updates if need
if [ -e /data/media/archos.ext4.update ] ; then
rm /data/media/archos.ext4
mv /data/media/archos.ext4.update /data/media/archos.ext4
[B]rm -r /data/dalvik-cache[/B]
fi
if [ -e /data/media/archos.squashfs.update ] ; then
rm /data/media/archos.squashfs
mv /data/media/archos.squashfs.update /data/media/archos.squashfs
[B]rm -r /data/dalvik-cache[/B]
fi
[B]if [ -e /data/media/wipe-dalvik.update ] ; then
rm -r /data/dalvik-cache
rm /data/media/wipe-dalvik.update
fi[/B]
-when archos.ext4/squashfs.update file is found dalvik-cache wipe is mandatory
-file /data/media/wipe-dalvik.update also triggers wipe (and dalvik-wipe.update file is removed
Tested, works fine
gen_scheisskopf said:
Dalvik-cache wipe in init:
Code:
# Do updates if need
if [ -e /data/media/archos.ext4.update ] ; then
rm /data/media/archos.ext4
mv /data/media/archos.ext4.update /data/media/archos.ext4
[B]rm -r /data/dalvik-cache[/B]
fi
if [ -e /data/media/archos.squashfs.update ] ; then
rm /data/media/archos.squashfs
mv /data/media/archos.squashfs.update /data/media/archos.squashfs
[B]rm -r /data/dalvik-cache[/B]
fi
[B]if [ -e /data/media/wipe-dalvik.update ] ; then
rm -r /data/dalvik-cache
rm /data/media/wipe-dalvik.update
fi[/B]
-when archos.ext4/squashfs.update file is found dalvik-cache wipe is mandatory
-file /data/media/wipe-dalvik.update also triggers wipe (and dalvik-wipe.update file is removed
Tested, works fine
Click to expand...
Click to collapse
Thanks...good job !
Another test, possibly will work for HDD models:
Code:
mount_p data
mount_p storage_`$GET_INFO p` #this should return product name and use correct storage mountpoint
#Check if system image is present, if not- copy from storage
if [ ! -e /data/local/archos.ext4 ] ; then
cp /mnt/storage/archos.ext4.update /data/local/archos.ext4
fi
# Do updates if need
if [ -e /mnt/storge/archos.ext4.update ] && [ -e /mnt/storage/system.update] ; then
rm /data/local/archos.ext4
cp /mnt/storage/archos.ext4.update /data/local/archos.ext4
rm /mnt/storage/system.update
rm -r /data/dalvik-cache
fi
if [ -e /mnt/storage/archos.squashfs.update ] && [ -e /mnt/storage/system.update ] ; then
rm /data/local/archos.squashfs
cp /mnt/storage/archos.squashfs.update /data/local/archos.squashfs
rm /mnt/storage/system.update
rm -r /data/dalvik-cache
fi
if [ -e /mnt/storage/wipe-dalvik.update ] ; then
rm -r /data/dalvik-cache
rm /storage/wipe-dalvik.update
fi
umount_p storage_`$GET_INFO p`
# Now boot
if [ -e /data/local/archos.ext4 ] ; then
$LOSETUP `get_mount_info d rfsext4` /data/local/archos.ext4 || log_and_die "Mounting system partition failed"
mount_p rfsext4 || log_and_reboot "Mounting system partition failed"
umount_p rawfs
rootfs_path=`get_mount_info p rfsext4`
umount_pseudo_fs
log "SWITCHING TO REAL ROOT"
exec switch_root $rootfs_path /init
fi
$LOSETUP `get_mount_info d rootfs` /data/loacl/archos.squashfs || log_and_die "Mounting system partition failed"
mount_p rootfs || log_and_reboot "Mounting system partition failed"
umount_p rawfs
rootfs_path=`get_mount_info p rootfs`
umount_pseudo_fs
log "SWITCHING TO REAL ROOT"
exec switch_root $rootfs_path /init
Changes
-system image file is mounted from /data/local (not /data/media)
-archos.ext4.update file is preserved on storage (/data/media or hdd) in case of data wipe- init copies it to the right place if file is not present
-updating firmware requires two files- archos.ext4.update and system.update- second one is an empty file, it is removed after system update (archos.ext4.update is not removed)
-I did not add checking for archos.squashfs file
Prequisites
-minimum 512 MB free on /data for hdd models- they have much smaller /data- about 1.5GB
This works fine on 16GB model- file is copied without any problem and possibly will work on HDD models too- I've sent test version to philmein (he was willing to test)
Android does not touch /data/local/archos.ext4 file (/data/local belongs to shell, not system so it's a safe place)
Other thoughts:
-maybe we drop archos.squashfs support?
-archos.ext4 can be made smaller- 191 MB is free so 400 MB should be more than enough
-maybe add mounting official system file (.squashfs.secure) if there is no custom one present and no archos.ext4.update on storage?
-other possible location can be /data/customization but I didn't test it
Hi @gen_scheisskopf...
I think ( not sure ...) , that until we find a way for mount proper HDD into initramfs , we can't load any files system ( .ext4, .squashfs, .update ) for Archos HDD !
Your test it's work great because for flash 8/16G , @letama modified initramfs
for mounting (.ext4, .squashfs ) -proper !
I believe the solution to root version Archos HDD,is just find a solution to change something in initramfs for a proper mount , after that I do not think it matters where you are place the files system ( /data/media, /data/local , /data/customization - is the same way )
Still believe that /data/media was not chosen at random - when we connect the tablet to the computer we see just Internal Storage ( ..or + SD Card), which is equal to /data/media/....you don't need root, you don't need any other app for look into Internal Storage....
surdu_petru said:
Hi @gen_scheisskopf...
I think ( not sure ...) , that until we find a way for mount proper HDD into initramfs , we can't load any files system ( .ext4, .squashfs, .update ) for Archos HDD !
Click to expand...
Click to collapse
All proper mountpoints are stored in /etc/mountpoints- init reads device name and uses correct mount. The only thing that possibly can be required is
Code:
wait_blk_device storage_$DEVICENAME
(I'm not sure if it's wait_blk_device, will check)
surdu_petru said:
Your test it's work great because for flash 8/16G , @letama modified initramfs
for mounting (.ext4, .squashfs ) -proper !
I believe the solution to root version Archos HDD,is just find a solution to change something in initramfs for a proper mount , after that I do not think it matters where you are place the files system ( /data/media, /data/local , /data/customization - is the same way )
Still believe that /data/media was not chosen at random - when we connect the tablet to the computer we see just Internal Storage ( ..or + SD Card), which is equal to /data/media/....you don't need root, you don't need any other app for look into Internal Storage....
Click to expand...
Click to collapse
Problem is that after android boots all mountpoints change.
Using /data/media may not work- on HDD there may be problems with mounts if /data/media belongs to hdd.
I've chosen /data/local not by mistake:
-android does not touch files placed there (as they may be vendor specific)
-/data/local is chmoded to shell while most of other /data folders are chmoded to root
-running system form HDD may decrease battery life greatly while /data/local is for sure flash memory
-modified initrd check for required files/updates on storage (/mnt/storage) and does not delete possibly necessary archos.ext4.update file (in case of data wipe) so copying those files doesn't change at all- just drag'n'drop on PC
It seems that modified init works for HDD models but more tests are required: http://forum.xda-developers.com/showpost.php?p=22309411&postcount=72
Modified part of init:
Code:
mount_p data
mount_p storage
#Check if system image is present, if not- copy from storage
if [ ! -e /data/local/archos.ext4 ] && [ ! -e /mnt/storage/archos.ext4.update] ; then
cp /mnt/storage/archos.ext4.backup /data/local/archos.ext4
rm -r /data/dalvik-cache
fi
# Do updates if need
if [ -e /mnt/storage/archos.ext4.update ] ; then
rm /data/local/archos.ext4
cp /mnt/storage/archos.ext4.update /data/local/archos.ext4
mv /mnt/storage/archos.ext4.update /mnt/storage/archos.ext4.backup
rm -r /data/dalvik-cache
fi
if [ -e /mnt/sdcard/wipe-dalvik.update ] ; then
rm -r /data/dalvik-cache
rm /mnt/sdcard/wipe-dalvik.update
fi
umount_p storage
# Now boot
if [ -e /data/local/archos.ext4 ] ; then
$LOSETUP `get_mount_info d rfsext4` /data/local/archos.ext4 || log_and_die "Mounting system partition failed"
mount_p rfsext4 || log_and_reboot "Mounting system partition failed"
umount_p rawfs
rootfs_path=`get_mount_info p rfsext4`
umount_pseudo_fs
log "SWITCHING TO REAL ROOT"
exec switch_root $rootfs_path /init
fi
$LOSETUP `get_mount_info d rootfs` /data/local/archos.squashfs || log_and_die "Mounting system partition failed"
mount_p rootfs || log_and_reboot "Mounting system partition failed"
umount_p rawfs
rootfs_path=`get_mount_info p rootfs`
umount_pseudo_fs
log "SWITCHING TO REAL ROOT"
exec switch_root $rootfs_path /init
Changes:
-support only for archos.ext4
-after update a backup file is created in case of data wipe (archos.ext4.backup)
Works on flash model, to be tested on HDD models:
http://dl.dropbox.com/u/14106051/archos/kernel_hdd_test7.zip
EDIT:
As it was just reported- G9 80 HDD does not have SD card slot so earlier idea to use external SD has to be dropped.
Backup & restore of archos.ext4 without wiping data (in case something went wrong with merging changes into the system).
Code:
#backup & restore of system image
if [ -e /mnt/storage/backup.update ] ; then
rm /mnt/storage/archos.ext4.backup
cp /data/local/archos.ext4 /mnt/storage/archos.ext4.backup
fi
if [ -e /mnt/storage/restore.update ] ; then
rm /data/local/archos.ext4
cp /mnt/storage/archos.ext4.backup /data/local/archos.ext4
rm -r /data/dalvik-cache
fi
umount_p storage[...]
When you connect your MIUI device to the computer through USB in File Transfer (MTP) mode (that is, not in Photo Transfer), it also emulates a CD-ROM drive. The ISO image for the fake CD contains a copy of Mi Assistant, a device management tool for the PC, which is in Chinese only and can be downloaded from the Internet anyway. Basically, it's all useless and mildly annoying.
View attachment 3137500
Here's what you need to do to get rid of it:
Step 1. Edit /system/build.prop and add the line:
Code:
persist.service.cdrom.enable=0
Step 2. Edit /init.qcom.usb.rc and where it says:
Code:
on property:sys.usb.config=mtp
(a) Change the first line to remove mention of mass_storage (this is for the CD only):
Code:
write /sys/class/android_usb/android0/functions mtp
(b) Remove these two lines:
Code:
write /sys/class/android_usb/android0/f_mass_storage/lun/ro 1
write /sys/class/android_usb/android0/f_mass_storage/lun/file /data/miui/cdrom_install.iso
Similarly, where it says:
Code:
on property:sys.usb.config=mtp,adb
(a) Change the first line after the above to:
Code:
write /sys/class/android_usb/android0/functions mtp,adb
(b) Remove these two lines:
Code:
write /sys/class/android_usb/android0/f_mass_storage/lun/ro 1
write /sys/class/android_usb/android0/f_mass_storage/lun/file /data/miui/cdrom_install.iso
Step 3. Delete the ISO image file to free up some space.
File location: /data/miui/cdrom_install.iso
And here's how to do it:
Using Android Debug Bridge from the command line:
Code:
adb root
adb shell "mount -o remount,rw /system"
adb shell "echo persist.service.cdrom.enable=0 >>/system/build.prop"
adb pull /init.qcom.usb.rc
Now use your favorite editor to make changes as described above in step 2.
Code:
adb push init.qcom.usb.rc /
adb shell "mount -o remount,ro /system"
adb shell "rm -f /data/miui/cdrom_install.iso"
adb reboot
Using ES File Explorer:
Download from Play Store or the developer's website. Install. Open. In context menu (hold leftmost button for 1 second), switch Root Explorer to On (this will fail). Go back to the home screen. Open Security, Permissions, Root Access. Put the switch next to ES File Explorer to On. Now you can switch back to ES File Explorer, and follow the steps 1-3 above. Use the built-in editor the make changes in the files.
Unknown USB devices when connected in MTP mode
When your device is connected in MTP mode (File Transfer) there are 3 unrecognized USB devices. To check if you have them too, go to Control Panel and choose Device Manager or run mmc devmgmt.msc from the command line (screenshot 1). The devices appear to have no hardware IDs (screenshot 2) and their class number seems to be {c897b31c-e8d2-59e9-a212-ccf0962fe102} (full registry dump provided as attachment).
View attachment 3137478 View attachment 3137479
This problem appears to be caused by the CD-ROM emulation as well: the number of devices will actually increase to 4 when it's switched off following the instructions above, which means there must be one extra step to get rid of it completely. This doesn't seem to cause any problems and the issue appears to be purely cosmetic. If I have time to investigate it further, I will report the conclusions back here. Meanwhile, if anyone has an idea what the cause is, please feel free to share it (might also be a driver issue).
Disclaimer: there might be some mistakes in what I wrote. Please use at your own discretion. This should work with a "developer" stock ROM out of the box, otherwise you'll need to set-up root access first.
Update for a total fix, and a more elegant approach
So the missing link to make the mysterious devices disappear is to edit /init.qcom.usb.rc and where it says:
Code:
case "$cdromenable" in
0)
Comment out (put the # sign) in front of:
Code:
#echo "" > /sys/class/android_usb/android0/f_mass_storage/lun0/file
The best way to make the whole change seems to be to unpack boot.img, for example with Android Image Kitchen, apply the patches (diffs attached), rebuild the image, and flash it. The persist.service.cdrom.enable=0 property can be set in /default.prop so that all the changes are contained within the boot image. In summary:
Code:
unpackimg boot.img
echo "persist.service.cdrom.enable=0" >>ramdisk/default.prop
patch ramdisk/init.qcom.usb.rc < init.qcom.usb.rc.diff
patch ramdisk/init.qcom.usb.sh < init.qcom.usb.sh.diff
repackimg
cleanup
adb reboot bootloader
fastboot erase boot
fastboot flash boot image-new.img
fastboot reboot
@ Aqq123 thanks for the write up, I have a Mi 4C and the iso file is not in /data/miui/ but it still shows up when connecting to pc
Magisk v19.3 on lineageos 16.0 for wt86047
trying to create my first module, no files to replace, just one task: run a remove.sh script
I put following two lines in ./common/service.sh , but there's no file created after boot , seems the service.sh itself never be run at all.
echo -e "\n------------${MODPATH}----------------------------" >> /sdcard/s.txt >&1
sh ./remove.sh
LATESTARTSERVICE=true in ./install.sh --YES
./META-INF/com/google/android/update-binary updated --YES
./module.prop edited --YES
the module installed with no error --YES
manual run remove.sh successfully in terminal after reboot --YES
called from service.sh --NO
need help, THANK YOU!
attached remove.sh
Code:
#!/system/bin/sh
DIRFILE="/sdcard/dir"
if [ -f "$USRFILE" ];then
while IFS= read -r LINE
do
if [ -n "${LINE}" ];then
...
...
fi
I haven't looked at what might be your issue, but you don't need a module for that... Just place your remove.sh script in /data/adb/service.d and give it execution permission.
Didgeridoohan said:
I haven't looked at what might be your issue, but you don't need a module for that... Just place your remove.sh script in /data/adb/service.d and give it execution permission.
Click to expand...
Click to collapse
thanks. but it doesn't work either.
When I manually run the script from terminal, it prompt 'Permission denied.'
But it works after execute 'su' first.
Is this the reason? But how could I authorise root right to the script since it doesn't pop dialogbox at all.
Again, I haven't looked at your script at all, but...
Any scripts run by Magisk at boot will run with superuser permission. That's not your issue...
Might be that the script has to run after boot is completed (if it works while booted but not during boot). You can look for the sys.boot_completed and when it's changed to 1 you can let the script execute.
I use this code in my modules, if it can help
Code:
_SLEEPBOOT=60
# ...
RETRY_INTERVAL=${_SLEEPBOOT} #in seconds
MAX_RETRY=30
retry=${MAX_RETRY}
while (("$retry" > "0")) && [ "$(getprop sys.boot_completed)" != "1" ]; do
sleep ${RETRY_INTERVAL}
((retry--))
done
Didgeridoohan said:
Again, I haven't looked at your script at all, but...
Any scripts run by Magisk at boot will run with superuser permission. That's not your issue...
Might be that the script has to run after boot is completed (if it works while booted but not during boot). You can look for the sys.boot_completed and when it's changed to 1 you can let the script execute.
Click to expand...
Click to collapse
Code:
# Wait for boot to complete
until [ "$(getprop sys.boot_completed)" ]
do
sleep 2
done
insert this code to script but still not work...
after all, found the solution:
don't use '/sdcard/, use '/storage/emulated/0/' instead, don't know why
funnypc said:
Code:
# Wait for boot to complete
until [ "$(getprop sys.boot_completed)" ]
do
sleep 2
done
insert this code to script but still not work...
after all, found the solution:
don't use '/sdcard/, use '/storage/emulated/0/' instead, don't know why
Click to expand...
Click to collapse
Might have worked if you had checked for sys.boot_completed = 1.
But yeah, /sdcard isn't available during boot. To be even more sure it'll work you could use /data/media/0 instead. That's always available (as long as /data is accessible).
Didgeridoohan said:
Might have worked if you had checked for sys.boot_completed = 1.
But yeah, /sdcard isn't available during boot. To be even more sure it'll work you could use /data/media/0 instead. That's always available (as long as /data is accessible).
Click to expand...
Click to collapse
though the script can work alone , I still want make it a module so that could install/disable easier with magisk gui than terminal.
currently I'm add a 'bypass' mode while script load, if volume key pressed repeatly. (like xposed does) but the code can only work after unlock, it seems the getevent can't work after system reboot, before keyguard unlocked. any workaround? thx!
Code:
#!/system/bin/sh
KEYSTRING="KEY_VOLUME"
KEYREPEAT=1
KEYCOUNTS=0
until [ "$(getprop sys.boot_completed)" ]
do
sleep 2
done
setenforce Permissive
echo 300 > /sys/class/timed_output/vibrator/enable
sleep 0.3
for i in `seq 1 4`;
do
EVENT=$(timeout 1 getevent -l -q -c 1)
RESULT=`echo $EVENT | grep -c $KEYSTRING`
input keyevent mouse
if [ "$RESULT" -gt 0 ] ;then
KEYCOUNTS=`expr $KEYCOUNTS + $RESULT`
echo 100 > /sys/class/timed_output/vibrator/enable
fi
done
if [ "$KEYCOUNTS" -gt "$KEYREPEAT" ] ;then
echo 1000 > /sys/class/timed_output/vibrator/enable
fi
Simple, just put your code in the service.sh file of the module instead of a separate script file...
Didgeridoohan said:
Simple, just put your code in the service.sh file of the module instead of a separate script file...
Click to expand...
Click to collapse
can't work. so I put the keypress detection part in a standalone script for debug. just script in service.d folder, not pack to module yet.
if I run the script manually in terminal after keyguard unlocked, everything works as I want
but not when keyguard locked status just after reboot.
funnypc said:
can't work. so I put the keypress detection part in a standalone script for debug. just script in service.d folder, not pack to module yet.
if I run the script manually in terminal after keyguard unlocked, everything works as I want
but not when keyguard locked status just after reboot.
Click to expand...
Click to collapse
I mean the code from your remove.sh file, not the key detecting stuff... That way you can disable the module from the Manager and also from TWRP (or other custom recovery) by placing a disable file in the module directory or enabling Magisk Core Only Mode by placing a .disable_magisk file in /cache.
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.
please, I would like to know where I can find (in Merin)
ro.serialno
ro.boot.serialno
I've already checked on /system/build.prop and there is no trace,
They exist at runtime only as it is specific for each hardware/motherboard.
by running this command I found some files that have inside the line ro.serialno
Code:
grep -rnw '/system' -e 'ro.serialno'
/system/bin/init:21065:ro.serialno
/system/bin/ueventd:21065:ro.serialno
/system/lib64/libadbd_services.so:27042:ro.serialno
/system/etc/selinux/plat_property_contexts:76:ro.serialno u:object_r:serialno_prop:s0
/system/priv-app/Shell/Shell.apk:36675:ro.serialno
/system/priv-app/MiuiSystemUI/MiuiSystemUI.apk:1784453:
/system/priv-app/MiService/MiService.apk:1147774:ro.serialno
/system/priv-app/MiuiScanner/MiuiScanner.apk:1812931:ro.serialno
/system/framework/services.jar:2077492:ro.serialno
So a simple question @VD171 based on your knowledge, is there a way to make some modification on that direction, or I am loosing only time ? thanks