Author Topic: Rooting the Cosmo Communicator  (Read 192615 times)

TauPan

  • Newbie
  • *
  • Posts: 43
    • View Profile
    • http://
Re: Rooting the Cosmo Communicator
« Reply #165 on: January 15, 2022, 11:21:41 am »
I've just stopped following this topic since I've been using the official planet procedure for rooting and I suggest everybody to do the same.

Instructions for upgrading magisk are in a different thread, which I'm still following.

forcella

  • Newbie
  • *
  • Posts: 6
    • View Profile
Re: Rooting the Cosmo Communicator
« Reply #166 on: January 31, 2022, 03:59:00 am »
I've just stopped following this topic since I've been using the official planet procedure for rooting and I suggest everybody to do the same.

Does this mean that the problem with the version of Rooted Android provided by Planet that does not recognise the SIM card has been fixed? As I understand it, the status quo is still that you have to manually root the system for SIM card recognition to work.             

Radovan Garabík

  • Newbie
  • *
  • Posts: 28
    • View Profile
Re: Rooting the Cosmo Communicator
« Reply #167 on: Today at 07:04:16 am »
Yes, I know what year it is :-)

Anyway, writing this because it might still be helpful.

I soft bricked my second Cosmo some two years ago (basically, I applied the v25 root patch, not noticing the OTA upgrade is not working anymore and the firmware remained v23) and recently found the time to look into it properly. Unbricking it was an ordeal that is good for a separate writeup, but finally I succeeded and I had a booting, rooted v23 (multiboot). However, IMEI was empty and baseband unknown.

This required rooted device, with either termux+tsu or adb shell su -c (does not matter much which one).

What I did (took a LOT of trial and error!):

Since the baseband was unknown, almost all the guides on IMEI restoration were useless (first fix the baseband, then we can check IMEIs).
I did not have backups of nv{ram,data,cfg} partitions from before the bricking, but I managed to make backups while bricked.

There are strong hints all over the internet the missing baseband can be caused by mismatched boot/system/vendor partitions. Well, since I could boot only into rooted android, and the normal boot kept rebooting, and /proc/last_kmsg displayed verity errors for /vendor, I checked /vendor/build.prop on the Cosmo and on the downloaded v23 firmware (https://support.planetcom.co.uk/index.php/Cosmo_Android_Firmware_Manual_Installation). The one on the Cosmo had  ro.vendor.build.date a day before the downloaded firmware. Probably the final OTA upgrade was not done in time, before the server went down.

So I OEM unlocked and fastboot flashed the downloaded vendor.img. This wiped out the data, but the Cosmo booted in both rooted and normal mode. Still no baseband, though.

Looking through logcat -c -b all, i noticed a lot of lines like property_get("vendor.service.nvram_init") = , read_nvram_ready_retry = ... (with ever increasing number)”.

Looking still through logcat -d -b all, I noticed nvram_daemon tries to write (?!) to fstab.mt6771 on the nvram partition: auditd : type=1400 audit(0.0:955): avc: denied { write } for comm="nvram_daemon" name="fstab.mt6771" dev="auditd : type=1400 audit(0.0:955): avc: denied { write } for comm="nvram_daemon" name="fstab.mt6771" dev="mmcblk0p7" ino=16 scontext=u:r:nvram_daemon:s0 tcontext=u:object_r:unlabeled:s0 tclass=file permissive=0" ino=16 scontext=u:r:nvram_daemon:s0 tcontext=u:object_r:unlabeled:s0 tclass=file permissive=0


So I tried (suggested by GPT-5, distilled to the crucial commands:):
Code: [Select]
setenforce 0
stop vendor.nvram_daemon
start vendor.nvram_daemon
Lo and behold, the baseband appeared after some seconds!

Now I new I was on the right track. What finally (after much, much further trial and error) helped:
Code: [Select]
cd /mnt/vendor/nvram/md; ls -lZ
There were some files with u:object_r:unlabeled:s0  SELinux label. The command
Code: [Select]
restorecon -R -v /mnt/vendor/nvram/md fixed the labels.

Reboot, still no baseband, but at least the fstab error is gone.

But there are other SELinux related errorrs:
Code: [Select]
logcat -d -b all|grep ‘avc: denied’
See other unlabeled files: 
Code: [Select]
cd /mnt/vendor/protect_f/md; ls -lZ

Quote
-rw-rw---- 1 radio radio u:object_r:unlabeled:s0             232 2019-02-14 10:12 MT00A001
-rw-rw---- 1 radio radio u:object_r:unlabeled:s0             232 2019-02-14 10:12 MT00B001
-rw-rw---- 1 radio radio u:object_r:unlabeled:s0             106 2019-02-14 10:12 MTFW_000

So, let’s restore the labels:
Code: [Select]
restorecon -R -v /mnt/vendor/protect_f/md

The baseband is fixed, MEID and IMEI appear, both in rooted and normal boot.

This was quite a walk and I learned much more than I like about Android partitions, SELinux policies, ril daemons and whatever. ChatGPT was helpful, but it quite insisted on flashing original firmware, on restoring nvram partition, on checking crashed ril daemon all over again and again. But it had enough hints for me to know what to look for.
« Last Edit: Today at 07:14:21 am by Radovan Garabík »