keypad is wonky in nano

For a while now on multiple Gentoo boxes I've had an issue where the keypad keys function as if the NumLock was off even when it was on. If I tried to type a 0 it would kick off "insert from file" function. A little searching on Google revealed the following from the nano manpage:

 -K (--rebindkeypad)
            Interpret  the  numeric  keypad keys so that they all work properly.  You should only need to use this option if they don't, as mouse support won't work
            properly with this option enabled.

To fix this system-wide for everyone, just add the following to /etc/nanorc (or, on Gentoo, uncomment the line as it's probably already there:

## Fix numeric keypad key confusion problem.
set rebindkeypad

Alternatively, add the line to your ~/.nanorc.

I can't find my UUID!

In the last post I showed how to reference a partition in /etc/fstab using a UUID and ran through a couple real-world scenarios for wanting to do so.

This post is about the trouble I ran into looking for said UUIDs...

I have 6 hard drives in my server, 2 have 3 partitions each (boot, swap, root) and are raid mirrored, the other 4 have 1 each and are set up as raid 5. I'm only concerned with the first 2 for this post. After seeing the error about mounting the swap on the last bootup I figured it would be an easy fix. I knew how to list the UUIDs so I typed in that command and was greeted with a seriously lacking list of partitions:

# ls -l /dev/disk/by-uuid/
total 0
lrwxrwxrwx 1 root root 10 2008-01-25 19:44 c2ceffb9-90be-4564-a946-9d37de7725ba -> ../../hdg2
lrwxrwxrwx 1 root root 22 2008-01-25 19:44 ca583626-4a25-4af7-b6c5-8e59a502dbc2 -> ../../mapper/vg-ballzy
lrwxrwxrwx 1 root root 22 2008-01-25 19:44 f5cc881f-210a-431f-8d52-f1e5b512b57b -> ../../mapper/vg-backup

As you can see, none of the partitions from hde are listed, and only the one from hdg is listed. I'm not sure how or why the other ones are not listed.

Since the swap partitions weren't mounted I first tried mkswap to just "reformat" the swap:

# mkswap /dev/hde2
Setting up swapspace version 1, size = 1028153 kB
no label, UUID=56c2f2af-86dd-4390-ae1a-c7fb71e6ed05

Ok, Looks good so far. Let's try turning it on:

# swapon UUID=56c2f2af-86dd-4390-ae1a-c7fb71e6ed05
swapon: cannot find the device for UUID=56c2f2af-86dd-4390-ae1a-c7fb71e6ed05

But...mkswap just told me the UUID...how can it not be found?!?!?

After a little digging, I came up with the vol_id command and it clued me in to the problem:

# vol_id /dev/hde2
ID_FS_USAGE=raid
ID_FS_TYPE=linux_raid_member
ID_FS_VERSION=0.90.0
ID_FS_UUID=5088bad5:89d678b2:c125e369:2e0dbcdd
ID_FS_UUID_ENC=5088bad5:89d678b2:c125e369:2e0dbcdd
ID_FS_LABEL=
ID_FS_LABEL_ENC=
ID_FS_LABEL_SAFE=

Raid member? OK, I admit, I used to mirror my 2 swap partitions, but after seeing the performance I decided against the protection it afforded and just went back to adding 2 separate swap partitions. It seems the raid superblock was still in the partition and mkswap wasn't overwriting it for whatever reason.

After another quick google search for deleting a raid superblock, I found the proper command and here are the results:

# mdadm --zero-superblock /dev/hde2
# vol_id /dev/hde2
ID_FS_USAGE=other
ID_FS_TYPE=swap
ID_FS_VERSION=2
ID_FS_UUID=fe6bffd9-5b6b-4db9-8929-cf1575a72d67
ID_FS_UUID_ENC=fe6bffd9-5b6b-4db9-8929-cf1575a72d67
ID_FS_LABEL=
ID_FS_LABEL_ENC=
ID_FS_LABEL_SAFE=

Ahhh, the real UUID, and it sees it as swap as well. I then proceeded to update the /etc/fstab after which swapon -a correctly enabled both swaps. As to why the UUIDs are not listed under /dev, I don't know. Maybe after a reboot the other swap will show up? The other /dev/by-* listings show all the partitions properly.

EDIT: Since I'm running Gentoo, a simple udevstart causes udev to restart. Now,

ls -l /dev/disk/by-uuid/

shows both hde2 and hdg2 :).

The mystical UUID

Every filesystem (partition?) should have a uuid. On modern Linux systems you can see them with the following command:

# ls -l /dev/disk/by-uuid/
total 0
lrwxrwxrwx 1 root root 10 2008-01-25 19:44 c2ceffb9-90be-4564-a946-9d37de7725ba -> ../../hdg2

UUIDs, while a bit cumbersome to look at, are extremely nice because you can use them in a lot of places instead of a normal device name (such as /dev/hdg2 in the above example).

Tonight I moved the 2 hard drives I had plugged into the onboard IDE controller of my motherboard into a Promise Ultra100 card. Because of this, the kernel renamed the partitions from /dev/hda and /dev/hdc to /dev/hde/ and /dev/hdg. Upon booting the system I saw the following:

swapon: cannot canonicalize /dev/hda2: No such file or directory
swapon: cannot stat /dev/hda2: No such file or directory
swapon: cannot canonicalize /dev/hdc2: No such file or directory
swapon: cannot stat /dev/hdc2: No such file or directory

UUIDs will help this to never happen again.

Here are the relevant lines from my old /etc/fstab:

/dev/hda2   none    swap    sw,pri=1    0 0
/dev/hdc2   none    swap    sw,pri=1    0 0

And the new lines:

UUID=fe6bffd9-5b6b-4db9-8929-cf1575a72d67   none    swap    sw,pri=1    0 0
UUID=e2992cf5-bc3a-4b3a-a920-d9dfbe7a5a9a   none    swap    sw,pri=1    0 0

As I said, it doesn't look as pretty, but look what happens with the old /etc/fstab:

#swapon -a
# cat /proc/swaps
Filename                                Type            Size    Used    Priority

and the new:

# swapon -a
erma ~ # cat /proc/swaps
Filename                                Type            Size    Used    Priority
/dev/hde2                               partition       1004052 0       1
/dev/hdg2                               partition       1004052 0       1

If you haven't figured it out by now, by specifying partitions by UUID, you remove the dependency on where they are physically plugged into the motherboard and any kernel naming conventions. I recently had my SATA drives move around a bit after a BIOS update, so UUIDs would help out there as well.

As it happens I had some trouble finding the (correct) UUID of one of my swap partitions but that's the topic of my next post.