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=0So I tried (suggested by GPT-5, distilled to the crucial commands:):
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:
cd /mnt/vendor/nvram/md; ls -lZThere were some files with
u:object_r:unlabeled:s0 SELinux label. The command
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:
logcat -d -b all|grep ‘avc: denied’See other unlabeled files:
cd /mnt/vendor/protect_f/md; ls -lZ-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:
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.
