Migrating Arch install to a new device/partition

STUART · 2011-05-02 06:40:44

I'm looking to gather approaches and details for migrating an existing Arch install to another (larger) disk.

Note about my specific use case: I'm migrating from an 8 GB microSD card with the root filesystem on 1 partition to a 16 GB microSD card (which I'm thinking about setting up with a 4 GB FAT32 partition for easier OS interop). I'm looking for caveats that would crop up in other setups, though.

Some of the suggestions I got from the IRC channel:

Things you can do from a non-running system (ie. a LiveCD):

Tree copy method

Create a new partition on the destination device
Mount the source and destination filesystems

Copy the source tree to the destination:

cp
```
cp -Ra /path/to/from/* /path/to/dest/
```

Tarpipe

tar -c "$srcdir" | tar -C "$destdir" -xv

Advantages:

Existing system will be brought over without taking its host filesystem's fragmentation with it
Don't have to deal with moving/resizing partitions

Block copy method

dd
dump/restore

Things you can do from your currently-running system

No idea. All I know is that I was told that you would want to avoid copying /dev, /proc, /sys, and /var.

Things that have to be revised on the new disk no matter what approach you take:

/etc/fstab
Bootloader configuration:
- GRUB
- GRUB2
- LILO=

Last edited by STUART (2011-05-02 23:58:24)

jeslinmx · 2011-05-02 09:46:09

That's about it. You probably don't want to copy /tmp either, but /var shouldn't be a problem.
After the transfer, you have to make sure that GRUB is installed on the new drive too if you are using that as the primary device for booting.
EDIT: backup your stuff! Just to be sure.

Last edited by jeslinmx (2011-05-02 09:46:59)

STUART · 2011-05-02 23:55:18

How does one create /dev, /proc, and /sys (and /tmp though I'm guessing that's just mkdir) in the target tree?
How can you do a grub-mkconfig for the new system?
How does the dd / dump+restore approach work?

Misfit138 · 2011-05-03 00:41:39

I have used cp -a over these past 7 years with 100% reliability, and can strongly recommend you use it and keep it simple.

STUART · 2011-08-09 10:05:05

Here's an update on what I've done with this so far:

A few months ago I bought a store-brand 16gb microSD card from Micro Center, planning to upgrade my existing Arch Linux installation (residing on an 8gb microSD).

So, through a clumsy series of recoveries, I got the installation migrated (I partitioned the new card with a 4GB FAT32 block first so I wouldn't get a reformat prompt from Windows every time I insert my card, and so I'd have some inter-OS file swap space).

However, after a few hours of tooling around with the installation on the new card (in the middle of a -Syu, as I remember), all write operations suddenly failed. After rebooting (from what may have been a kernel panic), I discovered to my dismay that the card had become read-only (it was cheap).

Anyway, I forgot about the whole affair for a few months until one day I walked into a Staples and saw that they had brand-name warranty-backed 16gb microSD cards for nearly the same price as I'd gotten my cheap card a few months ago, so I purchased a new one and began anew.

Instead of migrating the card as I had before (which I honestly don't even remember), I instead used a borrowed family laptop I'd installed a dual-booting Ubuntu installation to a while back, and a spare microSD reader. I booted the system up, plugged in my drives, made the same (high-concept) partition scheme as I had before on the new card with Gparted, unplugged and reinserted the card to mount, and ran

cp -a /media/sturlingcentral/* /media/sturlingroot

(I'm changing partition label schemes: sturlingcentral is the old, sturlingroot is the new.)

A few seconds later I sent SIGINT, `rm -r /media/sturlingroot/*`, and reran the cp with a `v` in the options.

A while later, I came back to the machine to see several errors popping up (I think they were "Invalid Parameter" directory creation failures), so I deleted the progress again and re-ran the copy with a tee out to a log file (to see where the errors were starting). However, the errors ended up filling my buffer anyway, so I redid the command with tees for both streams:

cp -av /media/sturlingcentral/* /media/sturlingroot > >(tee stdout.log) 2> >(tee stderr.log >&2)

When the command failed again, I reviewed the errors, and determined them to be in an arbitrary enough place to exonerate any software problem. I then moved to the conclusion that it was the cards / the readers overheating (on top of the access stress, apparently Acer thinks the edges of the heating vents are great places to put the only 2 USB ports on the laptop), and so continued the copy with the -u option, doing a CTRL+C SIGINT every time failures started to occur, taking the cards out, shaking them cool, and repeating until running

cp -auv /media/sturlingcentral/* /media/sturlingroot > >(tee stdout.log) 2> >(tee stderr.log >&2)

returned to prompt with no output.

After the copies had finished, I knew there would still be problems with the files that were being copied while the card was failing, so I needed a way to determine which ones had failed. After a bit of searching, I read up on md5 deep, and after an `apt-get install md5deep`, and a little trial and error, I came to the first part of my solution:

cd /media/sturlingcentral
md5deep -relof . | tee ~/sturlc.md5

Here's a breakdown:
- The directory change was so the output paths would be relative to the current directory, and could be reused when comparing to the other directory.
- The `r` option to md5deep is required to recurse through the tree (why a program called md5DEEP doesn't do this by default is a question I leave for the philosophers).
- The `e` option outputs hash progress on the command line - useful for the 3 or so big files encountered in this operation.
- The `l` option prints relative paths in the md5 output list instead of absolute paths- necessary for matching against the other directory.
- The `o` option limits the types of nods to hash: the `f` parameter specifies that it should hash files only (since md5deep had a tendency to choke on some of the copious links / block devices / other I had present, I was willing to take my chances and hope that all non-file nodes had been copied correctly).

Once I had my list of file hashes in the source, I ran them against the target:

cd ../sturlingroot/
md5deep -X ~/sturlc.md5 -relof . | tee ~/torecp.log

`-relof .` does the same thing as it did in the previous command. The `-X` compares every node in the tree with the list from step 1, and outputs every file that doesn't match.

This is where I'm at now. I'm performing some forensics on the output from the second step by hand. Here's what I've found so far:

- For some reason, the contents of /opt (by filename) are present in ./usr/src/linux-2.6.38-ARCH/include/config/i7300/idle/ and vice versa.

Last edited by STUART (2011-08-09 10:26:33)

Arch Linux

#1 2011-05-02 06:40:44