How to reduce non-Bridge data trafic on the inter-processors serial line ... ?

...without editing inittab?

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..).

Please, please help!

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!

I'll keep watching this with great interest.

For what you are asking ,you do have to disable "ttyATH0::askfirst:/bin/ash --login" in /etc/inittab
Comment it out and reboot.

The Yun bridge communicates with the Linux console. Turning this off will give you straight serial between Linux and 32u4.

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?


If anyone knows of any better solution, I'd very much appreciate if you share the info.

Not better solution but work around.

Rootfs on External Storage microSD card (extroot)

[OpenWrt Wiki] Extroot configuration

Edit /etc/inittab at Rootfs on microSD card, comment out or delete:

#ttyATH0::askfirst:/bin/ash --login

Whenever you need access serial port again, just remove microSD card and reboot.

Now you have 2 copy of "/etc/inittaba".

One at flash is impact, one at MicroSD is comment out.

Thank you very much, sonnyyu!

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; 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…

i think that yes upgrading will solve the kernel panic issue for sure your because it will delete everything in your yun

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, 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;
(4) ..?
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...

Please help me to understand..

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!).

Thanks to whoever has had interest in the thread.

Just seen this thread. If you wish to extend yun disk space using extroot, please follow the tutorial

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!