Thursday, July 18, 2013

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.

Saturday, July 13, 2013

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.


Saturday, January 19, 2013

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.