Atlantic Linux Blog

Marine exploration using Linux

It is always interesting to see the different environments and ways in which Linux is used in the real world. I was recently onsite with the Irish Marine Institute to install a new Linux server for them. The server configuration itself is pretty standard – using the latest stable CentOS 4.x on a new HP ProLiant server.

What is interesting about this particular piece of work is the equipment that the Linux server is being used to control. The Marine Institute is Ireland’s national agency for marine research, technology and innovation. As part of their work they are involved in a climate change program which requires them to measure data including the temperature, salinity, chlorophyll and oxygen levels of the ocean. Using this data they can model the behaviour of the ocean and understand its role in climate change in Ireland.

As well as using traditional methods for recording this data such as sensors on buoys and ship surveys – the Marine Institute is deploying an unmanned remote controlled vehicle which includes a range of sensors. The remote controlled vehicle or glider can be programmed to follow a specific course, taking measurements at various depths as it travels and sending them back to base periodically. Obviously, this gives far more flexibility than data from a static buoy and costs far less to run than a research vessel.

Which brings us back to the Linux install. The Linux server will operate as the controller for this remote glider – a Slocum electric glider developed by Webb Research. Webb provide software to talk to the glider any time it is on the surface using an Iridium satellite modem. The software allows data to be retrieved from the glider and new routes to be sent to it.

The initial installation went well – after a few teething problems. The glider, which is currently out of the water (having successfully completed initial trials), was powered on and we immediately starting seeing communications between the server and the glider. Initial tests look good and we hope to hear of the Marine Institute successfully deploying this technology in the near future. When in operation, the glider can travel distances of over 1000km and to depths of 1000m.

Tags: linux, marine research, oceanography

Setting UUIDs on new partitions

If you take a look at /etc/fstab on a recent Linux installation, you may notice it’s using lines like

UUID=663f1349-3d37-4633-af59-849eda89bae4 / ext3 defaults 0  1

instead of the more traditional

/dev/sda1       /               ext3    defaults 0  1

These universally unique identifiers (UUIDs) can be generated by the uuidgen command and can reasonably be considered unique among all UUIDs created on the local system, and among UUIDs created on other systems in the past and in the future (from the uuidgen(1) man page).

Why would you want to use a UUID rather than the far more readable /dev/sda1 (well, readable if you’re somewhat comfortable with Linux anyway)? The problem with traditional device names (like /dev/sda1) is that they are assigned by the Linux kernel at boot-time and depend on the order in which devices are found. So /dev/sda is the name the Linux kernel assigns to the first SCSI or SATA hard drive it finds, /dev/sdb is the name used for the second SCSI or SATA hard drive and so on.

This works very well until the Linux kernel detects your devices in a different order to the usual. In practice, this is a relatively rare event but it is certainly possible when moving between kernel versions and if you make changes to your system hardware (such as adding in a second SATA controller). If your device order does change, all of a sudden, your root device which used to be known as /dev/sda1 becomes /dev/sdb1 or similar. Normally this will cause a kernel panic at boot time as your Linux system attempts to mount a filesystem which doesn’t exist or which doesn’t contain the expected filesystem.

One solution to this is the use of UUIDs. When you create a new filesystem, a UUID is generated and written to the filesystem’s superblock. The /etc/fstab then refers to this UUID which will remain constant regardless of what kernel you are running or how the drive is connected to your system (indeed, if you move the drive to an entirely different system, the UUID will still be valid).

If you only create partitions during the initial installation of your OS – you won’t have to deal with creating UUIDs for your partitions, the installer should take care of it automatically.

If you create any new partitions though, you will need to assign UUIDs to those partitions manually if you wish to refer to those partitions in your /etc/fstab by UUID (you can continue to use a mix of /dev/sda1 type entries and UUID based entries in /etc/fstab if you wish). To assign new UUIDs you need to

1. Generate new UUIDs with uuidgen

   uuidgen
   f15f8aed-0073-4d2f-abec-aa5da4f72e8c

2. Write this uuid to your new partition (WARNING: Do not run these commands against an existing partition),
   for ext2, ext3 or ext4:

   sudo tune2fs -U f15f8aed-0073-4d2f-abec-aa5da4f72e8c /dev/sdc5

   for xfs:

   sudo xfs_admin -U f15f8aed-0073-4d2f-abec-aa5da4f72e8c /dev/sdc5

   for reiserfs:

   reiserfstune -u f15f8aed-0073-4d2f-abec-aa5da4f72e8c /dev/sdc5

Update: When you  create a new filesystem on a device, the command seems to allocate a uuid at that stage. To view existing uuids (in order to use them in your fstab and so on, run the blkid command).

Tags: filesystem, fstab, linux, partition, uuid

Repartitioning modern Linux systems without reboot

This one is for my own future reference as much as anything. Ever since the move to udev in Linux 2.6, I’ve found it neccesary to do the very un-Linux like thing of rebooting before the appropriate device appeared under /dev. This was only an occasional hassle but still, you shouldn’t need to reboot Linux for such a thing.

Thanks to Robert for his Google magic in turning up partprobe, part of the GNU Parted package. As the Debian man page for partprobe says

partprobe is a program that informs the operating system kernel of
partition table changes, by requesting that the operating  system
re-read the partition table.

Excellent! Parted is normally installed on Debian and Ubuntu by default anyways, if not, simply, aptitude install parted and you’ll have access to the excellent partprobe.

We were trying to add some additional swap to a running system, the full series of commands needed as follows (I could have used parted to create the partition  but the cfdisk tool has a nice interface),

1. sudo cfdisk /dev/sda (and create new partition of type FD, Linux RAID)
2. sudo cfdisk /dev/sdb (and create new partition of type FD, Linux RAID)
3. sudo partprobe
4. sudo mdadm –create /dev/md3 -n 2 -x 0 -l 1 /dev/sda4 /dev/sdb4 (our swap devices are software RAID1 devices)
5. sudo /etc/init.d/udev restart (this updates /dev/disk/by-uuid/ with the new RAID device)
6. sudo mkswap /dev/md3
7. sudo vi /etc/fstab (and add a new entry for /dev/md3 as a swap device)
8. sudo swapon -a (to activate the swap device)
9. sudo swapon -s (to verify it is working)

Tags: linux, parted, partitioning, raid