Ubuntu, Remote Desktop and Windows Remote desktop (3): ThinLinc

This article is a continuation of two previous articles: Ubuntu, Remote Desktop and Windows Remote desktop (1 and 2). It is advised to read those two articles first.

In my previous article, I have explained how to auto-start and auto-pause a VirtualBox VM with Ubuntu. Now let’s see how we can use this feature in a broader context: using a remote desktop solution that enables remote usage of Linux and Windows desktops, from any device, and basically, from anywhere. Anywhere includes access to internal computers from the Internet. For the latter, and with the product that I use for it: a good firewall protection (maybe double), a correctly working DNS, understanding of Network Address Translation and understanding how to harden an SSH server at least with Public Key Authentication are essential. I won’t go into details about accessing an internal desktop from the Internet with the solution explained below. Suffice it to say that I do so. But since security is essential, I won’t publish any details. Numerous articles on the Internet explain items like SSH, alternate SSH ports, Public Key Authentication, Port Redirection, etc.

 For remote access within my home network, I use a free ten user version of ThinLinc, which I installed on my HP xw6400 Workstation with Ubuntu 12.04.  ThinLinc is a Thin Client solution based on Linux. It has excellent sound and video support. In my home situation, even when accessed over two wireless simple SOHO access points, the sound and video quality of e.g. a complex Youtube movie is still acceptable. In other words: ThinLinc just rocks. One more thing though: I strongly advise to install this software on Ubuntu versions that are supported by ThinLinc, and not to try the software on non-LTSP versions of Ubuntu. Ubuntu 12.04 is supported, according to the documentation.

I won’t go into details about the installation of ThinLinc. An excellent instruction, though of an earlier version than the current one, can also be found on Youtube. It is also very well explained in their online documentation.

By the way, ThinLinc has many, many more possibilities than I use in my home network. I just use a fraction of their numerous options.

Anyway, if you’re interested in trying this solution, take your time to read their online installation documentation first, because for the rest of this article, I assume that the reader is familiar with ThinLinc terminology.

Next, have a look at what you can achieve with their software with their online demo.

Also, first create an Ubuntu test virtual machine to familiarize yourself with the installation procedure. Then next with the knowlegde you gained, proceed to a real life installation.

What I myself remember of the installation, is that it was not difficult. Having already installed an Apache web server (sudo apt-get install apache2) but not the SSH server, the installation procedure corrected this issue by installing all missing pieces directly from the web. In less than half an hour, I had a fully functional ThinLinc server.

After having logged in to the admin web interface, I enabled two profiles, and disabled the rest.

thinlinc profiles

The Unity2D profile allows encrypted remote sessions to Linux machines where the VSM Agent is running. So if the VSM Agent is running on the same machine as the VSM server, the profile chooser will contain an option to connect to exactly the same server. Well, since I have only one physical machine… And that’s already the whole trick for remote sessions to your own Ubuntu machine.

 The Windows profile allows encrypted remote sessions to Windows machines where the ThinLinc WTS Tools are installed. Here, the trick is quite simple as well: under Application Servers, just point your default to the Virtualbox VM (with WTS Tools) that is auto-stated at boot time of the Ubuntu host.

thinlinc RDP server

The result, when starting a remote Thinlinc session, is the following.

tl profile chooser

Mind that for this remote desktop example, I use the HTML5 client: no client software on the client device, just a plain and simple (encrypted) HTML page in FireFox. Ready to install clients are available as well.

When clicking on Unity2D, a session is established to the Ubuntu desktop where the ThinLinc software is installed.

ubuntu session

And when choosing my Windows Desktop…a session is established to the VirtualBox VM that was auto-started…at boot time of that same Ubuntu Desktop machine.

ThinLinc remote session to Windows

Oh, and did I already mention that in this way, I am able to print from any device, to the printer that is attached to exactly the same Ubuntu host? Because that is another thing: Thinlinc allows printer redirection as well.

So basically, whether accessing a web page or using the Thinlinc client…off you go with an Open Source solution that allows you to connect to Linux and Windows your computers from any device in your home network!

Learn and have fun!


19/04/2014 at 8:48 am Plaats een reactie

Ubuntu, Remote Desktop and Windows Remote desktop (2): How to auto start (and pause) a VirtualBox VM at boot time and shutdown

This article is a continuation of my previous article: Ubuntu, Remote Desktop and Windows Remote desktop (1)

As soon as I decided to re-publish my WordPress blog (it had been offline for a couple of months), I noticed that one of the more popular articles is the article about X2Go . X2Go is a remote desktop solution for Linux, and is a fantastic product. Maybe I could have used it for my home network, but when doing this home network project, X2Go was not yet feature-rich enough.  As stated in my previous announcement, I would like to discuss the way I have organized my home network with Thin Client / remote solutions, with a combination of a couple of products. For a general overview, check out the picture in my previous article.

Ubuntu 12.04 Desktop version (LTSP) I personnally prefer Long Term Support versions (LTSP), since, generally speaking, these LTSP versions are more stable than the non-LTSP releases.

Virtualbox, which will auto-start a Windows 7 VM at boot time of the Ubuntu Desktop, and auto-pause this Windows 7 VM at Ubuntu Desktop shutdown.

Thinlinc . I believe that this product is, by far, the best commercial product for any Linux based thin client / remote solution, whether intended for a remote Linux or Windows Desktop. And best of all: it comes with a free 10 user version. I guess that this is more than sufficient for an average home usage…

Let’s first talk about some basics.

First I installed my Ubuntu “Desktop server”. It would be used, later on, as remote, say, Linux RDP server, with a virtual Windows 7 box inside. For the whole project I bought, an old HP xw6400 workstation, at less than 300 euro. It’s a 64-bit machine, with only 8 GB RAM, and a 1 TB disk, and it’s the HP XW6400 shown in my previous article.

On this machine, I installed Ubuntu 12.04 Desktop Edition. As shown in the screenshot, I did a custom partitioning of the disk:



– A boot partition (/boot) of type ext2
– a swap file partition of 2 GB
– an extended 900 GB partition (“/”; this would contain the user data)
– an extra /vms partition (this would contain the files for VirtualBox VM’s up to 100 GB)

The VirtualBox part

Okay, now let’s get started with VirtualBox: how to auto-start and auto-pause a (Windows) VirtualBox VM at boot time and at shutdown. This Windows VM will be used, later on, in the Thinlinc Remote Desktop solution.

Basically, I simply installed VirtualBox. If I remember well, I did not use the Ubuntu Software Centre to install it. At that time, I used virtualbox-4.2_4.2.6-82870~Ubuntu~precise_amd64.deb from https://www.virtualbox.org/wiki/Downloads. I guess there’s a more recent version now, check it out at Virtualbox.When defining the location of the files for the Windows VM, I chose /vms (which I created earlier). For the rest, I simply did a normal install of a VirtualBox Windows VM, so I am not going into details about that.

But now, here comes the first trick: how to auto-start and auto-pause the VM at boot and at shutdown time.

First, you need a script that I found on  sourceforge.net. I tried to find it back for reference, but It seems to be gone from SourceForge. However, the original script can still be found at pastebin.com.   Here is the content of my /etc/init.d/  windows script: vbox-windows7ultimate.

Mind your VirtualBox VM name: stick to lower case to avoild errors, and avoid space in the name of the VM.

Since the file is self-explanatory, I simply copy / paste the content here:

#! /bin/sh
# chkconfig: 2345 90 10
# Provides: vbox-windows7ultimate
# Required-Start: $remote_fs $syslog
# Required-Stop: $remote_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: ‘windows7ultimate’ virtual machine
# Description: Starts and stops a VirtualBox host as a service.

# Author: Brendan Kidwell <brendan@glump.net>
# License: GPL 3 <http://opensource.org/licenses/GPL-3.0&gt;
# Based on /etc/init.d/skeleton from Ubuntu 12.04.

# What is the name of the VM exactly as it appears in the VirtualBox control
# panel? This is the ‘name’ and the ‘long name’ of the VM.
# Does ‘name’ contain spaces or other special characters? If so, you must
# make up some other value for ‘name’ that doesn’t have spaces.
# Setup:
# 1. Copy this file to /etc/init.d/vbox-‘name’. The filename must start with
# the prefix “vbox-“. Make sure you set the ‘x’ bit on the file to make it
# executable: Note by JanV: open a terminal session, sudo sulogin, and cd into /etc/init.d and chmod +x filename.
# 2. Edit ‘Provides’, above, to match the filename.
# 3. Edit ‘Short-Description’ to describe the function of the VM.
# 4. If ‘long name’ is different from ‘name’ fill it in below, otherwise leave
# LONGNAME as an empty string.
# 5. What user owns the virtual machine?
# 6. Which stop command? “hibernate” or “powerbutton”
# 7. For the ‘start-wait’ command — waiting until network is up, what is the
# VM’s hostname?

# Do NOT “set -e”

# PATH should only include /usr/* if it runs after the mountnfs.sh script
# Pull DESC from file header
DESC=`grep –max-count=1 “^# Short-Description:” $(readlink -f $0)|cut –delimiter=’ ‘ –field=3-|sed ‘s/^ *//’`
# Pull NAME from file header
NAME=`grep –max-count=1 “^# Provides:” $(readlink -f $0)|cut –delimiter=’ ‘ –field=3-|sed ‘s/^ *//’`


# Get VM_SHORT_NAME from service name
VM_SHORT_NAME=`echo $NAME|cut –delimiter=’-‘ –field=2-`
# Actual filename of VM is VM_SHORT_NAME, or if VM_LONG_NAME is set, use that
if [ ! “$VM_LONG_NAME” ] ; then VM_LONG_NAME=$VM_SHORT_NAME ; fi

# Do not use ‘sudo’ if this script is actually running as VM_OWNER already
if [ `whoami` = $VM_OWNER ] ; then SUDO_CMD=”” ; else SUDO_CMD=”sudo -H -u $VM_OWNER” ; fi

# Set VBoxManage command for stop action
if [ $VM_STOP = powerbutton ] ; then VM_STOP_CMD=acpipowerbutton ; else VM_STOP_CMD=savestate ; fi

# If VM_HOSTNAME isn’t set (for ‘start-wait’ command) use VM_SHORTNAME

# Load the VERBOSE setting and other rcS variables
. /lib/init/vars.sh

# Define LSB log_* functions.
# Depend on lsb-base (>= 3.2-14) to ensure that this file is present
# and status_of_proc is working.
. /lib/lsb/init-functions

# possible SHORT_STATE values: running, paused, aborted, powered off

VMINFO=$($SUDO_CMD $MANAGE_CMD showvminfo “$VM_LONG_NAME” 2>/dev/null)
if [ $? = 0 ] ; then
# No error retriving state string
LONG_STATE=$(echo “$VMINFO”|grep –max-count=1 “^State:”|cut –delimiter=’ ‘ \
–fields=2-|sed ‘s/^ *//’)
SHORT_STATE=$(echo $LONG_STATE|cut –delimiter=”(” –fields=1|sed ‘s/ *$//’)
# Fix for syntax highlighting in KomodoEdit for previous line
[ 0 = 1 ] && NOOP=$(echo “)”)
# VM must be missing

# Return
# 0 if daemon has been started
# 1 if daemon was already running
# 2 if daemon could not be started


if [ “$SHORT_STATE” = “missing” ] ; then
echo Could not access VM \”$VM_LONG_NAME\”.
return 2

if [ “$SHORT_STATE” = “running” ] ; then
echo VM \”$VM_LONG_NAME\” is already running.
return 1

$SUDO_CMD $MANAGE_CMD startvm “$VM_LONG_NAME” -type vrdp || {
echo Failed to start VM \”$VM_LONG_NAME\”.
return 2

# No status report; VBoxManage said if it worked.
return 0

# Return
# 0 if daemon has been stopped
# 1 if daemon was already stopped
# 2 if daemon could not be stopped
# other if a failure occurred


if [ “$SHORT_STATE” = “missing” ] ; then
echo Could not access VM \”$VM_LONG_NAME\”.
return 3

if [ ! “$SHORT_STATE” = “running” ] ; then
echo VM \”$VM_LONG_NAME\” is already stopped.
return 1

echo Failed to hibernate VM \”$VM_LONG_NAME\”.
return 2

echo Waiting for \”$VM_LONG_NAME\” to complete shutdown…
while [ “$SHORT_STATE” = “running” ] ; do
sleep 1

echo The VM \”$VM_LONG_NAME\” has been stopped \($VM_STOP\).
return 0

if [ “$SHORT_STATE” = “missing” ] ; then
echo Could not access VM \”$VM_LONG_NAME\”.
return 2
echo Status of VM \”$VM_LONG_NAME\”: $LONG_STATE

if [ “$SHORT_STATE” = “running” ] ; then return 1 ; else return 0 ; fi

do_reload() {
do_stop && do_start

do_wait_for_online() {
echo Waiting for \”$VM_LONG_NAME\” to come up on the network…
while [ ! “$result” = “0” ] ; do
sleep 1
ping -c 1 $VM_HOSTNAME >/dev/null 2>/dev/null
echo Ready.

case “$1” in
[ “$VERBOSE” != no ] && log_daemon_msg “Starting $DESC” “$NAME”
case “$?” in
0|1) [ “$VERBOSE” != no ] && log_end_msg 0 ;;
2) [ “$VERBOSE” != no ] && log_end_msg 1 ;;
do_start && do_wait_for_online
[ “$VERBOSE” != no ] && log_daemon_msg “Stopping $DESC” “$NAME”
case “$?” in
0|1) [ “$VERBOSE” != no ] && log_end_msg 0 ;;
2) [ “$VERBOSE” != no ] && log_end_msg 1 ;;
do_status && exit 0 || exit $?
# If the “reload” option is implemented then remove the
# ‘force-reload’ alias
[ “$VERBOSE” != no ] && log_daemon_msg “Restarting $DESC” “$NAME”
case “$?” in
case “$?” in
0) [ “$VERBOSE” != no ] && log_end_msg 0 ;;
1) [ “$VERBOSE” != no ] && log_end_msg 1 ;; # Old process is still running
*) [ “$VERBOSE” != no ] && log_end_msg 1 ;; # Failed to start
# Failed to stop
[ “$VERBOSE” != no ] && log_end_msg 1
do_start && do_wait_for_online
echo “Usage: $SCRIPTNAME {start|start-wait|stop|status|restart|restart-wait|force-reload}” >&2
exit 3


Now when this script is inside the /etc/init.d directory, run these commands inside a terminal:

sudo sulogin (enter your password)
cd /etc/init.d
update-rc.d scriptname defaults 90

With this command, you ensure that the script is used at boot time of your Ubuntu computer.

All right, basically that’s all. If you want to check if your VM is running:

sudo sulogin (enter your password)
service scriptname status


Or your just check it out within VirtualBox:



Check it out…and have fun!!!

More about my home network configuration in an upcoming article: Thinlinc


12/04/2014 at 7:23 am Plaats een reactie

Ubuntu, Remote Desktop and Windows Remote desktop (1)

thuisopstellingIt’s been a while since I published a blog entry on this WordPress site. No time, other priorities. Things have changed since, and I will be having more time to publish about items that I’ve come to discover or create.

Since my last post (somewhere in late 2012), I always wanted to explain the way I have, since then, organized my own home network around a combination of Ubuntu, Windows (whatsoever version), and VirtualBox. In the next weeks, I will be publishing, in parts, how I proceeded to achieve the following: a central Ubuntu desktop server (so a kind of Linux Terminal server), that would also function as a kind of  Windows Terminal server, in case me or my family members would need to use a Windows application, supposed there was really no alternative. The Ubuntu / Windows terminal server would and should be accessible from any device within my my home network (even from e.g. an iPad).  My ultimate goal was to have this central Ubuntu server auto start up (or resume), at boot time,  a Windows virtual machine (with remote desktop enabled), and to shutdown or hibernate this Windows VM at shutdown time of the Ubuntu terminal server. Also, printing would be done centrally on this server, whether through Ubuntu or thorugh Windows. And finally, of course, backup would be done only on this central machine. Interested? Stay tuned! Oh and by the way: of course, and since I prefere to re-use (legacy) hardware: all at minimum cost.

30/03/2014 at 4:21 pm Plaats een reactie

Ubuntu 12.04 x64 and Citrix client 12.1

Just a couple of days ago, I needed to install some extra software on one of my Ubuntu machines, x64. I needed to have remote Citrix access to a site of one of my customers. Installing a Citrix client is excellently described on the official Ubuntu documentation site, and for anyone who needs to, first of all, go there first, and not first to the Citrix ica client download site. Unfortunately, I did the opposite, and so I went directly to the official Citrix client download site. There, I downloaded the package that was presented to me for my x64 Ubuntu machine (“Receiver for Linux 12.1, Release Date: 4/23/2012, For 64-bit Systems) . According to the Ubuntu documentation, for Ubuntu 12.04, I should just have installed the 12.1 32 bits client.. Anyway, I downloaded the ill-behaving x64 Debian installation file icaclient_12.1.0_amd64.deb and started the installation of the software through the Ubuntu software center.

So I had chosen the wrong one, and indeed, exactly as described on the official Ubuntu documentation site, at the end of the install, i got an “exit 2” error message: the Citrix software was in an in-between state of installation. The Citrix binaries were installed, though, in the appropriate directories, so I thought, what the h….And remote Citrix access was possible, so I left the machine this way. Until this morning, when, through the normal update procedure, my machine started downloading and installing updated packages. Because of the not-so-well installed Citrix package, the update would always come up with warnings, errors, etc. (as described on the Ubuntu documentation site).

Now the Ubuntu documentation site does have a solution for this, but frankly, I find it rather cryptic…:

“This can be fixed by unpacking the deb and editing the regular expression in line 2648 of the postinst script to match x86_64. Then rebuild the deb and it should install without a problem.”

For all those who have exactly this problem, here is a somewhat less cryptic description for this line:

– Just extract the file icaclient_12.1.0_amd64.deb
– a folder icaclient_12.1.0_amd64 will be created
– in this folder, open the DEBIAN folder
– double click the postinst file, and select “display” (so do not choose run in terminal)
– on line 2648, change the line so that the result will be:  echo $Arch|grep “x86_64″ >/dev/null <–so you just have to change the item in between th ” ” quotes
– save the file
– rename your current icaclient_12.1.0_amd64.deb to e.g. icaclient_12.1.0_amd64-old.deb
– open a terminal, and, with the cd command, navigate to one level above the icaclient_12.1.0_amd64 folder <– so with the ls command, you can see this folder
– now type dpkg-deb -b icaclient_12.1.0_amd64/ icaclient_12.1.0_amd64.deb

And here you have your well working Citrix 12.1 x64 deb installation package.

Although the package installed with some warnings about the quality of the package, it installed 100% instead of exiting just before. And of course now, updating Ubuntu through the normal procedure went without a flaw…

26/08/2012 at 11:33 am Plaats een reactie

Upgrading from Ubuntu 11.10 to Ubuntu 12.04

Just a quick one, because it was incredibly quick to do. Today, I attempted an upgrade of Ubuntu to the newest LTS version, 12.04, on my Toshiba Satellite L670-1DT (64 bit). The installed version was Ubuntu 11.10. As a precaution, I connected my machine to my home network with a normal network cable, instead of working wirelessly. After that, and before starting the upgrade, I made sure that all current packages would be up to date. After that, I started the upgrade. Well, my very big compliments Ubuntu developers and Canonical: the upgrade went totally flawlessly! New packages were downloaded, the upgrade was started. In the Details pane that you can open when doing an upgrade, i just had to answer some basic questions in the beginning (Enter… / OK), and that was it. After the install portion finished, old packages were removed and the system was restarted. About an hour after I had started the upgrade, the job was done.

The only thing that did not work was a java based application. Indeed, the upgrade had changed the default java program to IcedTea. Since I already had a Sun java version on my machine, the only thing I had to so was to remove IcedTea: sudo apt-get purge openjdk-\*. This reverted the Java version back to the previously installed version, No hassle with reinstalling java, nothing! This is the way an online upgrade should be. One more thing however for those who want to do an upgrade instead of an installation of a new version: always have a recent backup of your /home directory, an upgrade is always a bigger risk than  doing a fresh installation.

23/06/2012 at 9:04 am Plaats een reactie

How to recover your Windows files when nothing helps any more

Today, I had a fine case of  recovering Windows files from a corrupt Windows installation. The Windows OS (Vista…) would hang completely after a couple of minutes of operation, so files could not be copied from within Windows. My colleague suspected an imminent hard disk failure, so we had to remove the vital data from the machine. Everything had been attempted to create a clone, a backup, whatever, from the disk…nothing had been succesful so far.

I suggested to give it a try with an Ubuntu live CD. The idea was to try to mount the somewhat damaged partition within Ubuntu, and copy important files to an external disk. So we downloaded the live CD Ubuntu 12.04 from the Ubuntu web site, burned the live CD iso  file on CD, and started the CD. An Ubuntu live CD can be used to test Ubuntu without installing it to the hard disk.
Within our temporary desktop, I started GParted. GParted is an outstanding partition manager. To start it, I just had to click on the Ubuntu Dash and type in the word part. Ubuntu will find the right program for you rightaway.
Within GParted, I was able to see that the damaged NTFS partition was recognized as /dev/sda3. If the data had been on a D or E drive, of course, this would have been sda4, etc.  I created a temporary folder “temp”. Next, I had to give the following terminal console command to have all the Windows files visible in Ubuntu:

sudo mount /dev/sda3 temp (enter) <- this makes a link to the partition on the temp folder
cd temp (enter) <- go into the folder
nautilus . <- Don’t forget the .  , it means “current folder”; open the folder in file manager

Next, I just had to plug in an external hard disk, and voilà, I was able to copy almost all files. Problematic files residing on the damaged blocks were reported and I was able to skip them; this way, we were able to save 99% of the data.

So if you’re a Windows user and you have a problematic Windows installation…try to recover your files with the Ubuntu 12.04 live CD. And while you’re at it…have a look around on the Ubuntu 12.04 live CD. It’s quite impressive…

22/06/2012 at 1:26 pm Plaats een reactie

A couple of tips on how to recover from a failed Ubuntu upgrade

Last week I decided to give Ubuntu 11.10 a try on my Toshiba Satellite L670-1DT (64 bit). Having Ubuntu 11.04 already installed on this machine, and having a lot of extra software that I did not want to reinstall on that machine, I thought it was wise to go for an upgrade, instead of a fresh install. Well, I was wrong.

I started the upgrade from within the graphical screen. Downloading the new packages went without a flaw. However, just after about ten minutes, and during the software replacement phase of the upgrade, bang, there it was: just a black screen, no graphical screen any more, and a fatal error message on the screen: kernel panic, and no other activity on the machine whatsoever. The only option I had, was to power off the machine, and hope for the best.

I powered the machine back on. It would still boot into Linux, but  with a lot of error messages and only a text screen. There was no prompt, neither text based, and certainly not a graphical interface. So here I was, with a broken machine in an in-between state of two Ubuntu versions. What would be the best tactic of repair? And generally speaking, what are the best tactics of diagnosis and repair?
This is what I want to discuss in this blog entry, with a few simple basic tips. Oh and by the way: I fixed the Toshiba machine was (without reinstall…) and it’s working fine with Ubuntu 11.10 now, and Ubuntu 11.10 is just great. But would I recommend an upgrade from 11.04 to 11.10 instead of doing a fresh install? Well, I’m not so sure about that…just install a fresh Ubuntu 11.10.

Anyway, here is a couple of tips, for an Ubuntu machine that an upgrade was attempted on, with (at least…) no graphical screen appearing after a failed upgrade. My own situation after the failed upgrade was:

– no prompt
– no network
– a machine with an in-between Ubuntu version.

NB: all commands in Linux are case sensitive.

Tip 1. Always first check that your personal data is still in place.

If your personal data is still in place, you’ll feel a lot less lost.

Start your computer in Ubuntu recovery mode, and select root shell prompt. Press Ctrl-Alt-F2. A login prompt will appear. Type in your regular name and password. Type in: ls  (Enter). Do you see your files? Okay then, your data is still in place.

Tip 2. Check and possibly repair your internet connection (at least temporarily), and use it to repair. With a network cable plugged in into the machine, start your machine in Ubuntu recovery mode. In the recovery menu, select the drop to root shell prompt option (possibly with networking option). Type in: ifconfig (Enter). In the best case, it will show something like this:


eth0      Link encap:Ethernet  HWaddr 87:ae:1e:cf:0e:b3
inet addr:  Bcast:  Mask:
RX packets:7047 errors:0 dropped:0 overruns:0 frame:0
TX packets:6503 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:6643595 (6.6 MB)  TX bytes:1093342 (1.0 MB)
Interrupt:40 Base address:0x8000

lo        Link encap:Local Loopback
inet addr:  Mask:
inet6 addr: ::1/128 Scope:Host
RX packets:336 errors:0 dropped:0 overruns:0 frame:0
TX packets:336 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:26880 (26.8 KB)  TX bytes:26880 (26.8 KB)

The eth0 part is the networking part, and is the cable connection. It tells you that you have an IP address (inet addr). You could try a ping command to some internet site that can be pinged. If you get a response, you know that your network is still working.

From here, we have two scenarios:

– save personal data in a safe place and do a fresh installation; next, copy your data back on a fresh install
– continue the failed upgrade

If you want to go for the first option (save your data and start all over again), you can do the following, using the winscp program:

– install ssh on your Ubuntu machine: sudo apt-get install ssh. After installation, type: sudo /etc/init.d/ssh start. This will start your machine in server mode, and will allow you to get your files from the machine to any other place, including a to Windows machine. Download winscp. Install the package, and start it. Basically, you can now make a connection to your Ubuntu machine by entering the IP address of the Ubuntu machine, and by entering your username and password. Copy / paste all data that you would like to save. Your personal data is in /home/username.

Now let’s assume we want to opt for the second option: continue the failed upgrade. With a working network connection, you can just type in: sudo apt-get update, followed by sudo apt-get upgrade. Ignore error messages, and wait for the upgrade to finish.

But the situation could also be that you only see this:

lo        Link encap:Local Loopback
inet addr:  Mask:
inet6 addr: ::1/128 Scope:Host
RX packets:336 errors:0 dropped:0 overruns:0 frame:0
TX packets:336 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:26880 (26.8 KB)  TX bytes:26880 (26.8 KB)

In this case, your network is not working, and you’ll have to do some more work to, at least, get an Internet connection and to continue the previously failed upgrade.

Restart your computer in Ubuntu recovery mode, and select root shell prompt again. You can still:

– start scripts
– enable network interfaces
– get an IP adress through DHCP

Start scripts: all initialization scripts are located in the folder /etc/init.d/ Type in: /etc/init.d/networking start (Enter). After getting back to the prompt, type in: dhclient (Enter). Now check your network: ifconfig eth0. You should see that your Internet connection is working again, at least manually, and you should see something like shown in the first example, and you can continue the previously failed upgrade:sudo apt-get update (Enter) and sudo apt-get upgrade (Enter). Follow the instructions as shown on the screen.

Most of the time, and despite some very not-reassuring messages on the screen, you will see that the upgrade will continue up to a point where the upgrade procedure will prompt you to restart your machine. With a little bit of luck, the machine will be up and running again. If you’re not lucky, the machine will start, but will, e.g., not show any graphical screen. That happened in my case.

Tip 3. Check log files after (unsuccesful) full start.

Again, you may be lucky, or not. This was the case with my laptop, telling me (in text mode) something about apache being not well configured, and it just halted there: a black screen with some text.
Now we have two choices: on another machine, Google  for the exact error message (I think that’s a don’t) and check some log messages (I think that’s a do). I think that Googling for the exact error message is a don’t, because the last message on the screen is NOT per se the fatal message. Myriads of causes can apply tho the system not booting 100% correctly, and you will find at least a hint to the exact cause in the log files.
Log files are located in the /var/log/ directory. You can always access them, non-graphically, by doing the Ctrl-Alt-F2 thing, logging in with your normal account. Once you are logged in, type in cd /var/log (Enter). Type ls, and you’ll see all log files. You can read the content with the cat command, e.g. cat boot.log. If the file is too big, you can do cat boot.log | more.

The most important log files are:

– boot.log. Always check it. It will tell you which programs did load correctly, and which did not. Sometimes, the load failure is as simple as the package not being installed. If this is the case, you can always add it by typing sudo apt-get install <packagename>
– Xorg.0.log (that is with X, not with x). This is the log file of the graphical part (the “X server”). Any problems with the graphical screen will be reported here
– dpkg.log. That’s a log of all installed and  removed packages. Check what this file says about the missing (or wrongly installed package).
– syslog. That is the running system log.

The most important commands to read the log files in text mode are:

– cat (“show on the screen”)
– cat filename | more (“show on the screen as much as can fit on the screen”)
– cat filename | grep sometext (show on the screen the content of the file, but only the things that I want to see. e.g.: cat boot.msg | grep error
– tail -f filename (show the content on the screen and see the content as it is appended). e.g.: tail -f -n 100 /var/log/syslog. The -n is the number of lines

A tail command can always be interrupted with Ctrl-c.

Hope this information is helpful for anyone facing a failed Ubuntu upgrade.

25/12/2011 at 9:50 am Plaats een reactie

Oudere berichten Nieuwere berichten

Posted previously