On Yun: I want to use, in place of Bridge, a software with a similar function, based (on the Linux side) on a lightweight PHP implementation of websockets.
I have already implemented a prototype of this software, which I call GiBridge; it is working together with a sketch (which contains the ATmega half of GiBridge), but this somewhat disturbed by:
messages coming from the kernel (I have revisited them with dmesg; they are not limited to the startup phase);
echo of anything sent from the ATmega to the Atheros.
For info to anybody who may wonder why I am doing that: to have more speed than REST and because I want to talk with my Yun (across the net) from web browser as well as from other software (I have made a partial - but working - websocket implementation for Matlab).
Although I am filtering out this data trafic, it is nevertheless disturbing.
Perhaps modifying inittab (disabling the line "ttyATH0::askfirst:/bin/ash --login") may help, but I would prefer not to do that, if possible.
Unfortunately I am not at all expert of Linux in general, and still less of OpenWRT in particular; for me it is also difficult (I tried, anyway) to read the Bridge code in search of a solution (because Bridge authors probably have been facing this problem..).
Yes, this would be a great step for using the Yun with websockets. I find myself in the same position.
Everything up and running in place to use this as a monitoring tool for workplace prototypes and test/service use, but frustrated by this bottleneck.
I think if it could be done, then somewhere deep in the channels, there would be some info. Hopefully more light will be shed.
For my part, all day communication (bi directional) can be fine ( albeit slightly choppy data flow at 300mS sampling), but, hit a glitch and all serial communication will stop. I tried syncing to no avail, and finally am just to about to add an external AND'ing of the serial lines which. after a delay, will reset the sketch and kick it back to life. If I could monitor and understand what and why, maybe this could be overcome. A crude fix, but it does what I need for now, until one of the gurus (with great respect) shows us the easy way!
Thank you both, Roffey and arbor, for your interest in my question.
By the way, few minutes ago I have messed up something in my Yun, resulting in:
"Kernel panic - not syncing: Attempted to kill init!"
Therefore I am now reading discussions and documentation on this problem.
I fear this kind of problems and is also for this reason I was trying to avoid what to my eyes looks as a "for-experts-only-work", like disabling the console on ttyATH0; after all, Bridge do not do that..
Anyway, now that I am obliged to study some of these frightening things, may be I will change mind and reconsider that solution.
I am still curious: why Bridge did not adopt this solution and how does Bridge overcome the problem?
you have opened my eyes not only on the solution to my particular problem, but also to what seems to promise a lot exciting opportunities… For me, as a not Linux expert, there is a lot to study (I prefer, when I can, to try to understand, and avoid blind use of recipes; I only hope I will be able to!).
If I may take the opportunity to have one more advise from you: now I need to (1) recover from “Kernel panic - not syncing: Attempted to kill init!” (2) to try to implement your solution and I am also tempted to (3) upgrade to 1.3 as suggested by http://forum.arduino.cc/index.php?topic=235360.0; I got the feeling that the logic order would be (1) upgrade, that I hope, would also solve “Kernel panic”, then (2) Extroot and two inittab files:
Am I right? (my “Kernel panic” is probably the consequence of my playing around, executing something from /bin and /sbin without imagining this might be dangerous…(should not an executable require at least a parameter before doing something dangerous?)).
I understand that my “Am I right?” question is now a bit “off-topic”, but I am confused how to proceed, so please excuse me…
Thank you too, mantissa00.
I had to suspend my work on Yun for one+ day (my duties as grandfather of a 3.5 months child:-).
In order to avoid mixing up different things, I decided to proceed as follows:
(1) restoring my Yun to the original out-of-the-box status; this I have done following http://forum.arduino.cc/index.php?topic=195589.0, apparently with success;
(2) reinstalling php, that I had installed before crash but has been (of course) wiped out by (1); this is in progress
(3) buying a new Yun in order to have two "test-bed" (may be upgrading to 1.3 on one and two-inittab on another); this should be delivered in few hours from now;
I will keep recording the story in this thread; I feel this is my duty as thread initiator... but may be I need some days..(I need studying, you know?) and may be I need some extra help...
After having struggled several hours reading various OpenWrt docs:
I have to say - alas - that I am not satisfied with the level of understanding I was able to reach (I said I am not a Linux expert); I think I got the general idea and I think I can (and I will) apply "the recipe", but there are many areas on which I would greatly appreciate further help.
Among all the questions crowding my head, I selected these:
in the lines to be added to /etc/config/fstab, the "option target" is specified as "/" and the device as "/dev/sda1"; I think this is has a more or less equivalent meaning of a "mount /dev/sda1 /" command; but then the "/dev/sda1" has to be existing (under "/") before that fstab is "executed"; correct?
If it is so:
does this mean that and old "/" is being replaced by the content of the filesystem contained in (the old) "/dev/sda1", becoming the new "/"?
and is then (i.e. after fstab has produced its effect, i.e. after reboot) possible to return to the old "/" via a umount and without a second reboot?
is it possible to have anyway access (without doing umount nor reboot) to the content of old "/"?
In my understanding the "tar ..." line is substantially a "copy" operation.
If it is so, why not to use simply a "cp"? to which advantages?
the dot in the mean of that line should be a kind of "exec"; isn't it? but it is followed by a pipe.. I am confused...
I have realized that the topic of this thread has changed along the way; also I have had no success in understanding the extroot "theory", nor in (almost) blindly applying the recipe (although I have learned something about ramfs (and tmpfs), about boot process, etc); no fdisk nor mke2fs nor nano were available on my Yun (Barrier Braker factory installed; think this unavailability is normal); I have done some of this preparatory work for the SD card on my Ubuntu (SD was sdb there), but something went wrong later, when - back to Yun - I tried to tar-copying the necessary directories and files.
I eventually decided to give up (for the time being) with the extroot, to comment out the terminal related line of the "real" inittab, to install coreutils-stty and to control the serial line options (with exec("stty ..")) in php.
Therefore I think that this thread should be considered dead (at least for what I am concerned); I will return to extroot in the future (after further study) and probably open a new thread (with the appropriate title!).
Thank you very much, Federico. I will soon try to follow the extroot part of the tutorial.
Can you please confirm that I have to upgrade the Yun image before proceeding (I have not yet done the upgrade, in the fear to make mistakes and damages)? I thank you in advance for this.
After having looked at the upgrade procedure I uderstood it is foolproof and I felt stupid with my fears...
Thanks again to everybody!