The center just disappears when trying to start on my wife’s Mac. On my PC, I get some weird complaint about 4755 mode of sandbox. Yuck! Please, either OTA, or let us drop an OS image into its storage when it’s mounted on a PC, and then it just installs it on next boot. This center thing is a train wreck, sorry to tell you that!
3 Likes
@vandys Thanks for the feedback. Looks like you’re experiencing some isolated issues that have not been reported by other users. Do you have the most recent Mudita Center installed?
1 Like
If your PC says things about a mode of 4755, am I correct in assuming you specifically mean “GNU/Linux PC” not “Windows PC”? If so, you may have some luck running Mudita Center with the “–no-sandbox” option. Either add this to the command line in the desktop shortcut (if you have one), or run Mudita Center by opening a terminal and adding the option, e.g.:
./mudita-center --no-sandbox
(replace “mudita-center” with whatever the filename of the executable actually is).
If it still doesn’t run, try running as root, or chmod-ing the actual device that corresponds to the Pure (possibly /dev/ttyACM0 or similar), to 777, to see if it’s some sort of permissions issue.
For me, I can’t run the Center without using the “–no-sandbox” option. It’s something to do with Mudita Center being an electron app.
3 Likes
Thank you! --no-sandbox did the trick here (along with chmod’ing ttyACM0 to 666). Now running 1.4.0.
2 Likes
@forest_cat I was just about to post about having to chmod /dev/ttyACM0 to 777, but you beat me to it. 
I couldn’t figure out what was going on until I ran Mudita Center from the terminal and I saw the “Error: Permission Denied” message.
2 Likes
No, never worked on the Mac. I’m glad I have an updated phone, but I still hope Mudita will think more about how their users can live with their phone without needing apps on PC’s. Thanks again to forest_cat for the workaround!
2 Likes
I understand there are licensing complications but there really needs to be a way to directly flash an image to the emmc, especially since there’s currently no way to recover from a brick
2 Likes
For me, it was sufficient to add my user to the dailout group to have r/w access to /dev/ttyACM0.
I’m also interested in directly communicating with the CDC ACM Data/Control interfaces with serial communication tools. I would like to retrieve the logs manually. I tried many things, including a more generic driver:
sudo modprobe -r cdc_acm && sudo modprobe usbserialvendor=0x3310 product=0x0100
see also USB cdc_acm driver not assigning Data interface to any port
Yesterday I gave up and I took a deep breath knowing that trying to dig into an electron app’s code would be a pain. And so I started reading the mudita-center/packages/pure source and tried it out.
I ended up updating the whole thing to use Javascript modules just to get that bit to work (using node v14.17.3, npm 6.14.13). But alas, it is just the tip of the iceberg; I’ll need to be able to find out how get-app-logs.request.ts (from the main app) works.
it uses a electron-better-ipc
ipcRenderer.callMain(AppLogsEvents.Get, 15000000)
… and in registerAppLogsListeners there’s a clue about the filename matching ^mc-.*\.log$ and path being someplace referred to with "appData"/@mudita, downloaded in chunks of MaxSize=15000000.
On my linux machine these logs are stored locally in ~/.config/@mudita/mudita-center-app/logs. Still, I want to be able to retreive them with minicom/screen/… rather than relying on an over-engineered electron app that is in constant risk of irrevocable deprecation.
3 Likes
Nice approach! There’s not so much people which wanted to do the reverse engineering to be able to retrieve the logs
We’re currently working on bootloader-related things, so a little sneak-peak: it should be possible in the future to update the phone using a package dropped on the phone via USB. It should be possible also to retrieve logs this way 
3 Likes