Migrating Home Mount Point From an Old Hard Drive to a New Replacement

The other day I found that a rather old hard drive I had been using to mount my home directory on my Linux machine had a number of bad sectors. I figured it was about time to update it to a new drive since, at 320GB, it was getting small for me along with the fact I didn't want to have to recover from the drive failing completely.

I found a suitable 1TB replacement, got it installed, then booted from a Linux Mint Live DVD. I used cfdisk to partition the hard drive similar to my old one with a swap partition and the remainder of the drive being ext4.

First use lsblk to see a layout of your hard drives:

aerotachyon@mint % lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0  83.9G  0 disk
└─sda1   8:1    0  83.9G  0 part
sdb      8:32   0 298.1G  0 disk
├─sdb1   8:33   0  11.5G  0 part
└─sdb2   8:34   0 286.7G  0 part
sdc      8:64   0 931.5G  0 disk

In my case, sda is my root drive, sdb is the old drive with home, and sdc is the new replacement for home. Next, to open cfdisk on the new drive I use:

aerotachyon@mint % sudo cfdisk /dev/sdc

From there I usually create the swap partition first. Choose 'New', then choose whether the partition will be primary or logical, I chose primary (A good run down of partioning can be read about at the Arch Wiki here). Type in the size of the partition in MB, and change it's type to 82, which is Linux swap. Press down to select the remaining free space and go through the same process, but this time have it's size be the remainder of the drive and make the type 83, which is Linux. Mark the partition you will use for the home mount point as bootable, as cfdisk won't allow you to write the partition table to the disk unless you do. Finally write the partition table to the disk.

At this point there is still a little more configuring that is needed for the new hard drive. You need to make the actual filesystems. Running lsblk again shows us the names of the new partitions:

aerotachyon@mint % lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0  83.9G  0 disk
└─sda1   8:1    0  83.9G  0 part
sdb      8:32   0 298.1G  0 disk
├─sdb1   8:33   0  11.5G  0 part
└─sdb2   8:34   0 286.7G  0 part
sdc      8:64   0 931.5G  0 disk
├─sdc1   8:65   0  11.5G  0 part
└─sdc2   8:66   0 920.1G  0 part

To make the the home portion of the new drive ext4 and the swap partition swap, use:

aerotachyon@mint % sudo mkfs.ext4 /dev/sdc2
aerotachyon@mint % sudo mkswap /dev/sdc1

Now you are ready to start copying files. Here, what is important is copying file permissions, hidden files, symlinks and not changing modification times. Also something that shows progress will be really nice since chances are a lot of data is being copied. Something that does all of this, and can resume if the transfer is stopped for some reason, is rsync.

First we need to create places to mount the old and new hard drives, mount them, then invoke the rsync command:

aerotachyon@mint % sudo mkdir /mnt/oldhome
aerotachyon@mint % sudo mkdir /mnt/newhome

aerotachyon@mint % sudo mount /dev/sdb2 /mnt/oldhome
aerotachyon@mint % sudo mount /dev/sdc2 /mnt/newhome

aerotachyon@mint % sudo rsync -avP /mnt/oldhome/ /mnt/newhome/

Note that the trailing forward slashes on the directories are necessary to let rsync know to copy the contents of the folder into the other folder. As for the rsync options, the -a stands for archive mode, which means it actually is selecting the options -rlptgoD. Going down the list in order:

r - will go into all the directories
l - will keep symlinks as symlinks
p - will preserve permissions
t - will preserve modification times
g - will preserve the group
o - will preserve the owner
D wil preserve device files and special files

The final two options:

v - will print every file that is being copied
P - will keep partial files for resuming and will also track progress of individual file transfers

This checks off everything on our list.

Now while the transfer is taking place, you can update your /etc/fstab since it will be necessary to properly mount your new drive as home when you boot, and the transfer can take quite a while. (Note: Here I am assuming you are using UUID's to designate your drives in the fstab. If not, from what I understand, as long as your new /home drive is plugged in to the same spot on your motherboard as your old one, an update of the fstab isn't necessary.)

First you need to create a directory and mount your root drive:

aerotachyon@mint % sudo mkdir /mnt/root
aerotachyon@mint % sudo mount /dev/sda1 /mnt/root

Next open the /etc/fstab file in an editor. Here I use vi:

aerotachyon@mint % sudo vi /mnt/root/etc/fstab

My fstab looked like this:

#
# /etc/fstab: static file system information
#
# <file system>    <dir>    <type>    <options>    <dump>    <pass>
# /dev/sda1
UUID=8fba4dae-d320-4d1d-8fe3-56118bf1c9f5    /             ext4          defaults,relatime    0 1

# /dev/sdb2
UUID=b49ef1a1-c63b-468e-a552-b16db8a1ce29    /home         ext4          defaults,relatime    0 2

# /dev/sdb1
UUID=d6dda3f4-3fdb-435e-ba92-333c0a41d089    none          swap          defaults      0 0

Here all I need to do is update the UUID values from the ones on the old hard drive to the new ones. (Note here that the lines preceded by # are comments and do not need to be edited. However, for the sake of clarity it is a good idea to update them.)

To find these values, I know of two ways. The first and easiest is:

aerotachyon@mint % lsblk -f
NAME   FSTYPE LABEL UUID                                 MOUNTPOINT
sda                                                     
└─sda1 ext4         8fba4dae-d320-4d1d-8fe3-56118bf1c9f5
sdb                                                     
├─sdb1 swap         d6dda3f4-3fdb-435e-ba92-333c0a41d089
└─sdb2 ext4         b49ef1a1-c63b-468e-a552-b16db8a1ce29
sdc                                                     
├─sdc1 swap         d9538553-1392-4933-b856-894f0f6ac682
└─sdc2 ext4         4d82a479-ccf5-4291-827d-97345e703f8f

For some reason, however, lsblk wasn't showing the UUID's from the live DVD. The other option is to list the files in the directory /dev/disk/by-uuid/ by typing:

aerotachyon@mint % ls -l /dev/disk/by-uuid/
total 0
lrwxrwxrwx 1 root root 10 Jul 18 04:21 4d82a479-ccf5-4291-827d-97345e703f8f -> ../../sdc2
lrwxrwxrwx 1 root root 10 Jul 18 04:21 8fba4dae-d320-4d1d-8fe3-56118bf1c9f5 -> ../../sda1
lrwxrwxrwx 1 root root 10 Jul 18 04:21 b49ef1a1-c63b-468e-a552-b16db8a1ce29 -> ../../sdb2
lrwxrwxrwx 1 root root 10 Jul 18 04:21 d6dda3f4-3fdb-435e-ba92-333c0a41d089 -> ../../sdb1
lrwxrwxrwx 1 root root 10 Jul 18 04:21 d9538553-1392-4933-b856-894f0f6ac682 -> ../../sdc1

Once you have the UUIDs, replace the old UUIDs in the fstab and save, then wait for the transfer to finish. Finally, unmount all your drives, reboot, and you're good to go.

Soft Blocked Wireless in Arch Linux

I recently had a need to get the wireless card in my desktop working again, which was no major task as I had done it before with my particular card, but this time around I ran into a problem I had never encountered before. My card was soft blocked. Not only did I not initially know what this was but nothing I tried would unblock my card. Since I didn't find anything online that dealt with my specific issue, here is the process I went through and the eventual solution I found.

First, I knew the card had a Broadcom 4306 Rev3 chipset with a PC-ID of 14e4:4320. According to wireless.kernel.org's information here, this meant the b43 firmware was necessary to get the card working properly. The Arch Wiki broadcom page states that the firmware package is in the AUR, so I proceeded to install that and follow the additional instructions on the wiki page. After this the device was recognized, but no wireless yet. I checked the status and name of the device with:

aerotachyon@arch % ip link

Which told me my device was named wlp3s7 and that it was down. I tried fixing that with:

aerotachyon@arch% sudo ip link set wlp3s7 up

SIOCSIFFLAGS: Operation not possible due to RF-kill

I didn't know enough to make heads or tales of this error, so I consulted Google finding out that a utility called 'rfkill' could solve my problems. I hadn't installed it yet and it was in the core repository, so I quickly installed it with:

aerotachyon@arch % sudo pacman -S rfkill

Next on the list was to have rfkill list all the devices:

aerotachyon@arch % rfkill list all
0: phy0: Wireless LAN
    Soft blocked: yes
    Hard blocked: no

Here I could see that the card was soft blocked. I did some more searching and found out that a soft block is essentially the kernel or some software disabling the card (please correct me if I am wrong here, as I couldn't find anything very definitive). The next step was to have rfkill unblock the card, then list the devices to make sure it worked:

aerotachyon@arch % sudo rfkill unblock all
aerotachyon@arch % rfkill list all
0: phy0: Wireless LAN
    Soft blocked: yes
    Hard blocked: no

After seeing it didn't work, I tried to find an explanation as to why it didn't but came up empty handed.

At this point I had run out of ideas and decided I would try another card. I wasn't completely confident it would fix the problem, but it was a last ditch effort. Additionally, at the very least, I could get a card with a kernel supported chipset that didn't require any proprietary firmware so I wouldn't need to worry about having another computer handy to get my desktop setup any time I decided to try a new distribution or do a fresh install.

I knew I could get a supported wireless card from Think Penguin's site, but I was under a time constraint and needed one I could get from a local store. I ended up finding a TP-Link TL-WN851ND for about $25 that has an Atheros AR9227 chipset which uses the ath9k driver. According the Arch Wiki wireless page, it is officially supported and included in the Linux kernel since v2.6.27.

After it was installed, I booted to find it not working. First I checked to see if the module was loaded:

aerotachyon@arch % lsmod | grep ath9k
ath9k                  88740  0
ath9k_common            2096  1 ath9k
ath9k_hw              373214  2 ath9k_common,ath9k
ath                    15489  3 ath9k_common,ath9k,ath9k_hw
mac80211              488494  1 ath9k
cfg80211              452332  3 ath,ath9k,mac80211

I could see the module did load and checking with a quick 'ip link' command, saw the interface was down. I tried setting it up again as before, but encountered the same SIOCSIFFLAGS error. Checking with rfkill the card was softblocked and was still unable to unblock the card.

I wanted to check that this card would work, like it should, out of the box on a system that hadn't been altered as much as mine had. I tried a Linux Mint Cinnamon live DVD I had handy and, sure enough, the wireless worked immediately without any configuring necessary.

Now that I knew it wasn't just a problem with my old card but more a problem with the state of my system, I started to think harder about the soft block. Since it was my understanding that software could be blocking the card, I double checked to see that Network Manager (since that is what I am using) was set up correctly according to the corresponding Arch wiki page, but to no avail.

Finally, it had occured to me that it may be software packaged with another desktop environment I had installed to give a try. I had Enlightenment (E17) and i3 installed that I hadn't really used. I proceeded to uninstall them and finally was able to unblock the card and get my wireless working.

If anyone does happen to know the exact cause of this issue and why rfkill couldn't unblock the card, please leave an explanation. It still bugs me that I don't know the exact cause.

Arch Linux: eth0 Down on Boot

I finally decided to give Arch a try after a handful of people recommending it to me. Having never installed it before I followed along with their Beginners' Guide in the wiki. Everything went smoothly through the installation all the way up to rebooting the system. After the reboot I started to go about installing programs I would need, but found that I had no internet connection. First I wanted to see what ip would say about my wired connection:

aerotachyon % ip link

In the output I noticed 2 things:

1. The interface was down
2. The interface was named enp2s0

The first one I expected, but the second I did not because on installation it was know as eth0. I assume this has to do with udev naming networking interfaces differently than in the past, as noted in the installation guide, but I expected it to happen when I booted off the installation disk.

To fix this, I went back to the networking part of the guide looking for where I set up eth0. The command I had issued was:

aerotachyon % systemctl enable dhcpcd@eth0.service

I had to disable eth0 first then enable enp2s0 using the following two commands:

aerotachyon % systemctl disable dhcpcd@eth0.service

aerotachyon % systemctl enable dhcpcd@enp2s0.service

From my understanding this should have worked, but after rebooting I still had the same issue. I had noticed after issuing the enable command a file was created.

aerotachyon % ls /etc/systemd/system/multi-user.target.wants/ dhcpcd@eth0.service

The relevant file should have been for the enp2s0 but, as indicated by it's file name, it was for eth0. All that was needed to correct the problem was changing the file name to:

dhcpcd@enp2s0.service

After a quick reboot to confirm, I was good to go.

Fedora 17 with ibam and ibamtray

I recently reinstalled Fedora 17 on my laptop and instead of using one of the default usual spins (Gnome, KDE, XFCE or LXDE) I wanted to try something different. A friend of mine who uses Arch mentioned he uses a combination of Openbox and fbpanel which he really enjoys. This sounded as good as any and noticing that the LXDE spin comes with Openbox, I installed that spin.

After everything was installed and I got fbpanel up and running, I tried to use the battery plugin that's built in but it didn't work. Assuming I figure that problem out, it will be the subject of a future post. In the mean time I installed ibam or Intelligent Battery Monitor. You can read about it at their sourceforge page. Initially it didn't work. I was getting an error 'No apm data available'. After some searching I found that the location for my battery information is:

/sys/class/power_supply/BAT0/ 

whereas ibam was looking in:

/sys/class/power_supply/BAT1/

That was a simple enough to fix. If you look in the ibam.inl file, you'll see this around line 962:

      acpi.close();
      apm = new acpi_status();
   } else {
      sysfs.open((sysfs_path+"/BAT1/charge_full").c_str());
      if(sysfs.is_open()) {

All that was needed was to change BAT1 to BAT0 and recompile, then I was good to go.

Next was to install ibamtry, a system tray frontend for ibam based on vubat found here. Unfortunately, that too was not working. Every time i would try to run ibamtray from the terminal, I would get this:

aerotachyon % ibamtray

Traceback (most recent call last):
  File "/bin/ibamtray", line 6, in <module>
    app.run ()
  File "/usr/lib/python2.7/site-packages/ibamtray.py", line 96, in run
    self.update_status ()
  File "/usr/lib/python2.7/site-packages/ibamtray.py", line 145, in update_status
    n.show()
glib.GError: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Notifications was not provided by any .service files

Everything I could find relating to the last line of the output had something to do with notification-daemon. I tried testing it by running:

notify-send "hello"

which failed produce a notification. I figured I should try running the daemon explicitly, but wasn't sure where it was in the filesystem to run it. Issuing the following command:

aerotachyon % whereis notification-daemon
notification-daemon: /usr/libexec/notification-daemon

gave me the location of what I needed to run. Once it was started, I tried sending a notification again with notify-send and it worked. From there I just needed to add the following lines to my Openbox autostart file to start the daemon and ibamtray upon starting Openbox:

/usr/libexec/notification-daemon &
ibamtray &

Now I have a nice battery monitor in the tray with notifications. In hindsight I'm glad the fbpanel battery plugin didn't work because ibam seems to be much more accurate at predicting discharge and charge times along with having better tray icons.

Vim Key Map For Fortran 77 Continue Line Character

I started learning Fortran because the code I would be working with in a research project was written in Fortran 77. As a result, the Fortran I learned was a fixed column format Fortran based on punch cards. The punch cards had 80 columns with the following format:

1-5: For statement labels, essentially line referencing.
6: For a continuation character to continue a previous  line (this is what we're interested in)
7-72: For statements, basically the actual code
73-80: Ignored by the compiler.

Since this was how I  learned Fortran, it is how I continue to use it. Eventually I got tired of manually adding the ampersand in column 6 of a line that is a continuation, so I set out to make the task much quicker.

I identified 2 different cases in which I would need to add the continuation character. The first was if I was typing a line that reached column 72. In this case I would be in insert mode and would like to press the key(s) I have the shortcut mapped to, and have the ampersand in the correct place on the next line with my cursor following it in insert mode to allow me to continue typing the line. To do this I used a key mapping as it would be quicker that the abbreviation I described here.

Key mappings in Vim are very easy to implement. The syntax is as follows:

:map key_with_mapping sequence_of_keystrokes_to_be_mapped

A simple example would be:

:map <C-g> o<esc> 

This will, when Ctrl-g is pressed, press 'o' and then 'Esc' which would open the next line in insert mode and the exit insert mode.

For my case, this is what I used:

 imap <C-a> <esc>o<home><space><space><space><space><space>&

Since I put it in my .gvimrc, I didn't need the leading colon. The imap just means that it only works in insert mode, whereas a vmap would work in visual mode. So, when I press Ctrl-a in insert mode it escapes to visual mode, opens the next line in insert mode, moves to the first column of the line, enters 5 spaces, then the ampersand. I'm left with the ampersand in the correct place with the cursor in column 7 in insert mode ready to continue my line of code.

More information on Vim key mappings can be found if you type:

:help key-mapping

while in visual mode in Vim.

I'll add my second case for adding the continue line quickly in the near future.

Commenting Multiple Lines in Vim

I do a bit of programming in Fortran and periodically I find myself wanting to comment out a block of code for whatever reason. In Vim this is relatively easy. Just highlight the lines you would like to comment and type:

:s/^/\!

The s is for subtitute, the ^ character designates the front of each line, and the exclamation (which has to be escaped with the \ character) is the comment character for Fortran. This can be replaced by any comment character the language you may use requires, but not all characters will need to be escaped like the exclamation does. Similarly to uncomment selected lines:

:s/^/\!/

 Now, I find this tedious and frustrating to type in and/or remember. To streamline the commenting and uncommenting process, I make use of abbreviations. Essentially, you define an abbreviation and what should be substituted for that abbreviation. When you type the abbreviation, Vim will automatically substitute it for you. The syntax is as follows:

:ab <abbreviation> <unabbreviated substitution>

where ':ab' is the command  (you type this in the Vim window), <abbreviation> is what you type, and <unabbreviated substitution> in what replaces the abbreviation. Also note that spaces in the unabbreviated substitution are acceptable. You also do not inclue the '<>' characters.

Here is how it would work with commenting multiple lines:

:ab com s/^/\!
:ab ucom s/^/\!/

Now, all you need to type in once the lines are selected is,

:com
:ucom

to comment or uncomment those lines.

This method will only work for the particular instance of Vim that you are working in, meaning you would need to type this at the start of each session. An easier method would be to place the commands in your .vimrc or .gvimrc file, without the leading colon, and they will be defined every time you start up Vim.

Hopefully, A Beginning And Not The End

For the most part, I am a inexperienced Linux user. This requires extensive use of google, hoping any problems I have are common enough that I can find solutions rather quickly. Every now and again I run into that dreaded thread, depicted in this xkcd comic: http://xkcd.com/979/. The purpose of this blog is to document all problems and solutions I come across in my Linux endeavors for the reference of others (hence the name of the blog), and for myself.

Most of what I have learned has been from trying to understand the commands I am told to run, as opposed to posting output and waiting for the next command. As a result, my goal is to explain everything clearly enough that something is learned from reading a post, in addition to fixing the problem.

There is no set schedule for posts. I simply will post solutions to problems as I come across them, assuming I have the time. A friend of mine will also help with contributions on the same basis. Hopefully, at some point, we'll help someone.