Network booting the Live CD has obvious advantages – aside from booting faster than CD (especially on a gigabit network), it is indispensable as an emergency boot medium in a workplace environment, especially for broken Windows systems, and allows for Ubuntu effortless installations on netbook PC’s that don’t have optical drives and saves you having to have a USB stick handy.

Pre-requisites

• You need a working Linux PXE boot server. Doesn’t have to be Ubuntu, but it needs to be Linux. You cannot use a Windows PXE server.
• An Ubuntu 10.04 Live CD ISO or physical CD. Can be the 32-bit or 64-bit ISO, but you can also setup both of them at once!
• At least 700MB of drive space on your PXE server, more if you want to have more than one CD available.
• This tutorial was put together using Ubuntu Server 10.04 Lucid Lynx, but should work with all future releases and older versions to at least Ubuntu Server 8.04 Hardy Heron.

Getting it together

1. Login to your PXE server and mount the CD or ISO image (in this example we are copying the 32-bit disc). Assuming the CD is mounted at /media/cdrom, copy the CD’s files to your server as follows:

   $ sudo mkdir -p /srv/tftp/ubuntu-livecd-boot/i386
   $ sudo mkdir -p /srv/ubuntu-livecd/i386
   $ sudo cp -av /media/cdrom/* /srv/ubuntu-livecd/i386
   $ sudo cp -av /media/cdrom/casper/initrd.lz /srv/tftp/ubuntu-livecd-boot/i386
   $ sudo cp -av /media/cdrom/casper/vmlinuz /srv/tftp/ubuntu-livecd-boot/i386

   (if you want to setup the 64-bit disc, then replace all instances of “i386″ with “amd64″, or you can setup both architectures by setting up both directories)
   .

2. Make sure the permissions of the files to be loaded by TFTP are correct:

   $ sudo chmod 777 -R /srv

3. The astute of you will have noticed that we have copied the Ubuntu CD outside of the TFTP directory and that we have made a separate copy of only two of the disc’s files inside the TFTP directory. Why is this? Well, the vmlinuz and initrd.lz files are the only files that TFTP will need to download to get started with the boot process. After that, we will use NFS to deliver the rest of the Live CD, so let’s set that up:

   $ sudo apt-get install nfs-kernel-server
   

   Note: I should point out that the files that are copied to the NFS share do not have to be on the PXE server. The NFS server can be any box as NFS is not related to PXE at all.

4. Once that is installed, we need to define an NFS share. This is done in the NFS exports file, so let’s get that into a text editor:

   $ sudo nano /etc/exports

5. Add the following line to the bottom of the file:

   # Ubuntu Live CD files for PXE booting
   /srv/ubuntu-livecd/i386        *(ro,async,no_root_squash,no_subtree_check)

   …if you are setting up the 64-bit version, replace “i386″ with “amd64″, or if setting up both architectures, list it as follows:

   # Ubuntu Live CD files for PXE booting
   /srv/ubuntu-livecd/i386        *(ro,async,no_root_squash,no_subtree_check)
   /srv/ubuntu-livecd/amd64       *(ro,async,no_root_squash,no_subtree_check)
   

   A breakdown of the parameters on the right is as follows:

   • The asterisk means “share with everyone on this network, regardless of who they are”.
   • The “ro” parameter means to share the data as read-only.
   • The “async” parameter allows the NFS server to reply before data is written to the share. Since it’s mounted as read-only anyway, the parameter is only there to keep NFS’ syntax happy.
   • The “no_root_squash” parameter means to allow the NFS client to use the mount as a root filesystem, otherwise it’s mounted as “nobody” instead of “root”. Since the LiveCD is essentially a diskless client, we need to be able to define the NFS mount as a root volume.
   • The “no_subtree_check” parameter helps to speed up transfers. Normally NFS will check to see if a requested file exists in an exported sub-directory. This slows things down, so turning this off means the only check that is made is that the requested file exists on the exported filesystem. Subtree checking can also cause issues when an open file is renamed, but since the export is read-only, this is irrelevant.
     .
6. Save your changes with CTRL+X, then “Y” and then Enter.
   .
7. Now have NFS re-read its export file and begin sharing the specified directories with:

   $ sudo exportfs -a

8. We’re nearly ready to rock and/or roll. All we need to do now is prepare the PXE boot menu to launch the Live CD for us. Assuming you followed by previous tutorial and your boot menu file is called mybootmenu.cfg:

   $ sudo nano /srv/tftp/mybootmenu.cfg

9. Assuming your NFS server’s IP address is 192.168.0.10, insert the following lines for a 32-bit Live CD entry:

   label Live CD 32-bit
       kernel ubuntu-livecd/i386/vmlinuz
       append boot=casper netboot=nfs nfsroot=192.168.0.10:/srv/ubuntu-livecd/i386 initrd=ubuntu-livecd/i386/initrd.lz -- splash quiet

   …and if you are doing 64-bit, you can replace or add as a separate menu option the following:

   label Live CD 64-bit
       kernel ubuntu-livecd/amd64/vmlinuz
       append boot=casper netboot=nfs  nfsroot=192.168.0.10:/srv/ubuntu-livecd/amd64  initrd=ubuntu-livecd/amd64/initrd.lz -- splash quiet
    

   The kernel line is the actual kernel that is loaded to run the session. The append line tells the boot process several things. First up, the casper directory contains the boot files (a SquashFS image in the case of the Live CD), the root of the NFS file system is located on the server with the IP 192.168.0.10 under the path /srv/ubuntu-livecd/i386 (or amd64) and that the image to fire up the RAM disk with is located under ubuntu-livecd/i386/initrd.lz and finally we have advised the boot process to suppress console messages and display the splash screen while loading. From this point on, the initrd.lz is extracted and will grab the SquashFS image from the casper directory via NFS, extract it and commence running it. All other files that the disc needs to do its thing (such as when installing Ubuntu from the Live environment) are also provided by the NFS share.

10. Save your changes by pressing CTRL+X, then “Y” and then Enter.
    .
11. You’re now ready to go – reboot your PXE workstation and you should now see an entry for your Live CD. Upon choosing it, your system should fire up with the Live environment! Once booted, you can even do an Ubuntu install to the PC you started on as though you’d booted from a CD or USB device!
    .
    

Enjoy!

Why would you want to boot a PC from the network? Well, it opens the door to booting diskless workstations, eg: Internet Cafe PC’s, or if you regularly install tens or hundreds of PC’s, you can start the installer on all those machines at once without needing to have individual boot/install media for each machine. You can even use Linux PXE for starting Microsoft Windows network installers and tools.

This article is going to show you how to setup a standard Ubuntu 10.04 Lucid Lynx Server to respond to a PXE boot request and present a boot menu ONLY. I will put practical applications such as installing Ubuntu over the network or booting a Live CD over the network into separate future articles.

Pre-requisites:

• A PC or virtual machine with an installation of Ubuntu Server on it. This tutorial was written using an Ubuntu Lucid 10.04 Server, but these instructions will work equally well on nearly any version of Ubuntu Server. This tutorial will not detail the initial build of a server as it is relatively straight forward.
• A DHCP server that allows you to specific PXE boot information. Most consumer routers will not give you these options. Suitable DHCP servers are the DHCP daemon on Ubuntu Server, third-party Linux router solutions such as Smoothwall or pfSense, and Windows Server among others.
• If your DHCP server is a dedicated network/firewall device that you do not wish to use as a file server to serve the network boot files, then you will need a separate PC to be a file server as well.
• Some free disk space. PXE booting take bugger-all space, but whatever you plan to serve from it will need space. If you plan to setup the Ubuntu Live CD to be bootable from PXE, you will need 700MB+ of hard-drive space on that server. You will need more than this if you wish to host things like multiple LiveCD’s such as both the 32-bit and 64-bit versions, or multiple different distributions.
• A PC workstation that has PXE boot capability. Any PC built in the last 10 years should definitely have this capability, though you may be required to enable it in BIOS. If you do not have a PC that can do this, you can use a virtual machine such as Virtualbox instead (you could have a virtual machine PXE boot off a virtual PXE boot server too! ).
• A copy of Ubuntu Server 10.04 that suits your server’s architechture.
• A copy of the Ubuntu ALTERNATE Install CD 10.04 that we need to get some PXE boot files from. Unfortunately the Live CD does NOT contain the files we need.

At the end of this exercise we will have a PXE server that will boot into a selection menu that will give us choices of things to do. We’re also going to pretty up the menu with a background image instead of just having plain boring text, and we’ll do this using some of the existing elements on the Ubuntu CD as most of the work has been done for you already!

Getting it together:

1. Login to your server.
   .
2. Let’s install the software we need:

   $ sudo apt-get install tftpd-hpa inetutils-inetd

   …this will install a Trivial FTP server which is essentially a super-simple FTP server plus the inetd daemon which will listen out for TFTP requests and direct them to the TFTP daemon.Before you ask, no you cannot use a regular FTP daemon like vsftpd or similar. It has to be a TFTP daemon. Beware: Ubuntu has two TFTP options in the repository – you must use the HPA version of the daemon as shown, as it handles large boot images while the other daemon does not. If you don’t use it, you will see boot errors.

3. By default Ubuntu sets up the TFTP daemon’s root directory to be /var/lib/tftpboot which may not suit your requirements. For the purposes of this tutorial, we will be changing this to /srv/tftp instead. To do this, we need to edit the /etc/inetd.conf file in a text editor:

   $ sudo nano /etc/inetd.conf

4. Scroll down to the bottom of the file and modify the tftp line (or add it if it’s missing) and substitute /var/lib/tftpboot bit on the end of that line with the path to your preferred directory:

   tftp    dgram   udp    wait    root    /usr/sbin/in.tftpd /usr/sbin/in.tftpd -s /srv/tftp

5. Save your changes by pressing CTRL+X and then “Y” and then Enter.
   .
6. Now we need to tell the Trivial FTP daemon where our TFTP root is. Open its config file with:

   $ sudo nano /etc/default/tftpd-hpa

7. Modify the TFTP_DIRECTORY line (usually the fourth line from the top) to be /srv/tftp:

   # /etc/default/tftpd-hpa
   
   TFTP_USERNAME="tftp"
   TFTP_DIRECTORY="/srv/tftp"
   TFTP_ADDRESS="0.0.0.0:69"
   TFTP_OPTIONS="--secure"

8. Save your changes by pressing CTRL+X and then “Y” and then Enter.
   .
9. Now we just need to restart the inetd and tftp services with:

   $ sudo service inetutils-inetd restart
   $ sudo service tftpd-hpa restart

10. So that’s the TFTP daemon ready to serve files to a PXE agent. Now we need to create the directory where we will be putting all our PXE goodness into:

    $ sudo mkdir -p /srv/tftp

11. We now need to copy some files off the Ubuntu Alternate Install CD that make up the PXE boot files and the menu config files. I will use the 32-bit disc in this example, though the files are the same on the 64-bit disc for this step. Insert the CD or mount the downloaded Ubuntu Alternate Install CD ISO. In this case I will assume you have a physical CD mounted at /media/cdrom.

    $ sudo cp /media/cdrom/install/netboot/pxelinux.0 /srv/tftp
    $ sudo mkdir -p /srv/tftp/ubuntu-installer/i386
    $ cd /media/cdrom/install/netboot/ubuntu-installer/i386
    $ sudo cp -R boot-screens /srv/tftp/ubuntu-installer/i386
    $ sudo cp initrd.gz linux /srv/tftp/ubuntu-installer/i386
    

    (if you’re using the 64-bit CD, substitute all instances of “i386″ above with “amd64″ instead.)
    .

12. Now we need to setup the initial PXE boot process:

    $ sudo mkdir /srv/tftp/pxelinux.cfg
    $ sudo nano /srv/tftp/pxelinux.cfg/default

13. You will now be looking at a blank text editor. In this, type the following:

    include mybootmenu.cfg
    default boot-screens/vesamenu.c32
    prompt 0
    timeout 100
    

    The timeout 100 line will provide a 10 second countdown before it automatically chooses the default PXE menu option when you boot into it. If you do not want a timeout, then change this to timeout 0 instead.

14. Press CTRL+X and then “Y” and then Enter to save your changes.
    .
15. Now let’s setup our actual boot menu that we’ll be choosing options from:

    $ sudo nano /srv/tftp/mybootmenu.cfg

16. Again you’ll be looking at a blank text editor. Type (or copy & paste) in the following. Indenting text is not important, but makes it more readable:

    menu hshift 13
    menu width 49
    menu margin 8
    menu title My Customised Network Boot Menu
    include ubuntu-installer/i386/boot-screens/stdmenu.cfg
    menu begin Cool options
        default myfirstoption
        label myfirstoption
            menu label This is a menu item
        label mysecondoption
            menu label This is another option
    menu end

17. Press CTRL+X, then press “Y” and then Enter to save your changes.
    .
18. Finally, we need to change the permissions of all files concerned because TFTP will not read any files unless they are set to full access:

    $ sudo chmod 777 -R /srv
    

19. That’s PXE server side ready to go. Now we need to tell PXE clients where to find the PXE boot server. If you are NOT using Ubuntu as your DHCP server, then skip to step 23, otherwise do the following:
    

    $ sudo nano /etc/dhcp3/dhcp.conf

20. This opens up the DHCP config file into your text editor. Assuming your PXE server is at 192.168.0.10, scroll right to the very bottom of this file and add the following:

    next-server 192.168.0.10
    filename "/srv/tftp/pxelinux.0";

    (note the semi-colon on the end)
    .

21. Press CTRL+X, then “Y” and then Enter to save your changes.
    .
22. Restart the DHCP daemon with:
    

    $ sudo /etc/init.d/dhcpd restart

23. If you’re using a non-Ubuntu DHCP server, then look for any “network boot” options and specify the PXE boot server’s IP address and path to the pxelinux.0 file there. For example, in Smoothwall, you would go to Services->DHCP and then check the “Network boot enabled” checkbox, then specify “192.168.0.10″ (to suit our tutorial) into the “Boot server” box and “/var/lib/tftpboot/pxelinux.0″ in the “Boot filename” box and “/srv/tftp” in the “Root path” box.
    .
24. We should now be ready to try out our PXE boot server! On your test workstation or VM, enable booting off the network (in the case of PXE booting a Virtualbox VM, you must ensure that the network adapter is set to “bridged mode” instead of “NAT”) and fire away. You should first see your PC launch its PXE agent, looking for a DHCP server to tell it where the PXE server is:
    
    
25. If your PXE server is working, within a few seconds you will see your boot menu!…and if you hit Enter on “cool options” you will now see a sub-menu showing your two options that we created.
26. Well this is all well and good, but the menu currently doesn’t actually DO anything other than show us a bunch of options. How about we provide something, say the Memory Test application from the Ubuntu CD? Plus we’ll add an option to boot from the first HDD in your system. If your CD is still mounted on the server, then go back into the terminal you’ve been working in and copy over the MemTest app as follows:

    $ sudo cp /media/cdrom/install/mt86plus /srv/tftp

27. Now let’s add a menu entry for it:

    $ sudo nano /srv/tftp/mybootmenu.cfg

28. Modify the file so that it now looks like the following (add just the bolded lines):

    menu hshift 13
    menu width 49
    menu margin 8
    menu title My Customised Network Boot Menu
    include ubuntu-installer/i386/boot-screens/stdmenu.cfg
    label Boot from the first HDD
        localboot 0
    label Memory Tester
        kernel mt86plus
    menu begin Cool options
        default myfirstoption
        label myfirstoption
            menu label This is a menu item
        label mysecondoption
            menu label This is another option
    menu end

29. Save your changes and exit.
    .
30. Reboot your test PC via PXE and this time you will see your menu sport the new menu options at the top (you could have equally placed them at the bottom too):
    
31. Choosing “Memory Tester” from the menu will launch the MemTest app straight away, just like off the CD. But by now you are probably wondering “Aren’t be building off Ubuntu 10.04? Why does the menu have the old logo on it? Can we change it?” Sure, we can!
    .
32. The Ubuntu 10.04 installer CD HAS got the new Ubuntu logo, but for some reason it’s only saved as a PCX file which won’t work for the PXE boot menu. We can fix this by simply re-saving the PCX file as a PNG file. To start with, get a copy of the splash.pcx file from the /isolinux directory on the Ubuntu CD. This is the new Ubuntu logo that you normally see on the CD’s boot menu.
    .
33. Load this file into an image editor such as The GIMP and re-save it as a PNG file, eg: splash.png (of course there’s nothing stopping you from creating your own graphic either – just make sure it’s no greater than 640×480 in size and indexed down to 16 colours).
    .
    
34. Copy the re-saved image file into /srv/tftp/ubuntu-installer/i386/boot-screens and overwrite the original splash.png file.
    .
35. Ensure that the permissions of the file are set correctly again with:

    $ sudo chmod 777 -R /srv

36. And when you reboot your PXE workstation again, your menu will now look like:
    

And there you have it. A working PXE server with menu!

I will document further uses of the PXE boot facility in future articles, including how to boot the Live CD environment without the CD or a USB key, setup the ability to use your local Ubuntu mirror as an installation source for new installs, how to launch tools like Clonezilla and also how to setup a diskless boot system that uses PXE to do a normal Ubuntu desktop boot directly off the network without a local hard-drive.

Stay tuned!

Since the idea of opening my PC on a regular basis to connect a drive is a bit of a turn off, I used to use an external USB drive enclosure. This works fine, but it’s a bit slow (well, at least until USB 3.0 makes its debut). The eSATA standard allows you to connect external drives at full SATA speed, but it’s not cost-effective to buy an enclosure for every external drive you have.

Enter the Docking Bay. This is a simple weighed base that allows you to connect a hard-drive in a similar way to how you used to plug in game cartridges into a classic game console like the Atari 2600. You can then eject the hard-drive and plug another one in, all without restarting the PC.

This is a review of one such Docking Bay and how it works with Ubuntu, including the wonders of hot-swapping.

I came across this generic eSATA Docking Bay whilst browsing my local PC store. eSATA Docking Bays have been around for awhile now, but I never got around to getting one so I figured I may as well try this one and see how it went under Ubuntu.

With a HDD inserted into the dock.

Without the HDD inserted into the dock.

There is unit was branded “A-Power” but I’ve seen several of these drives with various brand names on it, so this one is as generic as they come, but it comes in one of three variants:

1. eSATA and USB Docking Bay
2. eSATA and USB Docking Bay with in-built USB card-reader
3. USB-only Docking Bay with in-built USB card-reader

In my case, I got the first variant as I already have a separate card-reader.

Hooking Up

The Docking Bay is very easy to hook up. The package comes with the following components:

• The Docking Bay unit
• Power Supply
• eSATA cable
• USB cable

After connecting power, the Docking Bay is connected to the PC by the eSATA cable to a spare eSATA port on the back of your PC. You then insert the hard-drive into the slot on the top of the unit – it caters for both 3.5″ desktop hard-drives and 2.5″ notebook hard-drives. Once inserted, power on the drive using the power button at the back of the unit. The power light on the top of the Docking Bay will light up and you can now switch on your PC.

Configuration

eSATA Docking Bays don’t actually need any configuration as such. If you wish to make use of SATA’s ability to hot-swap, you will need to enable the Advanced Configuration Host Interface (AHCI) in your PC’s BIOS. Not every motherboard has AHCI, but if your machine is a recent machine, you should have AHCI capabilities. If you do not enable AHCI, you can still use your Docking Bay, however you will not be able to hot-swap a new drive without shutting down your PC first.

Using the Docking Bay

Drives inserted into the Docking bay appear like any ordinary permanently installed hard-drive inside your PC. You can format them, partition them, read and write data to them and see their SMART status like any other drive.

Doing an unscientific benchmarks using the dd app with a 7200rpm Seagate 1TB HDD, I was able to write straight zeros to the drive at a rate of about 116MB/s and read at about 120MB/s.

Real-world file copying transferred data at about 86MB/s which is consistent with normal single-drive copy speeds.

Doing a fresh installation of Ubuntu Karmic 9.10 on the hard-drive and booting my system from the docking bay and then repeating the boot test with the drive attached directly to the internal SATA connection as normal, Ubuntu booted in precisely the same amount of time, as one would expect. I was also able to dual-boot Ubuntu with Windows 7 without any issue.

Hot-swapping works well also. While Ubuntu is running, I insert my hard-drive into the dock, power on the drive and wait a few seconds. The drive appears in the Places menu, you choose it, enter your sudo password to mount the drive, and the drive appears on your desktop. When you are done with the drive, you simply do a right-mouse-click on the drive’s icon, choose “Unmount” and wait for any data to be written to the drive. Once the drive icon disappears off the desktop, you can then power off the drive in the docking bay, then press the eject button to remove the drive.

Dealing with differently sized drives, I tried a half-height Seagate 500GB I have (see photos). The spring-loaded flap on the top of the drive was able to hold the drive in place without a problem. Trying with a 2.5″ notebook HDD, the docking bay provides a cut-out section that allows you to insert the 2.5″ HDD but the flap does not press directly against the drive.

Conclusion

The convenience of a hard-drive docking station cannot be understated. This unit provides a simple, effective interface. For AUD$25 it’s cheap and in the last couple of months I’ve been using this unit, it has proven to be very reliable.

While this unit is not exactly the most elegant-looking of devices, it does the job and does it well.

Review score: 9 out of 10

Like

Unlike

Of course you could use a USB flash drive, but it takes twice as long to copy a file that way because you have to copy it to the flash drive and then copy it again from the flash drive to the destination PC. Besides that, what if you don’t have a flash drive big enough to transfer the files you want? Is there a quick and dirty way to transfer some files over a network without the need to install additional software to bridge the compatibility divide?

Indeed there is…

NOTE: This method is not suitable for transferring entire directories of files. While it is possible to transfer multiple files at once using this method, it is primarily intended for the transfer of very small quantities of files due to the fact that you have to initiate the transfer of each file manually – you cannot multi-select files for transfer unless you archive those files into a tarball first.

On the Ubuntu PC, open a terminal and type in the following at the $ prompt:

$ python -m SimpleHTTPServer

If this returns an error when you hit Enter, you are probably using an old version of Python, in which case use the following command instead:

$ python -c "import SimpleHTTPServer;SimpleHTTPServer.test()"

When you hit Enter, you should see a message similar to the following:

Serving HTTP on 0.0.0.0 port 8000 ...

What we have done is started a basic mini web server using Python on port 8000 which will now happily serve files from the current directory you started the Python command from! Now open up a web browser on the other PC and, assuming your Ubuntu PC’s IP address is 10.0.0.27, surf to the following web address:

http://10.0.0.27:8000

Viola! A full directory listing on the Ubuntu PC is presented that you can now navigate and download files from without needing to install any other software to effect a transfer. Just right-click and save like any normal download link on any ordinary website.

If you started the Python command from your Home directory, then the root of the site starts from your Home directory. If you change to another directory before launching the Python command, the web server will serve files from that directory instead. Standard security rules apply – whatever access your Ubuntu user has will be applied to the Python web server. It is not recommended that you run this command as root.

When you’re done, simply press CTRL+C to stop the Python web server on the Ubuntu PC.

Happy file transfers!

• You’ve decided to change where you update your Apt-Mirror archive from (eg: you’ve changed ISP’s or feel that another source is more reliable than your current one to update from)
• You’re adding another large repository to your Apt-Mirror archive (such as the next version of Ubuntu) and don’t have the quota to download it, so you’re getting a friend to download it for you from their free server using Apt-Mirror (eg: iiNet and Internode customers can access their respective Ubuntu mirrors for free), so you need to be able to merge it with your own Apt-Mirror archive and have it update from your preferred source afterwards.

So how do you do this? Read on.

Migrating your Apt-Mirror archive to update from a new source

This one is really easy. Let’s say you are updating your Ubuntu mirror from Internode, but now want to get your updates from iiNet. To make this happen you need to change the following files:

• Your /etc/apt/mirror.list file needs to be updated to point to the new source, and
• the Apt-Mirror’s record of downloaded files needs to be updated so that it doesn’t waste time trying to re-download the entire mirror again not realising that it’s already got 99% of all the files already, because Apt-Mirror tracks the files it has downloaded by the source URL and filename, not just the filenames themselves.

So let’s go through this.

1. Open a terminal load your /etc/apt/mirror.list file into your favourite text editor. In this case I will use the Nano text editor:

   $ sudo nano /etc/apt/mirror.list

2. In your mirror.list file, The lines for updating Ubuntu 32 and 64-bit versions plus source code from Internode can look similar to this:

   # Ubuntu 9.10 Karmic Koala 32-bit
   deb-i386 http://mirror.internode.on.net/pub/ubuntu/ubuntu karmic main restricted universe multiverse
   deb-i386 http://mirror.internode.on.net/pub/ubuntu/ubuntu karmic-updates main restricted universe multiverse
   deb-i386 http://mirror.internode.on.net/pub/ubuntu/ubuntu karmic-backports main restricted universe multiverse
   deb-i386 http://mirror.internode.on.net/pub/ubuntu/ubuntu karmic-security main restricted universe multiverse
   deb-i386 http://mirror.internode.on.net/pub/ubuntu/ubuntu karmic-proposed main restricted universe multiverse
   
   # Ubuntu 9.10 Karmic Koala 64-bit
   deb-amd64 http://mirror.internode.on.net/pub/ubuntu/ubuntu karmic main restricted universe multiverse
   deb-amd64 http://mirror.internode.on.net/pub/ubuntu/ubuntu karmic-updates main restricted universe multiverse
   deb-amd64 http://mirror.internode.on.net/pub/ubuntu/ubuntu karmic-backports main restricted universe multiverse
   deb-amd64 http://mirror.internode.on.net/pub/ubuntu/ubuntu karmic-security main restricted universe multiverse
   deb-amd64 http://mirror.internode.on.net/pub/ubuntu/ubuntu karmic-proposed main restricted universe multiverse
   
   # Ubuntu 9.10 Karmic Koala Source
   deb-src http://mirror.internode.on.net/pub/ubuntu/ubuntu karmic main restricted universe multiverse
   deb-src http://mirror.internode.on.net/pub/ubuntu/ubuntu karmic-updates main restricted universe multiverse
   deb-src http://mirror.internode.on.net/pub/ubuntu/ubuntu karmic-backports main restricted universe multiverse
   deb-src http://mirror.internode.on.net/pub/ubuntu/ubuntu karmic-security main restricted universe multiverse
   deb-src http://mirror.internode.on.net/pub/ubuntu/ubuntu karmic-proposed main restricted universe multiverse

3. We need to change the Internode URL to the iiNet URL, so bring up Nano’s search and replace function by pressing CTRL+Backslash (“\”).
   .
4. Now type in the text to replace, in this case:

   http://mirror.internode.on.net/pub/ubuntu/ubuntu

5. Press Enter and you’ll be prompted for the text to replace this with. In this case it’s:

   http://ftp.iinet.net.au/pub/ubuntu/

6. Press Enter and Nano will find the first occurrence of the Internode text string and highlight it for you. If the selection is correct, press “A” on the keyboard to automatically replace “all” occurrences.
   .
7. Once the update is done, manually go back and visually verify that all the entries were changed correctly.
   .
8. When you’re happy, save your changes by pressing CTRL+X, then “Y” and then Enter.
   .
9. Now we need to update the Apt-Mirror record of downloaded files. First, let’s take a backup of the index in case you stuff up. Type in:

   $ sudo cp /var/spool/apt-mirror/var/ALL /var/spool/apt-mirror/var/ALL_Backup

   NOTE: the filename “ALL” must be in uppercase
   .

10. Now let’s bring up the original file into the Nano text editor.

    $ sudo nano /var/spool/apt-mirror/var/ALL

11. Depending how large your index file is, there may be a brief delay while Nano opens it up. Once it appears, do the same search and replace as you did in steps 3-6 again. Note: If the editor comes up blank, then you have not opened up the index file – check your path spelling in Step 9 and try again.
    .
12. Save your changes by pressing CTRL+X, then “Y” and then Enter.
    .
13. Finally, we need to modify the Apt-Mirror’s cache of downloaded files so that its directory structure matches that of the new source. In the case of iiNet, you’ll notice it’s URL has one less ubuntu word in it compared to Internode’s URL, so we’ll need to move some directories to eliminate the extra ubuntu directory. At the terminal, move the dists and pool directories of the mirrored files one directory back using the commands:

    $ sudo mv /var/spool/apt-mirror/mirror/mirror.internode.on.net/pub/ubuntu/ubuntu/dists /var/spool/apt-mirror/mirror/mirror.internode.on.net/pub/ubuntu
    $ sudo mv /var/spool/apt-mirror/mirror/mirror.internode.on.net/pub/ubuntu/ubuntu/pool /var/spool/apt-mirror/mirror/mirror.internode.on.net/pub/ubuntu

14. Now rename the mirror.internode.on.net directory to become the name of the iiNet server:

    $ sudo mv /var/spool/apt-mirror/mirror/mirror.internode.on.net /var/spool/apt-mirror/mirror/ftp.iinet.net.au

15. The directory structure now matches iiNet’s server and your ALL file is up to date, so now we can test your changes by launching Apt-Mirror. Launch it manually with:

    $ apt-mirror

16. Watch the output. First Apt-Mirror will download all the repository indexes from the new location and will compare the files presented in those indexes to your local index of downloaded files (the modified ALL file). It will skip all files already listed as being present and will only download new files not listed in your local mirror. You should find Apt-Mirror advises only a small subset of data to download, perhaps only a few megabytes or no more than a gigabyte or two since your last update under the old setup. If you see that Apt-Mirror wants to download some 30GB or more, then you have made an error in changing the URL in the ALL index file or you incorrectly renamed the mirror directories. Press CTRL+C to stop Apt-Mirror, and go check your configuration from Step 10.

    $ apt-mirror
    Downloading 1080 index files using 5 threads...
    Begin time: Wed Dec  9 15:59:23 2009
    [5]... [4]... [3]... [2]... [1]... [0]...
    End time: Wed Dec  9 16:00:45 2009
    
    Proceed indexes: [SSSSSSSSSSPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP]
    
    1.7 GiB will be downloaded into archive.
    Downloading 998 archive files using 5 threads...
    Begin time: Wed Dec  9 16:02:31 2009
    [5]... [4]... [3]... [2]... [1]... [0]...
    End time: Wed Dec  9 16:54:15 2009
    
    207.4 MiB in 256 files and 1 directories can be freed.
    Run /var/spool/apt-mirror/var/clean.sh for this purpose.
    $

17. You’re done! Pat yourself on the back.

Inserting a foreign Apt-Mirror archive into your own archive

This one is slightly more involved, but is not difficult. In the case of a full Ubuntu Mirror, let’s say you were adding an Ubuntu Karmic mirror archive taken from iiNet’s mirror servers into your own local Apt-Mirror archive that featured only Intrepid and Jaunty, both of which you are updating from Internode’s mirror servers. There are some obstacles we need to overcome such as:

• Continuing to perform future updates for the Karmic repository from Internode rather than iiNet.
• The foreign iiNet Karmic archive contains lots of files that you already have in your own archive – files that are common between all releases of Ubuntu. How do you filter those ones out and only copy the new files?
• Finally, how do you update the Apt-Mirror index file with the potentially thousands of new entries from the foreign archive? How do you avoid duplicate lines potentially confusing Apt-Mirror?

Follow these steps:

1. First ensure that you have the full copy of the foreign Apt-Mirror archive supplied on a suitable storage medium. Aside from the mirror directory itself (usually under /var/spool/apt-mirror/mirror), you must have a copy of its /var/spool/apt-mirror/var/ALL file. It does not matter if the foreign mirror is not completely up to date, as Apt-Mirror will catch up with what is missing when you run the next update.
   .
2. Let’s prepare your local Apt-Mirror installation for grabbing Ubuntu Karmic from our preferred source first. We need to load up the /etc/apt/mirror.list file into your favourite text editor and add the entries relevant to our new repository that we are mirroring. I will use the Nano text editor for this, but you can use any text editor you like:

   $ sudo nano /etc/apt/mirror.list

3. Now we add the entries relevant to Ubuntu Karmic for Apt-Mirror to use. In this case, I am going to update Ubuntu Karmic from Internode and I will be grabbing both the 32-bit and 64-bit versions plus the source code (reflecting what is already included in the foreign archive on my storage medium, or Apt-Mirror will be doing a LOT of downloading the next time you run it), so I need to add the following entries:

   # Ubuntu 9.10 Karmic Koala 32-bit
   deb-i386 http://mirror.internode.on.net/pub/ubuntu/ubuntu karmic main restricted universe multiverse
   deb-i386 http://mirror.internode.on.net/pub/ubuntu/ubuntu karmic-updates main restricted universe multiverse
   deb-i386 http://mirror.internode.on.net/pub/ubuntu/ubuntu karmic-backports main restricted universe multiverse
   deb-i386 http://mirror.internode.on.net/pub/ubuntu/ubuntu karmic-security main restricted universe multiverse
   deb-i386 http://mirror.internode.on.net/pub/ubuntu/ubuntu karmic-proposed main restricted universe multiverse
   
   # Ubuntu 9.10 Karmic Koala 64-bit
   deb-amd64 http://mirror.internode.on.net/pub/ubuntu/ubuntu karmic main restricted universe multiverse
   deb-amd64 http://mirror.internode.on.net/pub/ubuntu/ubuntu karmic-updates main restricted universe multiverse
   deb-amd64 http://mirror.internode.on.net/pub/ubuntu/ubuntu karmic-backports main restricted universe multiverse
   deb-amd64 http://mirror.internode.on.net/pub/ubuntu/ubuntu karmic-security main restricted universe multiverse
   deb-amd64 http://mirror.internode.on.net/pub/ubuntu/ubuntu karmic-proposed main restricted universe multiverse
   
   # Ubuntu 9.10 Karmic Koala Source
   deb-src http://mirror.internode.on.net/pub/ubuntu/ubuntu karmic main restricted universe multiverse
   deb-src http://mirror.internode.on.net/pub/ubuntu/ubuntu karmic-updates main restricted universe multiverse
   deb-src http://mirror.internode.on.net/pub/ubuntu/ubuntu karmic-backports main restricted universe multiverse
   deb-src http://mirror.internode.on.net/pub/ubuntu/ubuntu karmic-security main restricted universe multiverse
   deb-src http://mirror.internode.on.net/pub/ubuntu/ubuntu karmic-proposed main restricted universe multiverse

4. Save your changes and exit the editor using CTRL+X, then “Y” and then Enter.
   .
5. Make a backup copy of the foreign mirror’s /var/spool/apt-mirror/var/ALL file, so you can revert to it if you make a mistake. Call the copy something like ALL_Backup.
   .
6. Now open the foreign mirror’s original /var/spool/apt-mirror/var/ALL file into your favourite text editor.
   .
7. Use your text editor’s search and replace function (in Nano, press CTRL + Backslash “\”) to replace the URL of each entry in the foreign mirror’s ALL file to the URL of the mirror you will be performing your future updates from. In the case of changing iiNet URLs to Internode URLs, you would replace any occurrence of the text string:

   http://ftp.iinet.net.au/pub/ubuntu

   …with…

   http://mirror.internode.on.net/pub/ubuntu/ubuntu

8. Once updated, save your changes and close your text editor.
   .
9. Now we need to merge the modified foreign ALL file into the ALL file from your local Apt-Mirror setup. First up, rename the modified foreign ALL file so we don’t confuse it. For this tutorial, I will assume your foreign mirror is supplied on an external USB hard-drive called “myhdd” and is simply a copy of the foreign system’s /var directory in its entirety. The following will rename the file from ALL to ALL_modified in a terminal:

   $ mv /media/myhdd/var/spool/apt-mirror/var/ALL /media/myhdd/var/spool/apt-mirror/var/ALL_modified
   

10. Now concatenate the original ALL file and the modified foreign mirror’s ALL_modified file into one new file called ALL_new in your local Apt-Mirror’s var directory. Concatenating alone will result in duplicate lines and we need to sort the file so that any duplicate lines in both the local and foreign ALL files are brought together. We can sort the content of the concatenated files and remove duplicate lines in one hit with:

    $ sudo cat /var/spool/apt-mirror/var/ALL /media/myhdd/var/spool/apt-mirror/var/ALL_modified | sort | uniq > /var/spool/apt-mirror/var/ALL_new
    

    The cat part of the command simply joins the content of /var/spool/apt-mirror/var/ALL and /media/myhdd/var/spool/apt-mirror/var/ALL_modified into one big file, but before it’s written to a physical file, the concatenated data is “piped” using the pipe symbol “|” into the sort command, which sorts the concatenated data into alphabetical order which will group duplicate lines together. But before that resultant output is written anywhere, the sorted data is then piped again into the uniq command which automagically removes all duplicate lines, leaving one unique copy of each line. Finally, we direct the output from uniq using the “>” character into our physical destination file at /var/spool/apt-mirror/var/ALL_new at the end. The sudo command at the start is used simply because only the root and the apt-mirror users can actually write to the /var/spool/apt-mirror/var directory.

    Alternatively, we can replace the “| sort | uniq” part with “| sort -u” which does the exact same thing, since the sort command does have it’s own “unique” functionality as well. I’ll leave it up to you which way you’d like to go.

11. Check your new /var/spool/apt-mirror/var/ALL_new file and you will find it now contains all your local and foreign mirror’s entries in alphabetical order and with no duplicate lines. If you’d like to see how this worked, re-work Step 10 without the sort and uniq commands or the pipe characters and see how it affects the output file. Try adding just the sort or just the uniq command too.
    .
12. Now rename your local mirror’s original ALL file because we’re about to replace it with the new one:

    $ sudo mv /var/spool/apt-mirror/var/ALL /var/spool/apt-mirror/var/ALL_old

13. Now rename the new ALL_new file to take the place of the old one:

    $ sudo mv /var/spool/apt-mirror/var/ALL_new /var/spool/apt-mirror/var/ALL

14. Right, that’s the index taken care of. We’re nearly done! Now we only have to merge the foreign mirror’s actual files into your local mirror. Once again, for the purposes of this tutorial I’m going to assume you have them stored on an external USB hard-drive called “myhdd” and is a copy of the foreign system’s entire /var directory, so the path to the foreign mirror’s files will be /media/myhdd/var/spool/apt-mirror/mirror – got that? Let’s change to that directory now in a terminal to save us having to type so much:

    $ cd /media/myhdd/var/spool/apt-mirror/mirror

15. Now, the observant of you may have noticed that Apt-Mirror stores its mirrored files using a directory structure that follows the path of the URL the data is obtained from, so in the case of a mirror from iiNet, there is a directory here called ftp.iinet.net.au. You can see it by using the ls command to list the directory contents:

    $ ls -l
    -rw-r--r--  1 apt-mirror apt-mirror   198599 2009-12-09 10:19 access.log
    -rw-r--r--  1 apt-mirror apt-mirror   544373 2009-12-01 06:45 access.log.1
    -rw-r--r--  1 apt-mirror apt-mirror  1863467 2009-11-03 06:44 access.log.2
    -rw-r--r--  1 apt-mirror apt-mirror  1865334 2009-10-01 06:28 access.log.3
    -rw-r--r--  1 apt-mirror apt-mirror 18152891 2009-09-01 06:42 access.log.4
    -rw-r--r--  1 apt-mirror apt-mirror     6135 2009-12-09 06:46 error.log
    -rw-r--r--  1 apt-mirror apt-mirror    33898 2009-12-01 06:45 error.log.1
    -rw-r--r--  1 apt-mirror apt-mirror   124512 2009-11-03 06:44 error.log.2
    -rw-r--r--  1 apt-mirror apt-mirror   554851 2009-10-01 06:28 error.log.3
    -rw-r--r--  1 apt-mirror apt-mirror   831227 2009-09-01 06:42 error.log.4
    drwxr-xr-x  3 apt-mirror apt-mirror     4096 2008-09-11 02:00 ftp.iinet.net.au
    $

16. We need to modify the foreign directory names and structure to exactly match that of the URL path your local mirror updates from. Starting with the obvious, we need to rename the ftp.iinet.net.au directory to be mirror.internode.on.net with:

    $ sudo mv ftp.iinet.net.au mirror.internode.on.net

17. Next we need to create an extra subdirectory called “ubuntu” because Internode’s URL path is mirror.internode.on.net/pub/ubuntu/ubuntu/ and iiNet’s path is ftp.iinet.net.au/pub/ubuntu/ only:

    $ sudo mkdir mirror.internode.on.net/pub/ubuntu/ubuntu

18. Now we need to move the “dists” and “pool” directories under the first “ubuntu” directory to be under the second “ubuntu” directory:

    $ sudo mv mirror.internode.on.net/pub/ubuntu/dists mirror.internode.on.net/pub/ubuntu/ubuntu
    $ sudo mv mirror.internode.on.net/pub/ubuntu/pool mirror.internode.on.net/pub/ubuntu/ubuntu

19. With the directory structure and directory names all amended, we are now ready to merge the foreign mirror’s files into your local mirror. We will do this using RSync. This tool traditionally is used to make backups and is indeed used to keep the official worldwide Ubuntu mirrors up to date 1:1 with the master archive, but in our case we are using it to add the “missing” files in the local mirror with the files from the foreign mirror whilst skipping the files that are already present, which means instead of copying around about 60GB worth of data from the foreign mirror, we’ll only copy a percentage of that instead, saving us time and drive space:

    $ sudo rsync -avz --progress /media/myhdd/var/spool/apt-mirror/mirror/mirror.internode.on.net /var/spool/apt-mirror/mirror/

20. The “–progress” parameter allows you to see which file is being copied over. You may see a large number of directory names whizz past because those directories don’t have any files that are different between your current Ubuntu Intrepid and Jaunty mirror and the Karmic mirror you are merging. Unfortunately rsync does not provide an all-over progress. It only provides a progress of the file it is currently working on. This procress can take several hours to complete depending on how much data needs to be copied and the speed of your storage medium containing the foreign mirror (which if on a USB HDD can take a looooong time).
    .
21. Once RSync has finished, it will give a summary of what was copied. If you were to run the rsync command in Step 16 again, you will see it finish rather quickly because there is no data that has changed or is missing anymore.
    .
22. Now we just quickly ensure that all the merged foreign files belong to the Apt-Mirror user with:

    $ sudo chown apt-mirror:apt-mirror -R /var/spool/apt-mirror

23. And now we are ready to try a manual update to see if it all worked. If you now execute the Apt-Mirror application manually, you should now see that it reads in the new repository entries you added into your /etc/apt/mirror.list file in Step 3 and will compare the files presented in those indexes to your local index of downloaded files (the newly modified ALL file). It will skip all files already present and will only download new files not present in your local mirror. You should find Apt-Mirror advises only a small subset of data to download, perhaps only a few megabytes or a gigabyte or two since your last update under the old setup and depending on how old the foreign archive was. If you see that Apt-Mirror wants to download about 30GB or more, then you have made an error in changing the URL in the ALL index file or the renaming of mirror directories. Press CTRL+C to stop Apt-Mirror, and go check your configuration from Step 5.

    $ apt-mirror
    Downloading 1080 index files using 5 threads...
    Begin time: Wed Dec  9 15:59:23 2009
    [5]... [4]... [3]... [2]... [1]... [0]...
    End time: Wed Dec  9 16:00:45 2009
    
    Proceed indexes: [SSSSSSSSSSPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP]
    
    1.7 GiB will be downloaded into archive.
    Downloading 998 archive files using 5 threads...
    Begin time: Wed Dec  9 16:02:31 2009
    [5]... [4]... [3]... [2]... [1]... [0]...
    End time: Wed Dec  9 16:54:15 2009
    
    207.4 MiB in 256 files and 1 directories can be freed.
    Run /var/spool/apt-mirror/var/clean.sh for this purpose.
    $

24. If all is good, then pat yourself on the back. You’ve successfully merged the foreign repository and it will now update from your preferred ISP’s mirror from now on.

First up, you need to follow the first 15 steps of my guide on how to seutp a Nokia N95 mobile phone as a Mobile Broadband Device because we need to update the version of the Bluez Bluetooth stack and pair your mobile phone. Once you get to step 15 where it asks about connecting the phone as a dial-up networking device, you can either choose to continue setting that up all the way through to Step 22 (after all, you might find DUN to be of genuine use to you if you’re a Mobile Internet kind of guy), or choose “Don’t connect” instead and just finish at Step 15 and continue on with this article.

Once you’re Bluetooth stack is updated and your mobile phone is paired, transfrerring files is simplicity itself:

1. Do a left-mouse click on the Bluetooth icon in your system tray. The Bluetooth Devices window will appear showing you your available or previously paired devices. Your mobile phone will be one of them.
   .
   .
2. Do a right-mouse click on your mobile phone and choose “Browse” from the menu that appears (or select the mobile phone with the left-mouse button and then click on the “Browse” button in the toolbar).
   .
   .
   NOTE: If you get a “Could not display ‘obex://[xx:xx:xx:xx:xx:xx]/’.” error when trying to browse, it means that the Bluetooth connection has not re-established itself between your PC and your phone after a previous pairing (ie: “Host is down”). To fix this, click on the “Search” button in the toolbar which will “awaken” your phone’s Bluetooth awareness and then choose “Browse device” again. You should also set your PC and phone to be “trusted” or “authorised” on both sides to prevent timeouts caused by either end asking you for permission to establish the connection.
   .
3. If your PC is setup as being “trusted” or “authorised” on your phone, within a second or so a Nautilus window should appear showing you the content of your mobile phone, or in the case of my Nokia N95, two Windows-like folders named “C:” and “E:” which represent the phone’s internal memory and my 8GB SD card in the phone. You can browse them like any ordinary folders including copying and pasting files. An icon for the phone will also appear on the desktop (I’m using a custom icon here).
   .
   .
4. When you have finished dealing with the files on your phone, you need to cleanly disconnect the phone and end the Bluetooth session. You can do this one of two ways. Either click on the “Eject” triangle icon next to your phone’s name in the Places list of the Nautilus window, or in the Bluetooth Devices window, do a right-mouse click and choose “Disconnect Device” from the menu.
   .
   .
5. That’s it! Happy file transfers!

Like most people, I use an external hard-drive to backup data to, or to shift things around if I’m low on space on my PC’s internal drive. Well, today that external drive reported that it was full. Damn.

So I fire up Ubuntu’s Disk Usage Analyser, aka Boabab, to find out what’s consuming the most space. I use a 1TB external drive and it’s formatted total is about 916GB, which is about right, however Boabab reported that the total consumption of data on the drive only added up to about 860GB – wtf? Even Nautilus’s Volume Properties window was reporting that the drive still had 50GB-odd free, so why is the system telling me it’s full?

I use Ext3 on my drives and, being a journalled filesystem, some space on the drive is reserved to record these journals among other functions which is expected, but 50GB worth? I did some research and found out that the Ext3 filesystem reserves 5% of disk space by default for itself! In this day and age of large drives, that’s a huge chunk of lost space!!

Thankfully there is a way to tell Linux not to reserve so much space. Read on…

1. First up, unmount your drive. You can do that by either right-clicking on the drive icon on the desktop and choosing “Unmount volume” or by clicking on the Eject icon next to it in the Places pane of any Nautilus window.
   .
2. Next, open up a terminal and type the following:

   $ sudo fdisk -l
   

   This will list all your available drives. Identify which one is your external drive and take note of the device name, eg: in my case my external drive appears as /dev/sdb with one partition on it, sdb1.
   .

3. Now type in the following:

   $ sudo tune2fs -m 1 /dev/sdb1
   

   This will modify the filesystem on that drive, on that one partition, to only reserve 1% instead of the default 5%.
   .

4. Now re-mount your drive by clicking on its name in the Places pane in a Naultilus window.
   .
5. The Nautilus Device Properties window will still show the same free space as before, because it reports the true total free space, but any Nautilus File Manager window only reports usable free space, which in the case of my external drive had now freed up a very sizable 37GB!
   .
6. Lather, rinse, repeat on any other non-system drive partitions on the same or different drive you want to reclaim space back for.

You learn something new everyday.

Today, we now have 32GB USB Flash Drives that go for a paltry AUD$95, and this is a review of Transcend’s offering.

I have to admit I’m a bit of sucker for Transcend. They make good products that perform well at a reasonable price, and I have bought several of their USB Flash Drive products over the last 5 years from 1GB through to 8GB. Sure, there are solutions that are much faster than Trancend, such as Corsair, but along with that comes a larger price tag. The Transcend product is competitively priced and performs more than acceptably to be used even as a boot device.

So today I obtained a 32GB stick. The package is simple – along with some catalogue advertising material, the stick itself is roughly 10mm x 50mm in size and is about 6mm deep, comes with a Transcend-branded lanyard, a removable thin clear plastic layer on the burgundy-coloured part of the stick to protect it from scratches and that’s pretty much it. The non-retractable USB connector is protected by a removable plastic cap. Refreshingly, the cardboard insert from the packaging actually makes reference to Linux as a supported platform, citing a requirement of kernel 2.4.2 or later.

Click for full size (230K)

Like all sticks these days, this USB 2.0 unit is pre-formatted to FAT32 thus allowing it to work with pretty much every major platform out there. Personally I rarely use my sticks on Windows PC’s, though I keep an 8GB stick handy with FAT32 just in case. Most of the time, however, I reformat them to EXT2 or EXT3.

So, let’s plug this guy in. It’s always interesting to see how they implement the activity LED (well OK, it’s hardly anything to write home about, but I’ve got to generate some excitement somehow…!). Previous Transcend sticks had an obvious dot on the top, usually sporting a blue LED as has been the trend for the last few years, but this time they’ve gone different. There is no obvious hole on the stick for an activity light and upon connecting it to my PC’s front USB ports, the end of the stick suddenly lit up in bright roadwork-vest-orange. Well, that’s a welcome change. I can leave it plugged in a dark room without it becoming distracting! The LED remains on all the time to show that it is active and flashes HDD-style when there is activity.

Click for full size (118K)

Nautilus popped up its usual “what do you want to do” prompt and I elected to open a window. As typical with most USB Flash Drives, this one came up imaginatively titled “disk” which is Ubuntu’s way of telling you that the stick has no actual label. The stick itself is completely empty – no promotional software or funky one-touch-backup applications are included.

First thing was first – relabel that stick. There’s nothing worse than having several USB Flash Drives and not knowing what’s on them at a glance. I fired up Ubuntu’s Partition Editor (GParted) and had a look at the stick. The stick’s actual storage space is 29.92GB and I observed that the leading 4MB were not allocated. Usually you find most Windows-formatted devices have the last few MB unallocatable, not that it actually matters.

Anyway, I quickly unmounted the stick and renamed it and remounted it. For those that are interested, this is what the dmesg output for it looks like:

usb 8-3: new high speed USB device using ehci_hcd and address 8
usb 8-3: configuration #1 chosen from 1 choice
scsi19 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 8
usb-storage: waiting for device to settle before scanning
usb-storage: device scan complete
scsi 19:0:0:0: Direct-Access     JetFlash Transcend 32GB   8.07 PQ: 0 ANSI: 2
sd 19:0:0:0: [sdf] 62750720 512-byte hardware sectors (32128 MB)
sd 19:0:0:0: [sdf] Write Protect is off
sd 19:0:0:0: [sdf] Mode Sense: 03 00 00 00
sd 19:0:0:0: [sdf] Assuming drive cache: write through
sd 19:0:0:0: [sdf] 62750720 512-byte hardware sectors (32128 MB)
sd 19:0:0:0: [sdf] Write Protect is off
sd 19:0:0:0: [sdf] Mode Sense: 03 00 00 00
sd 19:0:0:0: [sdf] Assuming drive cache: write through
 sdf: sdf1
sd 19:0:0:0: [sdf] Attached SCSI removable disk
sd 19:0:0:0: Attached scsi generic sg6 type 0

Exciting stuff.

With my now-properly-named stick, it was time to do some read/write tests. The stick comes preformatted as FAT32, so we’ll use that, but at the same time I will also conduct some tests using Linux-native filesystems. In this case, EXT3. Our test data will be a series of 15,645 thumbnail images, each averaging about 18K in size. We will also do a large file copy test using a compressed high-definition video file at 3.1GB in size. We will time how long it takes to copy this data to the USB Flash Drive and calculate the transfer speed from that. Then we will reboot the machine, to ensure no data is cached, and copy that data back from the USB stick to measure the read speed.

For comparison, we will also do the EXT3 tests with an older (6 month old) 8GB USB Flash Drive, also made by Transcend, to see if there has been a notable change in read or write speed between products.

First up, the small file copy test. Our test data is 15,645 thumbnail files from our host PC’s hard-drive, each averaging about 18K in size (total 281MB).

• Using the FAT32 filesystem on the 32GB stick, copying the small files took 12 minutes to copy at approximately 345K per second. Ouch – slow.
• Using the Ext3 filesystem on the 32GB stick, copying the same files took only 2 minutes and 53 seconds at a rate of approximately 1.6MB per second. Much better.
• And using the EXT3 filesystem on the older 8GB stick, copying the same data took only 2 minutes and 40 seconds, just edging out the 32GB stick.

Now for the large file copy test. Our test data is a single 3.1GB high-definition video file being copied from the host PC’s hard-drive.

• Using the FAT32 filesystem on the 32GB stick, copying the large file took a pathetic 69 minutes and 24 seconds to transfer, or about 780K per second. It really shows that FAT32 really does not like large files at all.
• Using the Ext3 filesystem on the 32GB stick, copying the same file took a far more respectable 6 minutes and 16 seconds to complete at approximately 8.4MB per second.
• Finally, the Ext3-formatted 8GB stick copied the file in 5 minutes and 55 seconds, which beats the 32GB stick, but only by about 20 seconds and half a megabyte per second (8.9MB/s).

To be fair, Windows’ NTFS filesystem should show reasonably similar figures to Ext3, but I did not test that as this article is about Ubuntu, not Windows!

Finally, we have the read-test. We rebooted the host PC to clear any cached data and copied only the 3.1GB large file from the USB stick to the host PC’s hard-drive.

• The FAT32-formatted 32GB stick copied the file in 3 minutes and 13 seconds. Exponentially faster than its write action.
• The EXT3-formatted 32GB stick took 2 minutes and 32 seconds to copy the file.
• The EXT3-formatted 8GB stick by comparison did the same copy in 3 minutes and four seconds. Interesting that it’s a slow reader compared to the 32Gb stick, but a slightly faster writer.

So transfer speeds have largely remained unchanged between generations, which is a Good Thing(TM) – if there is any faster speed, then that’s a bonus, but the last thing you want is greater capacity at a tragic expense of transfer speed, and whilst we do have that discrepancy here, it’s negligible at best.

Conclusion

Trancend’s 32GB USB Flash Drive is not the largest currently-available on the market, but it is certainly one of the most affordable and has good performance to boot. Aesthetically, the white plastic looks and feels a little cheap, but the stick as a whole feels robust and could probably take a few knocks without having a fit. The lanyard included is more than adequate to hang around your neck with, and the overall size of the stick means you could also comfortably add it to your keyring or hip pocket without it getting in the way, though the separate USB cap could probably be easily lost in that instance.

Review score: 8 out of 10

Like

Unlike

So, to that end, here is an update to my previous HowTo for connecting a Bluetooth mobile phone to Ubuntu Gusty or Ubuntu Hardy.

EDIT August 2009: If you are wanting to connect your phone using Ubuntu Jaunty or later, you should follow these updated instructions instead of this article.

Pre-requisites:

• Bluetooth-enabled mobile phone (I’m using a Nokia N95 in this guide).
• USB Bluetooth adapter or PC with built-in Bluetooth such as a modern-day notebook. Your adapter must be Bluetooth 1.2 compliant or higher.
• A PC with Ubuntu Linux 8.10 Intrepid Ibex installed.

Difficulty level: Mind-bogglingly easy. Point and click, essentially!

1. First, plug in your USB Bluetooth adapter or enable it on your notebook. Ubuntu should recognise it immediately with no need for additional drivers. You can optionally confirm that by jumping into a terminal as issuing the lsusb command to list your USB devices:

   $ lsusb | grep tooth
   Bus 001 Device 005: ID 1310:0001 Roper Class 1 Bluetooth Dongle
   $

2. You’ll be happy to know that Ubuntu comes pre-installed with everything you need to get Bluetooth running, and if the driver is loaded successfully, you will see a Bluetooth icon appear in your system tray, awaiting your bidding.
   .



3. Do a single left-mouse click on the Bluetooth icon and a menu appears showing “Setup new device…”.
   .
   



4. Once you choose the menu option, the Bluetooth Device Wizard will appear.
   .
   
   .
   
5. Click Forward and your system will begin scanning for local Bluetooth devices. Whatever it finds will be shown in the list (note that this may take a few seconds to update). One of them should be your Bluetooth-enabled mobile phone (which will initially appears as its MAC address, but then after a few seconds will change to the name assigned to that device). If you cannot see your phone after a few seconds, make sure that Bluetooth is enabled on your handset and try again from Step 3.
   .
   
   .
   
   
6. Select your phone and his Forward. Ubuntu will then generate a random PIN number and commence a pairing request with your phone. Your phone handset, meantime, should immediately prompt you to enter the randomly-generated PIN number.
   .
   
   .
   
7. Once you have entered the PIN code on your phone, Ubuntu will complete the pairing request and that’s it – pairing done!
   .
   
   .
   
8. Now we can start doing things, such as file transfers. Go back to the Bluetooth icon in your System Tray and this time do a single right-mouse click on it. A new menu appears. Go to “Browse files on device…”.
   .
   
   .
9. You will be asked which of your paired Bluetooth devices you wish to browse. Choose your phone from the list and click the “Connect” button.
   .
   
   .
   
10. After a brief delay, a Nautilus window should pop up showing your phone’s “drives”. In the case of my Nokia N95, the phone’s internal memory is presented a Windows-esque C: drive and the memory card is presented as E: drive. What appears here is ultimately down to how your phone manufacturer has implemented the filesystem.
    .
    
    .
11. At this time, an icon for your phone will also be added to your desktop (I use a custom icon on mine):
    .
    
    .
12. Browse and copy files as normal. When you are done, you should disconnect your phone by unmounting it with the Unmount or Eject right-mouse menu options (or the Eject icon next to your phone’s name in the Bookmark list).
    .
    
    .
13. And that’s it! Pat yourself on the back. Job done.

Like

Unlike

Title aside, this is one of yet another series of pre-packaged drive & enclosure solutions being bandied about the market today. These solutions are gaining interest with a lot of consumers because they generally manage to undercut the combined cost of buying the same hard-drive and enclosure separately, so much in fact that many users who only need the drive, buy the solution package, rip out the drive and discard the case because in some cases (pun not intended), it can be cheaper this way.

Cost aside, what if you simply need to have a cost-effective external portable backup solution with minimal hassles? That immediately calls for a notebook hard-drive that can be powered by the USB data cable.

A quick trip down to the weekly gatherings of some of my favourite vendors saw me come across Fujitsu’s answer to the masses – the intriguingly named Dynadisq III unit, available in several sizes. I am using the 320GB model for this review.

For AUD$130 you get:

• A single 320GB SATA 2.5″ notebook-sized hard-drive.
• Smart-looking matte silver enclosure with mini-USB, 5v external power and a small “Backup” button with some moderate styling and the Fujitsu logo embossed on top (the hard-drive is already pre-installed in the enclosure). The top side also features two LED’s – one green one for power and a red one for the obligatory activity notification. No blue LED’s in sight.
• A nice fake-leather pouch with a pocket and elastic strap to hold the drive, and several side pockets for cards and, er… stuff.
• A USB to mini-USB data lead.
• A USB to 5v-power lead.
• One-page “getting started” instructions (for Windows users only despite saying the unit will work on a “range of different computer operating systems”).
• A 50MB backup application installation CD-ROM (again, for Windows only).

The components come all packaged in a neatly presented and protected cardboard package.

The drive and case itself is lightweight and generally attractive to look at, with the fake leather pouch putting a bit of sophistication into the package, but then again, who buys an external hard-drive to be sophisticated?

Unfortunately, while the idea seems nice, the pouch just ain’t big enough to hold both the drive and cables together.

Plugging it in

Upon plugging it in to my Ubuntu Intrepid desktop, dmesg reported the following:

Nov  9 14:59:49 lamaar kernel: [ 1018.916011] usb 8-6: new high speed USB device using ehci_hcd and address 4
Nov  9 14:59:50 lamaar kernel: [ 1019.055454] usb 8-6: configuration #1 chosen from 1 choice
Nov  9 14:59:50 lamaar kernel: [ 1019.056230] scsi9 : SCSI emulation for USB Mass Storage devices
Nov  9 14:59:55 lamaar kernel: [ 1024.060657] scsi 9:0:0:0: Direct-Access     FUJITSU  DYNADISQ III     1.95 PQ: 0 ANSI: 2
Nov  9 14:59:55 lamaar kernel: [ 1024.062645] sd 9:0:0:0: [sdf] 625142445 512-byte hardware sectors (320073 MB)
Nov  9 14:59:55 lamaar kernel: [ 1024.063018] sd 9:0:0:0: [sdf] Write Protect is off
Nov  9 14:59:55 lamaar kernel: [ 1024.063640] sd 9:0:0:0: [sdf] 625142445 512-byte hardware sectors (320073 MB)
Nov  9 14:59:55 lamaar kernel: [ 1024.064017] sd 9:0:0:0: [sdf] Write Protect is off
Nov  9 14:59:55 lamaar kernel: [ 1024.064023]  sdf: sdf1
Nov  9 14:59:55 lamaar kernel: [ 1024.084377] sd 9:0:0:0: [sdf] Attached SCSI disk
Nov  9 14:59:55 lamaar kernel: [ 1024.084467] sd 9:0:0:0: Attached scsi generic sg6 type 0

So far so good, but not less than a few seconds later when GNOME tried to present the drive, the following dialog reared its ugly head:

Well, that confirms that it’s formatted for Windows out-of-the-box. Shame on Fujitsu for not properly unmounting the drive during factory testing! And what an exciting volume name they gave it too. Rather than shamelessly promote themselves, Fujitsu simply left it as the Windows-standard “New Volume”. Yay.

I was curious to find out if there was any included software on the drive itself. Maybe If I was lucky there would be random photos of factory workers testing the drives? Maybe I could find secret launch codes for Ballistic Nerf Missiles in the Southern Atlantic? Who knows what I could find?

I quickly fired up Virtualbox, setup the Fujitsu drive as a USB device for my Windows XP Virtual Machine and fired up. Upon checking the content of the drive, I was presented with… nothing. Nada. Zip. Zilch. Totally empty. What a disappointment.

I did a proper disconnect on the drive and shut Windows down. I then fired up GParted to repartition the drive for Ext3.

GParted reports the drive as only containing 302GB of physical storage space, which follows the whole 1,000MB versus 1,024MB in a GB debate that always surrounds drive sizes.

Repartitioning the drive into a single giant 320GB partition took just over 3 minutes to complete.

Turtle or Hare?

So let’s try some real-world file read/write tests.

I decided to go with the following basic tests involving the copying of data:

1. Copy from my desktop hard-drive to RAM
2. Copy from my desktop hard-drive to my aging Samsung 160GB IDE external USB notebook HDD
3. Copy from my desktop hard-drive to the Fujitsu Dynadisq III 320GB SATA external USB notebook HDD

Timing was done by hand with a stop watch from the triggering of the copy action to the closing of the file transfer progress window.

First up, let’s copy a single 2.2GB DV video file.

Figure 1: Time to copy a single large file

According to GNOME’s Nautilus, RAM was pulling a transfer rate of 85.4MB/s, the Samsung drive was pulling 30.2MB/s and our review Fujitsu was pulling 40.5MB/s – a notable difference over the Samsung.

Next up, we copy 7,762 small files all between 10K and 25K each (total 146.9MB) comprised of various image thumbnails:

Figure 2: Time to copy a series of small files

Nautilus didn’t have much time to evaluate the speed. RAM took less than a second to complete the copy, my Samsung drive took 3.65 seconds, and the Fujitsu took a paltry 2.98 seconds.

Finally, we go and copy 2,987 medium-sized files comprised of digital photos in various subfolders all between 250K and 1.5MB in size (2 megapixels max resolution).

Figure 3: Time to copy a series of medium files

Nautilus reported RAM pulling a transfer speed of 71MB/s, my Samsung drive did 32MB/s and the Fujitsu triumphed over the Samsung with 39MB/s.

So the Fujitsu shows an average 21% performance benefit over my little Samsung IDE unit. Not bad.

The Backup Button

Earlier I pointed out that there was a “Backup” button on the back of the drive labelled simply “Backup”. The intended use is to perform a one-touch backup of all your important data onto the external unit. Sounds great, except that it doesn’t work. Well, at least under Ubuntu it doesn’t work. The system does not recognise any press of the button – not even as a keyboard multimedia button.

The supplied CD-ROM contains the driver and backup application for use with the Backup Button, but unfortunately, it’s Windows only.

This is hardly a concern, though. You can easily throw an icon on your desktop to execute a script to backup all your important data and Linux in general has unparalleled methods for regularly backing up large volumes of data with ease, such as rsync.

Aesthetics

So what more can be said about this drive? Well, it’s quiet – barely a chirp from it. It also gets a little warm, but not overly hot when doing large file copies. No biggies.

It certainly looks like a nice unit – clean design, not trying to overtly stand out. The power and activity LED’s are non-intrusive as well unlike the bright blue LED’s you find on some units.

Probably the only real downer I can say about it is the juice consumption, but this is probably unavoidable, really. The main reason I still like my little 160GB IDE unit is that it is one of the last capacities to not really require additional power. Whilst conducting my tests on the Fujitsu, I did encounter moments where the drive was reporting back to the system hard-errors and at one point simply unmounted itself. Disconnecting and reconnecting it fixed these issues and a quick run of fsck showed that there were not any actual errors on the drive. Once I had hooked up the second USB power lead, the problems never manifested themselves again.

Conclusion

One of the main reasons people use notebook USB drives for portable storage is for their convenience. Not only for their size, but for the fact that you can do data and power over one lead. This one requires two for any major file operations, and while that may be an inconvenience for some, it’s still a helluva lot better than having to hook up a power brick to run a 3.5″ desktop drive.

SSD’s (and to a lesser extent, USB flash drives) are still a long way off from completely replacing hard drives, and at this stage are far more expensive GB for GB, so until then, this little drive suffices nicely. It’s small, tidy, fairly quick, had a good pouch which will offer some knock protection, and while not as small as a USB flash drive, it easily fits into most pockets.

All up, this is a drive worthy of notice.

Review score: 8 out of 10

Many thanks to fellow Ubuntu compatriot Blinky who supplied the unit for review.

Like

Unlike