Linux Tech Talk 3
January 1st, 2010 by ComputerBob
MY MAIN PC (debian1) MY SECOND PC (debian2) AMD Athlon XP 2400+ Intel Pentium 4 (2 GHz) nVidia GeForce 6200 video card nVidia GeForce 6200 video card 22″ wide-screen LCD monitor 19″ normal-aspect LCD monitor 1680 x 1050 resolution 1280 x 1024 resolution Debian Squeeze w/KDE 3.5.10 Puppy Linux (on a Live CD)
For quite awhile, I’ve been wanting to install Debian onto my second PC, but I didn’t want to have to “start from scratch” and install, configure and tweak, everything on it. And I also knew that a new Debian Squeeze install would give me grub2 and KDE 4 (both of which I’ve been avoiding for the past several months, as regular readers of this Journal know). And a new Debian Lenny install would require hundreds of painfully selective upgrades in order to upgrade it to Squeeze without upgrading grub and KDE.
I knew that because I did those selective upgrades on my main PC several months ago, and I’ve continued to do them to this day.
So instead, what I really wanted to do was to use rsync to copy the files in debian1’s / and /home partitions onto partitions on debian2, and see if debian2 would boot up and run, already configured the same way as debian1. I was concerned that it might not work, because debian1 and debian2 use different monitor resolutions and completely different CPUs — although I was pretty confident that the different CPUs would not cause a problem because they can both use the type of linux kernel (686) that is already installed on debian1.
Two days ago, I finally found the time to copy all of the files from debian1’s / and /home partitions onto debian2, using rsync on a GParted Live CD. First, I installed a second hard drive in debian1. Then I created new partitions of the correct sizes on the second hard drive. Then I copied the files from debian1’s partitions onto those new partitions on the second hard drive. Then I installed that second hard drive into debian2. Then I created new partitions of the correct sizes on debian2’s main hard drive. Then I copied the files from the second hard drive’s partitions onto the new partitions on debian2’s main hard drive.
It sounds complicated, but it feels like a pretty simple and logical process when you’re doing it.
Of course, after I did the copying, I used the Leafpad text editor on the GParted Live CD to edit and correct the paths in debian2’s /etc/fstab and /boot/grub/menu.lst.
Then I opened a root terminal and used the “grub”, “find”, “root” and “setup” commands to install grub-legacy onto the MBR of debian2’s main hard drive.
Then I removed the GParted Live CD, shut down debian2, and removed debian2’s second hard drive.
And because both PCs (debian1 and debian2) were still both configured with the same host name (debian1) at that point, I also disconnected debian2’s ethernet cable) before I powered it up again, to boot from its hard drive.
I held my breath and was very happy and relieved when debian2 booted up just fine — with no video problems. Debian Linux automatically detected debian2’s resolution during the boot process and the default Debian “nv” video driver worked perfectly, with the correct resolution.
Once debian2 was finished booting into KDE 3.5.10 I went into KDE’s network settings and changed debian2’s host name from “debian1″ to “debian2″. Looking back, I realized that I could have used the Leafpad text editor on the GParted Live CD to change debian2’s host name manually before I even powered it up, but I hadn’t thought to do a search to find out where its host name stored. I later learned that a Debian PC’s host name is stored in /etc/hostname. If Debian isn’t running (like when you boot from a Live CD), then all you have to do is change the PC’s host name in /etc/hostname before you boot it into Debian. If the PC is already running in Debian, then you need to edit /etc/hostname and and then run the following command as root:
/etc/init.d/hostname.sh start
to make the change active.
But since I didn’t know that at the time, I changed debian2’s host name in KDE, then I shut down debian2, plugged in its ethernet cable, and then powered it back on.
It booted up perfectly, and its Internet connection worked perfectly, too.
I now had 2 computers running the exact same Debian configuration.
But then I had a whole new adventure — which taught me how to install and configure an NFS (Network File System) share on my debian1 (my NFS server) that debian2 (my NFS client) would automatically mount and connect to every time debian2 booted, so that debian2 could access the files on debian1’s hard drive.
I’ve never used NFS before, so it took me awhile to get debian2 to connect to debian1 through NFS. After several hours of trial-and-error and online searches, I was finally able to get NFS to work when I manually mounted the NFS share on debian2. I did that by using debian1’s IP address (instead of its name) in the “mount” command.
Later on, I figured out that I had to add a line to debian2’s /etc/hosts file, so that debian2 could associate debian1’s name with its IP address. After I did that, I was able to mount the NFS share by using debian1’s name, instead of its IP address, in debian2’s “mount” command.
I must have read 50-75 different Web sites and forum threads while trying to troubleshoot NFS, but here are a few of the ones that I found the most helpful:
- An explanation of some NFS mounting options
- A forum thread: NFS will not mount at boot
- How to edit /etc/hosts.allow and /etc/hosts.deny to prevent hosts on other networks from connecting to your NFS share
- A forum thread: How To Share Folders With NFS
- An incredibly long forum thread: HOWTO: NFS Server/Client
Unfortunately, even after I finally got debian2 to mount debian1’s NFS share, it would only do it if I manually mounted it after debian2 was all booted up — debian2 refused to automatically mount the NFS share automatically during boot, no matter which fstab switch I used to mount the NFS share (hard, soft, _netdev, etc., etc.)
And debian2’s logs didn’t show any error messages to help me figure out the problem.
The good news is that I finally figured it out, and now debian2 mounts debian1’s NFS share during boot every single time.
The bad news is that it took me 13.5 hours to finally figure out what was causing the problem.
Yup, 13.5 hours.
The reason it took so long was because I kept Googling for answers and trying everything over and over and over and over, setting up my NFS over and over again, to try to figure out why it wasn’t set up correctly.
But what I finally discovered was that my NFS had been set up correctly the whole time!
It turned out that the whole reason that debian2 couldn’t automatically mount debian1’s NFS share during boot was because debian2 had a misconfiguration in /etc/network/interfaces that kept its networking from being up and running in time for NFS to be able to “see” debian1. And that misconfiguration was caused back when I first set up debian2 by using rsync to copy my debian1’s entire / and /home partitions onto debian2.
Of course, when I did that copying, I corrected all of the paths in my client’s /etc/fstab and /boot/grub/menu.lst before I booted it up. And changed its name from debian1 to debian2 before I connected it to my network.
But I had forgotten that debian1 has 2 ethernet ports: eth0 and eth1. I use only its eth1 port.
In contrast, debian2 only has 1 ethernet port: eth0.
So back wnen I had copied debian1’s / partition onto debian2, debian1’s copied /etc/network/interfaces file started incorrectly telling debian2 that it had 2 ethernet ports (just like debian1 does), and that it should use eth1 (just like debian1 does).
And every time debian2 booted up, it read /etc/network/interfaces and then tried to configure eth1 (which it doesn’t have), before it would finally give up on eth1, then it would figure out that eth0 was available, and then it would configure eth0.
But in the meantime, NFS on debian2 had already tried to connect to debian1, but it couldn’t, because debian2’s eth0 wasn’t up and running yet.
Which explains why, each time debian2 booted, it failed to automatically connect to debian1, and I had to manually mount the NFS share after debian2 was up and running.
But once I figured out what was causing the delay, I edited debian2’s /etc/network/interfaces file so that it contained only eth0. From that point on, debian2 was able to configure and start using eth0 right away during boot, and it was then able to mount debian1’s NFS share automatically during every boot up.
I use debian1 as my main PC, and now my wife can use debian2 as her main PC — in fact, she’s using it right now, about 3 feet away from me. Both PCs are running Debian Squeeze (Testing) — but with KDE 3.5.10 and grub-legacy instead of KDE 4 and grub2 — and both PCs save all of our email, browser settings and user-created data onto debian1’s hard drive, which I backup to a separate hard drive.
Who needs knowledge and experience when you’ve got patience, persistence and lots of time?
Permalink:
http://www.computerbob.com/wp/linux-tech-talk-3.php
Tags:
Debian, Linux, Personal, Security, Tech Support
January 1st, 2010 at 5:19 pm
I’ve copied across Linux machines a couple of times but i found it easier to use Gparted to copy the entire root and home partitions across. Then i used Super Grub CD to restore GRUB.
January 1st, 2010 at 6:07 pm
I used to use GParted to copy partitions, too, but IIRC, GParted used to use the “cp” command, which copied the entire partition bit-by-bit, which was really slow because it even copied the partition’s empty space.
I don’t know if GParted still uses the “cp” command or not, but I know that rsync copies only the actual files, so it works really fast.
January 1st, 2010 at 7:35 pm
I copy a lot of linux (mostly debian and Ubuntu) around from one machine to another - I’ve seen this problem
many times. Another gotcha in recent UDEV-based distros is that the /etc/udev/rules.d/70-persistent-net.rules
will assign the ethernet interface MAC address to eth0 and eth1, so when you copy the distro to a new
machine, your network interfaces are new, and the old nics in the old box are still in the 70-persistent-net.rules
file– so now your nics are eth2 and eth3, with eth0 and eth1 being reserved, but vestigal.
Best to clear out 70-persistent-net.rules everytime you copy a linux system to new hardware.
(my example is from an Ubuntu 8.04 system - file names for udev may vary in other distros)
Matt
January 1st, 2010 at 7:53 pm
there is also clonezilla:
http://clonezilla.org/
January 1st, 2010 at 7:55 pm
@MattW: Where were you yesterday? It sounds like you could have saved me many hours of troubleshooting!
Even though I wasn’t bitten by the /etc/udev/rules.d/70-persistent-net.rules problem this time, I’m going to follow your advice about clearing it out if I copy any configured Linux systems to new hardware in the future.
January 1st, 2010 at 8:57 pm
Both these machines *were* ordinary desktops. Now they are servers, providing a service (NFS) to each other. When they boot they probably get their IP address and other info from some DHCP server (probably your router). If a machine is going to provide services to other machine(s), it needs a fixed IP address so the other machines can always find it. You probably won’t have much problem with this setup as long as you boot these boxes in the same order, but it’s a setup for trouble. Stop using DHCP and switch to fixed IP addresses to avoid headaches later. Fair warning!
January 1st, 2010 at 10:51 pm
@Roland: Only one of my PCs (debian1) is an NFS server — the other PC (debian2) is just an NFS client.
But you make a valid point about static IP addresses. Thank you!
January 2nd, 2010 at 7:46 am
ComputerBob,
Thank you for spending your precious time to explain, share, and maintain the information regarding Linux!
Sincerely,
John and Dagny
January 3rd, 2010 at 1:06 am
There are a number of subtle problems with duplicating a debian configuration by, essentially, restoring a backup. Some being that your security public/private keys identifying the machine will be identical as will things like disk uuids — all of which are supposed to be unique. Finding and resolving all the strange problems that arise after such a duplication will often require time and expertise.
This is what the debian IRC channel tends to recommend:
msg(dpkg)] aptitude clone
[dpkg(~dpkg@dpkg.bot.oftc.net)] To clone a Debian
machine using aptitude (or install your favourite
packages) use aptitude search -F ‘%100p’ ‘~i!~M’ >
package_list; on the reference machine; xargs
aptitude –schedule-only install < package_list;
aptitude install; on the other machine. This
preserves information about “automatically
installed” packages that other methods do not.
See also…
This does not re-create specific configurations, but I find that except for gnome it’s simple to copy a the few configuration files that have been changed. When it comes to gnome or other desktop customizations there’s no harm in simply copying all the files and directories beginning with a period (.) in the home directory to re-create the user-level configuration.
(OTOH, it’s always worth restoring a backup on another piece of hardware to make sure you _can_ in case of an emergency.)
January 3rd, 2010 at 4:04 am
When cloning an OS installation, don’t worry about identical host names—they don’t mean anything (other machines get your host name from DNS or their own hosts files, anyway). What’s really important is making sure they don’t both try to use the same IP address on the same network.
Another thing I’d recommend you do is generate new SSH host keys, if you’re running an SSH server. That way you can tell them apart when you connect via SSH.
January 3rd, 2010 at 9:09 am
@Karl: Thanks for the good advice. My two PCs don’t use UUIDs or public/private security keys, so those two things haven’t caused me any problems, but I’m sure that your advice will help others who use UUIDs and security keys. Thanks for your aptitude advice — although I can’t confirm or deny whether WordPress messed up your syntax when you posted it here, so I would want to to do some searches and confirm the proper commands and syntax before atempting to use the method that you outlined. I’ve also read that copying your PC’s /etc folder will generally copy most (if not all) of its applications’ configuration settings that aren’t stored in your /home folder (like the GuardDog firewall’s settings).
@Lawrence: After I copied debian1’s entire configured / partition to debian2, those two computers had exactly the same /etc/hosts file, which gave them exactly the same host name, and those identical hosts files didn’t contain any information about debian2. That’s why I manually edited debian2’s host name. I like your advice about SSH, and I’m sure others will find it helpful, even though I don’t use it myself.
——
This Journal post is turning into quite an extensive source of tips, tricks and good advice.
January 15th, 2010 at 10:13 am
The aptitude commands look right, but of course you need to know what’s a command and what’s text, so I’ve re-done it here with line breaks and slightly re-worded. (Your blog does seem to have eaten the “see
also”.)
To clone a Debian machine using aptitude (or install your favourite packages) use (on the reference machine):
aptitude search -F '%100p' '~i!~M' > package_list;Then, on the target machine:
xargs aptitude --schedule-only install < package_list;aptitude install;
This preserves information about ‘automatically installed’ packages that other methods do not.
(And of course you need to move the “package_list” file from one machine to the other by whatever method you desire.)
Note that copying /etc/ will be the source of most of your problems if you try to copy a machine by making a duplicate. What you probably want to do is to compare the new machine’s /etc/ with the old machine’s
using diff and duplicate any changes you recognize having changed from the default.
The easiest way is to copy one machine’s /etc/ to the other with scp (which uses security keys) and then compare the results:
On the new machine:
scp -rp oldmachine:/etc /tmp/etcdiff -ruN /tmp/etc/ /etc | less
You will also find a few configurations saved in /var, usually /var/spool/. See the FHS at http://pathname.com/.