1
Cosmo Communicator - Hardware / Re: Rooting the Cosmo Communicator
« Last post by Varti on July 09, 2026, 03:39:43 am »Hi, glad to read that you have solved the problem!
Varti
Varti
Select language:
News:
Recent Posts
2
Cosmo Communicator - Hardware / Re: Rooting the Cosmo Communicator
« Last post by klampfenfreak on July 01, 2026, 08:20:58 am »Hi everyone,
Just wanted to give a quick update: I managed to solve the issue on my own!
Instead of messing around with fastboot unlocks that would wipe my dual-boot data, I booted into Linux and dumped the original boot image specifically from the ROOTED_ANDROID partition using the direct path via partlabel:
dd bs=2048 if=/dev/disk/by-partlabel/ROOTED_ANDROID of=magisk.img
I then booted into Android, let Magisk Manager patch this specific magisk.img file, and transferred the patched image back. Finally, I booted back into Linux and flashed the patched image manually right back onto the correct partition:
dd bs=2048 if=magisk_patched.img of=/dev/disk/by-partlabel/ROOTED_ANDROID
Now everything works flawlessly, the root check passes, and my standard Android installation as well as the 60GB dual-boot setup remained completely untouched. Thanks for the pointers in this thread!
Just wanted to give a quick update: I managed to solve the issue on my own!
Instead of messing around with fastboot unlocks that would wipe my dual-boot data, I booted into Linux and dumped the original boot image specifically from the ROOTED_ANDROID partition using the direct path via partlabel:
dd bs=2048 if=/dev/disk/by-partlabel/ROOTED_ANDROID of=magisk.img
I then booted into Android, let Magisk Manager patch this specific magisk.img file, and transferred the patched image back. Finally, I booted back into Linux and flashed the patched image manually right back onto the correct partition:
dd bs=2048 if=magisk_patched.img of=/dev/disk/by-partlabel/ROOTED_ANDROID
Now everything works flawlessly, the root check passes, and my standard Android installation as well as the 60GB dual-boot setup remained completely untouched. Thanks for the pointers in this thread!
3
Cosmo Communicator - Hardware / Re: Rooting the Cosmo Communicator
« Last post by klampfenfreak on July 01, 2026, 06:43:27 am »Subject: Cosmo Communicator: "Device failed verification" and no root after V25 update and Magisk installation
Hi everyone,
I am trying to root my Cosmo Communicator on V25, but I am stuck in a loop where the system boots but root is not recognized, and I get a verification error. My device is configured as a dual-boot system with two 60 GB partitions (one for Linux, one for Android).
Crucial preparation steps I already completed:
In the Android Developer Options, I have explicitly allowed OEM unlocking (bootloader unlocking) and enabled USB debugging, as recommended by other users for this process.
My goal:
I am trying to follow the official Planet Computers rooting guide, but I purposefully skipped the initial step of completely re-flashing and wiping the entire device. I must preserve my existing partition layout and dual-boot setup. I only executed the subsequent steps from their guide (flashing the root image and using Magisk) since the underlying partitions were already set up.
Here is the exact sequence of what I have done:
Started with the old version V19 installed.
Manually updated the device to V23.
Downloaded the V25 OTA update from GitHub and installed it via the manual installation method.
Flashed the V25 root image (following the Planet Computers method, but without wiping).
Installed the Magisk app, executed the installation/patching process, and let it reboot as prompted.
After the reboot, the device booted into the recovery menu. I proceeded with a normal reboot from there.
Once the system was up, I ran a root check, but the device was not rooted.
I attempted the Magisk installation process once more.
Since that second attempt, I get the following error message every time I restart the Cosmo Communicator:
"Your device has failed verification and may not work properly. Please download recovery image..."
After waiting 5 seconds, the device continuing to the boot menu allows me to boot into the OS normally, but the root check still confirms that root access is not installed.
It seems that by skipping the full wipe/re-flash from the official guide, the boot image verification (AVB / dm-verity) is now failing, or Magisk is not patching the correct partition due to the dual-boot layout, despite OEM unlocking being allowed. Has anyone successfully bypassed this "failed verification" error on V25 and achieved root without performing the full destructive flash required by Planet Computers?
Thanks in advance for your help!
Hi everyone,
I am trying to root my Cosmo Communicator on V25, but I am stuck in a loop where the system boots but root is not recognized, and I get a verification error. My device is configured as a dual-boot system with two 60 GB partitions (one for Linux, one for Android).
Crucial preparation steps I already completed:
In the Android Developer Options, I have explicitly allowed OEM unlocking (bootloader unlocking) and enabled USB debugging, as recommended by other users for this process.
My goal:
I am trying to follow the official Planet Computers rooting guide, but I purposefully skipped the initial step of completely re-flashing and wiping the entire device. I must preserve my existing partition layout and dual-boot setup. I only executed the subsequent steps from their guide (flashing the root image and using Magisk) since the underlying partitions were already set up.
Here is the exact sequence of what I have done:
Started with the old version V19 installed.
Manually updated the device to V23.
Downloaded the V25 OTA update from GitHub and installed it via the manual installation method.
Flashed the V25 root image (following the Planet Computers method, but without wiping).
Installed the Magisk app, executed the installation/patching process, and let it reboot as prompted.
After the reboot, the device booted into the recovery menu. I proceeded with a normal reboot from there.
Once the system was up, I ran a root check, but the device was not rooted.
I attempted the Magisk installation process once more.
Since that second attempt, I get the following error message every time I restart the Cosmo Communicator:
"Your device has failed verification and may not work properly. Please download recovery image..."
After waiting 5 seconds, the device continuing to the boot menu allows me to boot into the OS normally, but the root check still confirms that root access is not installed.
It seems that by skipping the full wipe/re-flash from the official guide, the boot image verification (AVB / dm-verity) is now failing, or Magisk is not patching the correct partition due to the dual-boot layout, despite OEM unlocking being allowed. Has anyone successfully bypassed this "failed verification" error on V25 and achieved root without performing the full destructive flash required by Planet Computers?
Thanks in advance for your help!
4
Cosmo Communicator - Hardware / Re: Successfully replaced the battery with a third party one
« Last post by pogmommy on June 29, 2026, 02:00:32 am »Hi all, apologies for posting to a long-inactive thread. Wanted to share my experience doing a custom battery swap.
Huge thanks to mifritscher and 346L3 for sharing their battery replacement experiences. Thanks to them I was able to bring one of my Cosmos (which had been dead-on-arrival) back to life. I'd purchased it online as seemingly new-old-stock from a third-party, and it arrived with a bloated battery and showed no signs of life, even when plugged in.
I tried using a Huawei Ascend P6 battery after seeing in daffyduck's thread and the linked article- the Cosmo became more responsive with the Huawei Ascend P6 battery, but consistent with jakfish's comment in that thread, it did not seem to actually charge. It would power on though as if it were charging though, which it would not do with the bloated OEM battery, so that gave me hope that a BMS swap to a new cell would get it working again.
I can confirm 346L3's comment that the BMS doesn't lock up if it loses power- my bloated cell seems to have been in such bad state that my multimeter was reading zero volts from it, so i figured if it was going to lock itself, it would already have done so. So I didn't bother keeping it powered during the swap, and cut away the original cell.
After soldering the new cell to the board, it booted fine and read the new battery as being at 35%, which lined up with the ~3.81V I'd measured from it.
I did not remove the BMS of the newly-installed cell, I just connected its positive and negative wires to the corresponding terminals on the BMS (with a JST connector inbetween but that's not important), which seemed to work fine. I also used a higher-capacity cell (6500mAh) than the Cosmo originally shipped with (4220mAh) since I was unable to get my hands on a 3mm cell with comparable capacity for a reasonable price, and plan for this device to be mostly stationary and for development purposes. For reference, I used a 3.7V 956090 (0.95 x 9.0 x 6.0 cm) LiPo cell, which definitely does not fit in the original housing as it's a little over 3X the thickness of the battery mifritscher linked to, but I'll likely be replacing it with something more reasonable later. I may try looking into 3.85V batteries of similar sizes/capacities made for other phones that I can swap the original BMS onto, if they're easier to get for a decent price.
Apologies for the lack of pictures, with this being my test device this initial assembly isn't particularly pretty, nor does it really show anything you can't see in mifritscher or 346L3's pictures. This was my first time doing work like this on batteries, but I do have soldering/small electronics repair experience and I found this incredibly easy to do.
Huge thanks to mifritscher and 346L3 for sharing their battery replacement experiences. Thanks to them I was able to bring one of my Cosmos (which had been dead-on-arrival) back to life. I'd purchased it online as seemingly new-old-stock from a third-party, and it arrived with a bloated battery and showed no signs of life, even when plugged in.
I tried using a Huawei Ascend P6 battery after seeing in daffyduck's thread and the linked article- the Cosmo became more responsive with the Huawei Ascend P6 battery, but consistent with jakfish's comment in that thread, it did not seem to actually charge. It would power on though as if it were charging though, which it would not do with the bloated OEM battery, so that gave me hope that a BMS swap to a new cell would get it working again.
I can confirm 346L3's comment that the BMS doesn't lock up if it loses power- my bloated cell seems to have been in such bad state that my multimeter was reading zero volts from it, so i figured if it was going to lock itself, it would already have done so. So I didn't bother keeping it powered during the swap, and cut away the original cell.
After soldering the new cell to the board, it booted fine and read the new battery as being at 35%, which lined up with the ~3.81V I'd measured from it.
I did not remove the BMS of the newly-installed cell, I just connected its positive and negative wires to the corresponding terminals on the BMS (with a JST connector inbetween but that's not important), which seemed to work fine. I also used a higher-capacity cell (6500mAh) than the Cosmo originally shipped with (4220mAh) since I was unable to get my hands on a 3mm cell with comparable capacity for a reasonable price, and plan for this device to be mostly stationary and for development purposes. For reference, I used a 3.7V 956090 (0.95 x 9.0 x 6.0 cm) LiPo cell, which definitely does not fit in the original housing as it's a little over 3X the thickness of the battery mifritscher linked to, but I'll likely be replacing it with something more reasonable later. I may try looking into 3.85V batteries of similar sizes/capacities made for other phones that I can swap the original BMS onto, if they're easier to get for a decent price.
Apologies for the lack of pictures, with this being my test device this initial assembly isn't particularly pretty, nor does it really show anything you can't see in mifritscher or 346L3's pictures. This was my first time doing work like this on batteries, but I do have soldering/small electronics repair experience and I found this incredibly easy to do.
5
Site Suggestions, Requests, and Updates / Re: Security certificate expired
« Last post by Varti on June 11, 2026, 09:54:59 am »Thanks for the confirmation, I'll write them back about the issue being solved!
Varti
Varti
6
Cosmo Communicator - Hardware / Re: Rooting the Cosmo Communicator
« Last post by Varti on June 11, 2026, 09:54:06 am »Thanks Radovan for posting this guide! It's important to have information like this stored and preserved. Regardless of when it is posted 
Varti
Varti
7
Site Suggestions, Requests, and Updates / Re: Security certificate expired
« Last post by koan on June 10, 2026, 08:04:41 am »Hi Varti,
I removed the exception I had added to Firefox and opened the site without any problems.
I removed the exception I had added to Firefox and opened the site without any problems.
8
Cosmo Communicator - Hardware / Re: Rooting the Cosmo Communicator
« Last post by Radovan Garabík on June 10, 2026, 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:):
Now I new I was on the right track. What finally (after much, much further trial and error) helped:
There were some files with u:object_r:unlabeled:s0 SELinux label. The command
Reboot, still no baseband, but at least the fstab error is gone.
But there are other SELinux related errorrs:
See other unlabeled files:
So, let’s restore the labels:
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.
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 -lZThere 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 -lZQuote
-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.
9
Sharp Zaurus / Re: Sharp Zaurus zapple Apple II emulator
« Last post by Retrofan on June 08, 2026, 05:01:02 pm »Hi Varti,
Thank you so much for your efforts! I can tell you that you are the only person known to receive a reply from the author on this topic for 10+ years So great job.
The link to YAE is very useful information! Recreating the emulator looks like the way to go. I'm not setup for that currently, nor do I have the knowledge but I do hope to setup a development environment sometime in the future. I believe that I have all the SDK files, tool chains, etc. that I need along with some versions of Linux from that era.
It is surprising that zapple never made it into a feed someplace where it may have survived. The quest continues...
Thank you so much for your efforts! I can tell you that you are the only person known to receive a reply from the author on this topic for 10+ years
So great job. The link to YAE is very useful information! Recreating the emulator looks like the way to go. I'm not setup for that currently, nor do I have the knowledge but I do hope to setup a development environment sometime in the future. I believe that I have all the SDK files, tool chains, etc. that I need along with some versions of Linux from that era.
It is surprising that zapple never made it into a feed someplace where it may have survived. The quest continues...
10
Sharp Zaurus / Re: Sharp Zaurus zapple Apple II emulator
« Last post by Varti on June 08, 2026, 05:45:01 am »The author has answered me, unfortunately it seems we are out of luck:
"Thanks you for your email. I havn't archive my work regarding the emulator. Also, my zaurus has been out of order and won't work now. I am sorry about that."
I'll now try to get in touch with the users who have posted on the forum that they have tried the emulator, one of them has opened this thread:
https://www.oesf.org/forum/index.php?topic=14442.0
Failing that, it could be worth to try to do again a port. Zapple is based on YAE 0.6, that version seems to have been the last one:
https://web.archive.org/web/20241007010758/http://www.netfront.net:6502/
Varti
"Thanks you for your email. I havn't archive my work regarding the emulator. Also, my zaurus has been out of order and won't work now. I am sorry about that."
I'll now try to get in touch with the users who have posted on the forum that they have tried the emulator, one of them has opened this thread:
https://www.oesf.org/forum/index.php?topic=14442.0
Failing that, it could be worth to try to do again a port. Zapple is based on YAE 0.6, that version seems to have been the last one:
https://web.archive.org/web/20241007010758/http://www.netfront.net:6502/
Varti