Wednesday, May 18, 2016

Acer Aspire Ubuntu "Freezing" Issue (Ubuntu 14.04, 16.04).

Starting from late last year, and continuing into the time of writing (May 2016), there have been several long threads on the kernel bug tracking system (, the Ubuntu Forums and Launchpad with dozens of infuriated Acer Aspire users experiencing spontaneous, randomly-timed freezes which affect Ubuntu 14.04 (Trusty Tahr), Ubuntu 16.04 (Xenial Xerus), and perhaps earlier releases too (although I cannot find any evidence for this). 

One user tried downgrading his kernel; another upgrading his kernel; both to no avail.  Later another user reports it to be a "...horrible bug affecting BayTrail users", with "little activity from Intel or kernel devs to fix it".  Bay Trail is an an SoC architecture common on many Acer Aspire machines. 

The good news is that there's one solution which truly works; the bad news is that it will severely affect your battery life.  So don't chuck out your laptop, but remember to put that power supply into your bag before going to Uni or work.

Here's the fix.  Add the following parameter into Grub:


When altering kernel parameters you should always 'test' it out first before applying it permanently.

To 'test' out the kernel parameter enter into grub (press "SHIFT" repeatedly during your computer's POST (power-on-self-test) phase) to enter grub and you should enter a GRUB screen which looks something like this:

It might look different depending on your desktop environment.  I use Ubuntu Mate and mine looks like this:

As you can see the options are still the same; they just look different.

Select the option which your normally boot from and press 'e' to edit it.  Locate the line mentioned earlier beginning with 'linux', and add the new bootarg  intel_idle.max_cstate=1
(sometimes also called a "boot parameter" or bootparam) somewhere towards the end of the line.  Press ctrl+x or F10 to boot using this param.  If the kernel can boot successfully without any issues and you can login, you know this fix is safe to apply for good and for every time you reboot your system.

Type the following command into your terminal:
sudo vim /boot/grub/grub.cfg

Make the same modification that you made from the Grub screen, save and exit.  You will most likely need to save with "w!" because grub.cfg is a read-only file.

Now this bootarg will be set for the next time you reboot and every subsequent reboot; and hopefully for you, the freezing issue will be gone.  But at what cost?  We mentioned earlier that there was a power-consumption side effect to this fix.  It has to do with a CPUs "C-states" and "P-states".

"C-states" are "power consumption states" and can be thought of as different levels of "sleep".  A CPU, or any one of its individual cores, if it is not currently doing anything would effectively be "driving around in circles", which wastes power.  The solution to this is that CPUs have different "C-states" starting from C0 right up to Cn where n is the highest C-state.  The higher the C-state level and the higher the value of n, the lower the transistors' quiescent (resting) voltage is, and the lower the transistors' switching frequency is; both of which drastically affect power consumption.  CPUs enter high levels of "n", during longer periods of "doing nothing".

Looking back at the fix we applied, we have limited our Baytrail chip's C-state to "1" (intel_idle.max_cstate=1).  One could only deduct from this fix that entering into one of the higher C-states or exiting out of them is what is causing the kernel to freeze.

So-called "P-states" are to do with performance.  During periods where the CPU is executing tasks, but the CPU utilization is not 100%, the CPU may enter into high "P-states"  in order to further save power.

Saturday, January 2, 2016

Logwatch for a Ubuntu 14.04 public-facing SSH sever

The following post will show you how to set up Logwatch on a Ubuntu machine with a public facing SSH server, so that every day you are e-mailed a daily summary of stats, as per the screenshot below.  In a separate blog post, I will include a very easy mechanism to block the offending IP addresses of repeated failed logins.  This might all sound very daunting, but it is in fact, very easy to set up.  So without further ado, let's get started.

This post assumes that you are dealing with a public-facing SSH server.  That is, a small or home office Ubuntu machine which you are able to ssh into from the outside world.

This post will also assume you are using Ubuntu 14.04.x LTS.  The advice contained within this post may also work for other Ubuntu versions.

If you are not already running an SSH server on your Ubuntu machine, it's very easy to get it up and running;

sudo apt-get install openssh-server

After it finishes installing, your system will automatically get it up and running (without rebooting).  You can check for the existence of a running server with a simple grep.

ps aux | grep sshd
root      6958  0.1  0.1  61372  5048 ?  Ss   15:02   0:00 /usr/sbin/sshd -D

Note: The rest of this post assumes you can ssh into your machine from the outside world.  For example, you should be able to ssh into your machine using an app your mobile device.  If you can't, then there's something blocking your Ubuntu machine from being accessible to the outside world, and you'll need to address that problem before continuing with the rest of this post.  If your Ubuntu machine resides at home behind an ISP-provided router, you will most likely need to research what port forwarding is, and learn how to set that up on your home router.

Your SSH server's configuration file (config file) lives at /etc/ssh/sshd_config.  There are various options you can set here such as changing the listening port, allowing or disallowing root logins, and so on.  You can look at man sshd_config or google for "sshd_config options" for more info.  Every time you edit this file you will need to restart your SSH server.

sudo service ssh restart


rsyslog is the system logger which comes with Ubuntu by default.  You'll want to modify its configuration file so that it redirects all messages related to your SSH server to a separate log file.

Add the following line (anywhere) to your /etc/rsyslog.d/50-default.conf:

# Redirect sshd messgaes
if $programname == 'sshd' then /var/log/sshd/sshd.log

Every line beginning with a hash is a comment.  After modifying the file, restart the service.

sudo service rsyslog restart

After that, you'll notice that every time you try to remotely log in to your Ubuntu machine via ssh, bungle the username or password, disconnect from the server, start, stop or restart the sshd service, some diagnostic messages will appear in /var/log/sshd/sshd.log.

For a while, these messages might seem informative and and useful, but over time the messages will grow out of control and be too cumbersome to manage and analyze.  This is where logwatch comes in handy.

 sudo apt-get install logwatch

When it comes up with a graphical prompt, choose "Internet Site", as we will later be using SMTP.  Change the System Mail Name to any name of your choosing.  You can choose a name which describes your machine.  Use your favourite text editor to create the file /etc/logwatch/conf/logfiles/sshd.conf.  This file only needs to contain one line:

Logfile = /var/log/sshd/sshd.conf

Now open the following file with your editor:

In that file you'll find a section starting with "Service = All".  Comment out all the "Service =" lines (including Service = All) and add in your own line at the bottom, just for our ssh server;

Service = "sshd"

Also change the line #mailer = "/usr/sbin/sendmail -t" to mailer = "/usr/sbin/sendmail" (we will install this program in the next section).

The range parameter should be set to to 'today', the MailTo should be the name of your email address, and and MailFrom can be anything.

As you might recall from the beginning of the post, logwatch e-mails you an easy-to-digest summary of the logfiles on your system which your system logger produces.  For this, logwatch is going to need a way to send out emails.  The next section details this.  For reasons which will become apparent soon, you will need to set yourself up a fresh email account (in this post I will be using a Gmail account).

Proceed to install an SMTP (Simple Mail Transfer Protocol) client on your machine;

 sudo apt-get install ssmtp

Now edit the configuration file, /etc/ssmtp/ssmtp.conf.  Delete all the lines and start over, like so:
'root' should be replaced with your email address, and so on.  During this step, you're going to be entering in your password as raw text.  So as I mentioned in the previous section, it's safest to open a new e-mail account dedicated just for logwatching.  Save and close the file.

Test your setup
At this point everything should be up and running.  Execute the following line from your terminal (no root permissions required), and within a few seconds, you should receive an email on your designated logwatch email account.

# /usr/sbin/logwatch --mailto

If you don't receive any e-mail, make sure there's some activity during "today" inside your /var/log/sshd/sshd.log file.  Generate some activity by (eg. by logging in and logging out remotely), and then after that, execute the above command again.

If the above command works and you do receive and e-mail, there's nothing left for you to do.  Every day at a fixed time (or whenever you power on your machine), you will receive an e-mail generated by logwatch and sent by ssmtp which will look like the example at the beginning of this post.

Monday, August 17, 2015

Sougou Pinyin v.1.2.0 on Ubuntu 14.04 (Trusty Tahr)

Sogou Pinyin, under its Linux help page suggests that all you need to do for 14.04 is just download the .deb file, double-click it, and install it via the Software Center.

Figure 1: Installation instructions for Ubuntu 14.04 LTS.

But there are some posts hereherehere of people having trouble getting Sougou Pinyin to install properly that way.

For a lot of people the fix seems to be to remove the daily build or nightly build ppa, remove fcitx, and re-install fcitx via Ubuntu's standard repositories (see the links above).  People tend to be getting this famous "Invalid Entry: line 150 missing '='" error.

Under my fresh installation of Ubuntu 14.04 LTS, the above solutions didn't work.  Instead, in order to get Sougou Pinyin working I had to do quite the opposite.  I had to do the following steps:
  1. Remove the fcitx which came from Ubuntu's standard repositories.
  2. Install the nightly build ppa (sudo apt-add-repository ppa:fcitx-team/nightly)
  3. apt-get update.
  4. Install fcitx again (this time it will come from the nightly build repository).
  5. From the command line: sudo dpkg -i sogoupinyin_1.2.0.0056_amd64.deb
  6. Add the following 4 lines to your ~/.xprofile (I had to create one, because one didn't exist):export XMODIFIERS=@im=fcitxexport
  7. Then finally reboot, and everything is working!
Figure 2: Sogou Pinyin in action on Ubuntu 14.04.


fcitx version:
kernel version: 3.16.0-45-generic
sougou pinyin version: sogoupinyin_1.2.0.0056_amd64

Tuesday, June 23, 2015

What is the colon equals sign ( := ) in makefiles?

Andrew (2015/06/23):  I posted this article on a blog many months ago, which has long since disappeared off the internet.  A few people found it useful at the time, so I decided to repost it here:

In Linux Makefiles, you will often see a notation which looks like this:
This is called "expansion assignment".
So what's the difference between expansion assignment and ordinary variable assignment (=)? Let's get straight into a coding example:
So nothing unexpected or unusual here! But lets try the same thing using expansion assignment ( := ):
Oh no! It appears that we have a frog instead of the porcupine we wanted. So what happened?
When using the equals sign the variable is only expanded when used. In other words, when we run test.

In the second example we used ":=".  This means that the variable is expanded at the time of assignment. If we want to see PORCUPINE again in the second example, we need to make a slight modification to it:

Sunday, May 17, 2015

Custom DST on Linux via the POSIX TZ environment variable

Fig 1: Geographical regions currently using DST (in 2013), in blue and orange.
Image credit:   TimeZonesBoy (Own work) [CC BY-SA 3.0 (], via Wikimedia Commons

If you are reading this article, you are probably writing software for, or porting Linux on devices that other people will use.  People who use Linux on their general purpose Desktop machines have no interest in fiddling with custom timezones or custom DST.  Doing so will upset your web browser, among other things.

But for those of us who have to worry about custom timezones, here is a 'getting started' guide that may help.

First of all, disambiguation of DST terminology should help a lot (at least it did for me).  Below is a diagram of what happens/happened to the clocks in Melbourne, Australia, for the year 2015.

Fig 2: DST time in Melbourne, AU, 2015.

The blue part represents what we call "standard time" or STD; or in other words, where the clocks would be all-year-round if DST didn't exist (which it arguably shouldn't).  The yellow part represents "daylight savings time" or DST.

Different geographical locations have different names for their standard time and daylight savings time.  Stockholm (Sweden) is using so-called "CEST" (Central European Summer Time) during DST, and "CET" (Central European Time) during its STD period.  Important note: "Summer Time" is just another name for DST used in some European countries.

Yes, your head may be a bit confused right now.  It can be for many people.  For example;
  • "AEST" is "Australian Eastern Standard Time"; and
  • "CEST" is "Central European Summer Time".
One is referring to DST and the other one is referring to STD.  Careful about that.

So what happens when one crosses over the border from blue part to the yellow part (DST) shown above?  Well, by official definition, a geographical location always advances the clocks when crossing the border into DST.  That is, we lose sleep when it starts, and gain sleep when it ends.  And it's usually an hour of sleep that we lose/gain.  But using the TZ variable, it can be any number of minutes you desire; not necessarily 60 minutes.

Now to the 'nitty-gritty' of the POSIX 'TZ' variable.  This is how you can set set your own custom version of what you see in figure 2.  You can choose when the 'blue' and 'yellow' parts start and end, and how much time is lost or gained at the crossing of each border.
The POSIX 'TZ' variable is defined as so:
std offset dst [offset],start[/time],end[/time]
Fig 3: The POSIX 'TZ' variable.

Here it is.  The golden TZ variable.  You're going to want to refer back to it many times; here, or on the GNU manual page or elsewhere.  Rather than explain what each part of figure 3 means, maybe jumping straight into some examples is clearer:

Example 1:
In English:

  • This would jump into DST (and lose an hour of sleeep) on the 2nd Sunday of the third month (March) at 2:00:00.  Eg. For 2015, we jump into DST on 8 MAR 2015 2:00:00.
  • This would jump out of DST (daylight savings time) on the 1st Sunday of the eleventh month (November) at 2:00:00 and we get an hour of sleep back.  Eg. For 2015, jump out of DST on 1 NOV 2015 2:00:00.
  • In this instance, the option DST [offset] omitted, and so defaults to an hour.

Example 2:
In English:
  • In this example, we have omitted the start and end [/time]'s, so it is assumed to be 2:00:00.
  • This would jump into DST (and lose an hour of sleep) on the 1st Sunday of October 2:00:00.   Eg. For 2015, we jump into DST on 4 OCT 2015 2:00:00.
  • This would jump out of DST (and gain and hour of sleep) on the 3rd Sunday of March 2:00:00.  Eg. For 2016, we jump out of DST on 20 MAR 2016 2:00:00.
  • Be careful if you were to manually set the time using the "date -s" command in the time period between 1:00:00 and 2:00:00 on 20 MAR 2016, as this is an "ambiguous" time period (it is experienced twice; once in the 'lead up' to exiting DST, and once again, when the clocks are set back an hour).
Example 3:
In English:
  • This example uses an entirely fictitious "ABC" standard and daylight savings time. 
  • In this example, we aren't using the 'Mm.w.d' format shown in the above two examples.  We are using "Julian Days" from 0 to 365.
  • In this example we will use 2015 as the example year.
  • We jump into DST (lose an hour of sleep) at the stroke of midnight on the 4 JAN 2015.  To be clearer, we jump directly from 4 JAN 2015 23:59:59 to 5 JAN 2015 01:00:00.
  • We jump out of DST (gain an hour of sleep) on the 22nd hour of the 10th April 2015, i.e. 10 APR 2015 22:00:00.

Some extra things worth mentioning:

  1. Environment variable scope is an issue when using the 'TZ' variable.  Exporting the TZ variable will affect the current process; and any processes spawned from it (child processes) will get a copy.  Parent processes will not be affected.
  2. There's more than one way to cook an egg.  If the TZ variable is not suitable for you, you may also consider a timezone database (zic input files), and the zic compiler.
    This page is the best resource I can find about this method.  It includes good examples.

Monday, December 22, 2014

Ubuntu 13.04/13.10 - W: Failed to fetch [source] 404 Not Found

So you're running Ubuntu 13.04 or Ubuntu 13.10, or something else, and one day, when using apt-get, this happened:

W: Failed to fetch  404  Not Found [IP: 80]

W: Failed to fetch  404  Not Found [IP: 80]

W: Failed to fetch  404  Not Found [IP: 80]

E: Some index files failed to download. They have been ignored, or old ones used instead.

Has lightning struck all the servers?  What's actually happening is that the distro has reached EOL - end of life.

What EOL means is that a lot of applications are not supported or updated anymore.  It also means that when you do an apt-get update, you might get a whole bunch of 404's, and if you try to use the Software Center, it might hang or error out with "Failed to download repository information".

Repositories contain packages which are tested and built specifically  for your version of Ubuntu.  Eventually support dies out in favour of newer releases and long term support (LTS) releases.

One option is to upgrade.  Another option is to edit your /etc/apt/sources.list file like so:

That'll keep you synced with the old versions of the packages for your release.  I used vim with the text replace commands:
(plus 'y' for every replacement).  You might need to adjust that depending on which server you're using.
More about Ubuntu repositories and servers:

Monday, November 24, 2014

Serio: A serial file transfer program without needing z/y/xmodem

In one of my previous posts I talked about using zmodem as a backup/emergency method to transfer files onto an embedded device using the serial console.  This technique requires you to have the lrz binary on the target to initiate the transfer.  But what happens if you have no way of getting lrz onto the target in the first place?  In this post I show you a method of serial transfer requiring no binaries to be on the target, and absolutely no setup on the target-side.

First, check that you have a Python 2.x version installed.  If you don't, apt-get or yum install it onto your host OS.  Check the version with python --version.

Now get the utility, which is called 'serio'.  Get it with hg clone Before you go ahead, there are two patches you need to apply (by hand):

Patch 1:
Insert self.last_size = 0 at the location shown, highlighted in green:
if callable( and callable(fp.write) and callable(fp.readline) and callable (fp.readlines):
                        self.fp = fp
                        self.current = 0
                        self.showprogress = progress

                        self.last_size = 0 

Patch 2:
Get rid of this line, on line 19:

and insert these lines instead:
already_open = self.s.isOpen()
if not already_open:

Update (14 June 2015): I tried this again recently.  It seems you may need to use self.serial.isOpen() and instead.

That patch above is for people who get the "Port is already open" error.  Now you can run the utility:

sudo ./serio -s lrz -d lrz -p /dev/ttyS0

where -s is the source file, -d is the destination, and -p is the serial (console) port.  You'll get a nice progress bar.

I recommend putting lrz onto your target (as per my example) so you can do zmodem transfers from here on in.

Help!  It transfers, but the executable doesn't work!
  • Check that the echo command on your target supports the "-n" and "-e" options (that's all you need).
  • Try cross-compiling a minimal "hello world" program with your toolchain and try transferring that, as a test.  Run it, and if you see "hello world" your settings are probably OK.  See the next point...
  • Open the source code and modify the parameter IO_TIME = .1 to be something greater than .1 (try .3 or .5).
  • In addition to the previous step, try using your toolchain's strip command to reduce the size of the binary.