Subsequent to my first post on sizing the partitions, and despite allowing for twice the amount mentioned in the book – 8Gb rather than 4Gb (see Ubuntu Unleashed 2012 – the install), a flashing question mark in the left hand panel has appeared. When clicked a warning message pops up to say that the Root partition disk is nearly full. How come?

The examine button asks if you want to use disk usage analyzer, which is a great tool, so lets have a look at it. It can be run directly by entering “disk usage” into the unity command line or also by using the name “baobab”.

The way this works is that each ring represents a level of directory from the middle out. The cursor is hovering over the /usr directory for which the system shows pointers to its subdirectories as the next ring segment level out. This utility shows by default the disk usage across all partitions, which is not so helpful in this instance. Fortunately, this can be restricted to the partition in question by  using the Edit->Preferences option and clicking the disk drive icon (above) to rescan. This window is instructive because it shows the different disk devices mounted (logically connected) and where they can be found in the directory tree. In this case, the image was taken part way through a tidying exercise so the total does not match that shown earlier.

The two biggest culprits are the /usr and the /var directories.

• /usr contains important source code stuff like code sources, binaries and libraries. Maybe I shouldn’t erase these things.
• /var contains log files but inspection (ls -l) reveals they are not particularly large.
• Firefox’s tools->clear recent history removes 300 Mb of stuff so that gives some breathing space. This came out of the /lib directory.
• Using the instructions in www.jaypeeonline.net/tips-tricks/howto-remove-old-ubuntu-kernels removed around 500Mb of older versions of the linux-kernel. This is good to do but not a long term fix.

To get an idea of the structure and usage of the Linux partitions, we can also use the terminal command ‘df’:

Filesystem          1K-blocks       Used  Available Use%  Mounted on
/dev/sda7              768836    6929396     368412  95%  /
udev                  1944992          4    1944988   1%  /dev
tmpfs                  780804        820     779984   1%  /run
none                     5120          0       5120   0%  /run/lock
none                  1952004        304    1951700   1%  /run/shm
/dev/sda8            43255296    3961388   37096660  10%  /home
/dev/sda5           207244136   38284684  168959452  19%  /windows
/dev/sda2           195354620  107926260   87428360  56%  /media/OS

Here we can easily see the fact that /dev/sda7, which we know is where the root is mounted, is 95% full (again not taken at exactly the same time as the other examples). The problem though, is that this contains information from Linux’s point of view based upon what is actually mounted. What would be also useful would be to get an idea of how the whole disk is structured. Enter the unusually oddly named (in a domain where odd nomenclature rules) palimpsest (there must be a really intelligent / cool reason for this name) disk utility:

This image is a bit small but you can click on it to get a bigger version if you like – or just try the utility on your system for more personal results. This graphically shows my 500Gb disk broken into a 200Gb Windows partition and the rest for Windows recovery and Linux (on the right). The main Linux partition is further broken down. The overall name of the disc is called sda and each partition is given a number, so sda7 is the offending root partition.

Fundamentally though, I have been playing around too much, have installed some bits and pieces and filled up the partition. This does beg the question of why we needed to make small partitions for the program area in the first place? Wouldn’t it be better to just combine with all the other Linux areas and let things dynamically flow between them rather than having this problem?

The solution I went for was to go back to the Ubuntu Unleashed installation disk again and resize the partitions by lowering the size of sda5 and creating a new sda9, larger than the existing sda7. The image above was actually taken after this reallocation and the new disk space (12Mb) grabbed from the DATA partition is shown. To recap the above structure, the purpose of each elementary partition from left to right is:

• sda1: Windows Recovery
• sda2: Windows OS, basically the C: drive so has lots of user and program information in it. It is about half full
• sda5: Windows D: drive with My Documents, this is shared with Linux as the /windows directory
• sda9: New 12Mb area for Linux root expansion, grabbed from the end of sda5.
• sda6: 8Gb Linux swap area
• sda7: 8Gb old Linux root partition
• sda8: 45Gb Linux /usr partition, for user data

In fact fixing this was quite a protracted procedure and I learned that you can only extend partitions into empty space that physically follows them. This is obvious really as the partitions are divisions of contiguous disk space. Unfortunately this causes a problem if the 8Gb root partition is followed by the /usr partition where the user data is stored right at the start. I intended to make the new 12Gb partition (sda9) a continuation of the 8Gb (sda7), but the installation software (see my first post) did not allow this.

There are some very helpful instructions about moving the Linux partition in the Ubuntu documentation. This gives information about mounting and unmounting partitions in the /dev directory, updating unique partition identifiers (UUIDs), grub and fstab. These last two are to control the booting process and the bootloader menu. The goal was to move the Linux partition (the root directory) from sda7 to sda9. When mounted in the /dev directory, these are also known as /dev/sda7 and /dev/sda9. At the high level, this procedure entails:

• Using the Installation CD to create the new partition (we don’t need the rescue CD as mentioned in the notes).
• Clone the existing Linux partition using the gparted tool.

• Generate a new unique reference number for the new partition (UUID). These are very long numbers that are for all practical purposes, globally unique. This of course means only a very very small probability of any two being identical. Wikipedia says “The probability of one duplicate would be about 50% if every person on earth owns 600 million UUIDs.” Fair enough! You can see an example of a UUID against the Mount Point of the palimpset utility above.
• Update the Master Boot Record (MBR) to make the system boot from the new partition.

Unfortunately, I was not able to make this last step work – possibly because of errors in earlier steps, or maybe because of my dual boot setup? Who knows, anyway, the goal of this was to create another installation of Linux on the same disk, so back to the trusty installer! I learned a new thing here too – if you have a separate home partition, you need to tell the installer which it is by providing it under the ‘mount point’ column. This means you have to tell it both the root (/dev/sda9) and the /home (/dev/sda8). If you don’t do this, you get another /home directory set up with skeletal details, just as the system was when first installed (because this is what happened).

This successfully fixes the boot menu and now there are options to boot into the old Linux on /dev/sda7, the new one on /dev/sda9 as the first boot option and all the other normal windows and recovery options. It should be possible to delete the sda7 partition, move the swap area up and increase the size of sda9, but for the moment, it is nice to have a ‘real’ Ubuntu and a ‘test’ one on the same machine. I have been experimenting with graphics drivers and they have caused big problems (needing a reinstall), so I think I will stick with the test area for a while, at least until I can get some progress on this other issue.

Other things I could have tried would have been centered around moving partitions. There are also instructions for this in the Ubuntu documentation.

As an aside, gparted is not found in the normal Linux installation, but if you run from an installation disk, you are then allowed to use it. Presumably, this is so you don’t destroy the environment you are working in. However, screen prints are hard to store permanently somewhere, as a disk mounting / accessing / something daemon (c.f. Windows service) is turned off. I used the cloud (dropbox).

So to conclude, here are some questions for which it would be really great if anyone could help me out with:

• Is it possible to define an extension partition somehow so that a partition can be made to flow on to another partition when it is full?
• Why could I not update the MBR to the new grub successfully? Does this really have to do with a dual Windows / Linux system? I know I haven’t given examples of commands here, but as I have two Linux installations, with two grub configurations, it should be easy to just switch between them somehow.
• Why is it recommended to make a small root partition? Was this just an example to show a system for where the users were not going to add many programs? Is there an easy way to handle disk overflow in this situation?

Thanks for reading and here is a great Baobab tree, the palimpset is not so impressive:

Laptop Linux top tip (amendment):

• Don’t use the fiddly edge scrolling I mentioned in my first post (even though it is better than page up / page down). Use Settings -> Mouse and Touchpad -> Touchpad tab to change to two finger scrolling. This allows you to move the mouse with one finger and to just drop another finger down to scroll the window. Brilliant! I just checked on an older Vista laptop and it doesn’t do it, but Windows 7 on this laptop does.