Getting Edimax EW-7811UN (or rtl8192cufw devices) to work with Chromium OS

Surprisingly easy as it happens!

Firstly boot your device and get to su command line  ([ Ctrl ] [ Alt ] [ F2 ]), log in as chronos and then

sudo su

Then pop in the wireless dongle and review the contents of dmesg.

You should see something along the lines of the following:

rtl8192cu: Loading firmware rtlwifi/rtl8192cufw.bin
rtlwifi: Firmware rtlwifi/rtl8192cufw.bin not available

In order to remedy this, firstly mount the OS read/write:

mount -o remount, rw /

Then create the directory structure and cd into it, and download the bin file

mkdir /lib/firmware/rtlwifi
cd /lib/firmware/rtlwifi/

Remove the dongle and reinsert. Lights on the dongle will now illuminate and you ‘should’ be able to connect to a wireless network! The version I tested against would not scan the network so I needed to add the wireless network manually. Reboot will remember the change so all should be good from that point on.

Any dev server updates will more than likely undo any of the above so please bear that in mind.

Usual caveats around none of this ever working etc.

Share on Google+Tweet about this on TwitterShare on FacebookShare on LinkedInShare on TumblrShare on Reddit

Dev Server Updates now available!

Fed up with constantly installing new Chromium OS version from USB?

Look no further, I now present to you – “The Dev Update Server”

Resplendant with the finest daily compilations, its ready for you to upgrade your installed ChromiumOS to the latest and greatest x86-generic version.

Check the status of the Dev Server on twitter @chromium_bot since the server needs to go offline to build the latest version at around 05:00 GMT daily. Once compiled and presented, the status will say its available.

In order to update go to command line on your deployed Chromium ([ Ctrl ] [ Alt ] [ F2 ]) and log in as chronos with the password of ‘password’ (or whatever your distribution is set to). You can also use SSH.

Then sudo to su

sudo su

Once in the admin shell, update the client with the following:

For amd64  builds
update_engine_client --update --omaha_url=
For x86  builds
update_engine_client --update --omaha_url=
For amd64 special builds
update_engine_client --update --omaha_url=
For x86 special builds
update_engine_client --update --omaha_url=

This will take a while dependant on a couple of things:

  • Whether the image is compiled yet (the dev server creates a sync image on 1st use which can cause timeouts)
  • What other load the server is under.
  • Your bandwidth (some of the updates can be large).

Simply try the update command again if you get an update error or timeout similar to the below:

[1228/] Update failed.

Once its running you should see notifications from the server saying all is fine and progressing:


Finally, the download will begin:


If all goes well, the updates will download and the install will progress to finalising:


This can tale a while (go for a beer whilst waiting) but ‘should’ result in:

[1228/] Update succeeded -- reboot needed.

You should now also be able to update your stateful partition (where dev tools sit) using:

sudo stateful_update

Which in turn should output:

Downloading stateful payload from
 HTTP/1.1 200 OK
 Date: Fri, 28 Dec 2012 15:42:43 GMT
 Last-Modified: Fri, 28 Dec 2012 15:07:27 GMT
 Content-Length: 42236449
 Content-Type: application/x-gtar
 Server: CherryPy/3.1.2
 Connection: Keep-Alive
Successfully downloaded update
Performing standard stateful update.

You ‘should’ be able to use the process above to update Hexxxeh and others vanilla builds as well but this is (as ever) completely untested.

Subsequent updates for the OS and stateful partition will now automagically point to the new dev server (you can change using the –omaha-url noted above) so all you need to do is:

update_engine_client --update


sudo stateful_update

Finally, in all cases, reboot your client!

Usual Caveats, E&OE stand. The Update Server could work fantastically and make you more attractive to other humans/species from other worlds as well as updating your base build perfectly. It could also create a black hole of NGC 4889 proportions and end the world as we know it as well as bricking your install completely. You have been warned!

Further details and notes available

Share on Google+Tweet about this on TwitterShare on FacebookShare on LinkedInShare on TumblrShare on Reddit

Getting Logstash to run as a daemon

Currently evaluating Logstash and its centralised log management facilities. So far its looking like a good candidate for replacement of far more expensive utilities and seems very nippy when searching. The search query syntax is well documented so its very easy to use once set up.

As ever, using the nice and simple approach to get it working in the first instance as a standalone server. Then needing to keep the engine running for long term testing, its obviously better to run as a daemon. This was a bit of a cludge so noted for ref.

Cribbing and creating the following:

sudo vi /etc/init.d/logstash

Copy the contents of the github link. A few small changes are required:

DAEMON=/usr/bin/java #obviously!
ulimit -n 32000 #allows elastic search to hold more than the default 1000 files open
ARGS="-Xmx$JAVAMEM -Xms$JAVAMEM -jar /opt/logstash/logstash-monolithic.jar agent --config ${CONFIG_DIR} --log ${LOGFILE} --grok-patterns-path ${PATTERNSPATH} -- web --backend elasticsearch:///?local"

This last sections tells the engine to start a web server (port 9292 default) and also use the local server as the elasticsearch provider. Everything is therefore running on one server in this instance which also maintains syslog for all other devices on the network.

Create the new user to run as:

sudo adduser --system --disabled-password --no-create-home --group --quiet logstash

Allow the user to read syslog files (probably a far better way to do this but I am not concerned about security at the moment)

sudo usermod -a -G adm logstash

Create all the directories mentioned on the script:

mkdir /opt/logstash/
mkdir /etc/logstash.d/
mkdir /var/log/logstash/
mkdir /opt/logstash/patterns/

CHOWN the directories as per the following example:

sudo chown -R logstash:logstash /etc/logstash.d/
sudo chown -R logstash:logstash /var/log/logstash/
sudo chown -R logstash:logstash /opt/logstash/

Download the jar file and rename:

sudo wget
sudo mv logstash-1.1.0-monolithic.jar logstash-monolithic.jar

Add the config below to /etc/logstash.d/mylogstash.conf

input {
 file {
 type => "linux-syslog"
# Wildcards work, here
 path => [ "/var/log/*.log", "/var/log/messages", "/var/log/syslog" ]
# file {
# type => "apache-access"
# path => "/var/log/apache2/access.log"
# }
# file {
# type => "apache-error"
# path => "/var/log/apache2/error.log"
# }
output {
 # Emit events to stdout for easy debugging of what is going through
 # logstash.
 stdout { }
# This will use elasticsearch to store your logs.
 # The 'embedded' option will cause logstash to run the elasticsearch
 # server in the same process, so you don't have to worry about
 # how to download, configure, or run elasticsearch!
 elasticsearch { embedded => true }

As you can see, all we look to do in the first instance is syslog search only. I have removed the apache logging for the moment (basically since its not installed on my test server!)

Make the logstash script executable and start the engine

sudo chmod +x /etc/init.d/logstash
sudo /etc/init.d/logstash start

If all is good, you can

 tail -f /var/log/logstash/logstash.log

And hopefully see the engine start and the fact its logging syslog content as it arrives at the server.

Then, give it a few minutes, open your browser, then hopefully you will have a log crawler and searcher! Ill be leaving this running for a few weeks to see how it scales so will report back on performance and any additional tweaks required.

Share on Google+Tweet about this on TwitterShare on FacebookShare on LinkedInShare on TumblrShare on Reddit

The general witterings of a nerd