[ 20.900878] device eth0.1 entered promiscuous mode
[ 20.905758] device eth0 entered promiscuous mode
[ 20.940478] br-wlan: port 1(eth0.1) entered forwarding state
[ 20.946310] br-wlan: port 1(eth0.1) entered forwarding state
[ 22.939289] br-wlan: port 1(eth0.1) entered forwarding state
[ 24.809528] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: 8701d944
[ 24.823293] Rebooting in 3 seconds..
This Kernel panic is a known bug of the closed source MediaTek WiFi driver. Now we know it can not manage if there is a WiFi AP in the neighborhood with some Unicode character in its SSID.
Onion @administrators deeply kept silent about this bug.
It seems Onion's new WARP CORE driver (also closed source ???) can manage this situation.
Unfortunately Onion @administrators do not say too much about this bug feature (as usual ;-).
@György-Farkas kernel was corrupted for sure, that's something I can tell you with honesty. The device was literally dead, only after inserting a microSD card with a new firmware my device was able to update itself and become functional.
Well... no one but you should know if this correct (or not ;-)
@Lazar-Demin as always, thanks for the response! I literally keep this open waiting for developments as they occur ;)
I am assuming that this information will come, but you seemed to point out something I was worried about:
I have a bunch of static and/or dynamic libraries I want to link with, but without control of a makefile, I can't ensure the resultant application is built/linked properly. This is a slight downside, but, I can just build something that requires static libs myself, at that point, as I'd have more capabilities myself then cloud compile would actually give me.
To that end, I just realized that I could extend the docker container I made up for nodejs compiling to utilize the toolchain and create a arbitrary programs given a directory filled with makefiles/sources/static libs.
Nominally, I could mount a directory of a project via -v flag to draw in any git repo for building in my toolchain container. I could then have a build hook/script within the container or in the git repo that, post-build step, POSTs the results to onion cloud for loading and installation to the omega. This would entail that I also, along with mounting the project directory, perhaps mount the credentials directory for the specific API key I want to post to. . .
Love it! Now that onion cloud/ubus/api integration is up, I feel the community can move at a much faster pace. I feel, though, that perhaps you should invite and open up your design meetings to members of the community (as much as you can without sacrificing your competitive edge) so that community advocates can do this sort of documentation and whiteboarding for you ;) I mean, I'm happy to spitball all my good ideas and all, but I feel you all should get to your core business and allow critical functions to be taken over by your dedicated and fanatical community.
Keep up the good work!
Looks like your connection to Community was lost, please wait while we try to reconnect.