[svlug] Adding a new HDD -- mini-HOWTO -- a newer version
aludal at SoftHome.net
Tue Mar 27 15:00:01 PST 2001
Attached is a new version, please consider and post. Or post and consider.
Sorry for >80, it's my fighting combination of KMail+KWrite that strips the
attachment completely off of its EOLs.
-------------- next part --------------
Adding a new HDD -- mini-HOWTO
'Salvation of a drowning person
is in the hands of this very
I. Ilf and E. Petrov
Version 0.0.1-10, March 27 2001AD, Copyright Alexander UDALOV (aludal at softhome.net)
This document covers the most important and urgent matters for an emergency rescue of an overbloated and asphyxiating Linux system. It describes a simplified procedure of adding a new HDD to a Linux system, and careful steps of transferring the /usr filesystem to it.
The author of the present mini-HOWTO in no way takes any responsibilities for anyone using the below recommendation in a harmful manner. Just backup what you've got, and don't read further. Well, look for and ask some other expert who might be willing to take responsibility for your dumb actions.
Do not search the solutions for SCSI disks here: there are none. Look for SCSI HOWTO at LDP or elsewhere instead.
This mini-HOWTO was born because of my own need -- and lack of coherent and sound advice from the rest of Linux community. Basically, there were dozens of helping hands for me, starting from a hint of an obscure Russian hacker with unpronounceable name and ending with a tip from Alan Cox. Some may argue that it is in this very variety of solutions the real power and flexibility of Linux resides. I do not think so. Not in this case, at least. This flexibility has the power to destroy your system in no time at all. Freedom and anarchy are sweet words in general, but they might amount to schizophrenia when somebody would be trying three different approaches to a single task in system administration. Well, I don't pretend I have the best solution of them all, I might not have seen them all, after all. But my solution is at least reversible. You didn't like it -- you could roll back with no losses.
So, having discovered that a partition on my old HDD with my /usr filesystem is nearly full (it was 95 %, but I advise you'd better never go beyond 90 %, at any session! well, I warned you...) I was looking for a safe, sane, clinically proven way to:
1. add a new HDD to my Linux box,
2. then transfer my /usr filesystem to it with nearly 100 % of success.
To make a long story of searches short, below are my
-- Linux System Administrators' Guide, v. 0.6, by Lars Wirzenius, -- for general clarification on partitions and filesystems;
-- Linux Tips HOWTO, v. 0.1, by Vince Reed (short tip 2.1 by Alan Cox is meant) -- for showing an explicit example of unsafe way, or HOWNOTTO;
-- numerous contributors from all over the world, presenting all different stages of system administration schizophrenia, -- for hints and tips you'd better use on somebody else's systems.
-- Silicon Valley Linux User Group (SVLUG) gurus: Aaron Lehmann, J C Lawrence, Bill Jonas, Rick Moen, Eric Gray, Drew Bertola, Karsten M. Self, et al., who have contributed a lot since the version 0.0.1-4 of this document.
Chapter 1. Adding a new HDD
'Gumption is the psychic gasoline
that keeps the whole thing going.'
Robert M. Pirsig, in 'Zen and the
Art of Motorcycle Maintenance
The following applies to an (E)IDE controlled HDD. If you have decided (for some obscure reason) to add a SCSI HDD to your relatively good Linux box, you're on your own, with a SCSI HOWTO's blessing. I prefer a simple charm of cheap IDE disks. With some tweaking of hdparms for them you can produce miracles. Or you may not, but we talk about cheap HDDs here, so it's a not a big loss anyway.
Personally I bought me almost half a truckload of 3.5 year old used Western Digital Caviars 22500 at the local fleamarket at the price a little higher than what they give you for aluminum content in it when recycling. Those have a formatted capacity of 2.38 GB which is good enough for transferring my ~1.1 GB of /usr.
The foolproof HDD (hardware) installation procedure is simple:
a. Turn off your computer, open it whereever it opens, get access to empty drive bays (or the IDE controller connector on your mobo, if there's no empty drive bays available already in your system.)
b. Play with the jumper(s) on the HDD, to define your HDD as a slave. Or you can call it second master HDD if the additional interface cable is needed, because a first slave position is occupied already.
c. Connect your new HDD to a 40-pin interface cable connector on your main cable, but be careful when matching indents to not connect it a wrong way around. Though you won't kill your new HDD this way.
d. Connect 4-wire power cable to your HDD. Now you can surely kill your HDD if you succeed to stomp in this connector the wrong way.
e. Fix your HDD in an empty drive bay. If there's several empty bays in your machine, use the one which renders you less twists of connected cables. If there's no empty bay at all, use some of your imagination, and some good sticker tape. Try only to get your HDD's label facing upwards, and its PCB at the bottom of your fix. It's a nice hint of some of HDD's manufacturers.
Almost there! Now, before uttering some short prayer and firing it up, try to remember whether you use Microsoft style PnP tricks in your BIOS, or not. If the answer is 'yes', it's about time to turn PnP off, so it won't mess around.
In any case, you start you machine with F2 (or Delete) key pressed (or whatever is needed, to get to your BIOS Setup screen first.) Once in BIOS Setup, find your way there to determine your new HDD. With different vendors, there are pretty different descriptions of what exactly has to be done there, so you'd better RTFM for your mobo beforehand.
Save your new setup, pray and reboot now! I used a dual boot MS Windows98/Linux system for all these experiments, and I booted first to MS Windows, just to be on the safe side. In most cases, MS Windows95/98 must recognize your new HDD and install it automatically, so you must be 100 % sure it could be recognized by your Linux kudzu later, too. If something goes wrong at this stage, chances are you won't see your new HDD in Linux either. Bad luck!
Suppose it's all OK, and your kudzu has done a great job (if not, you go elsewhere for a full-fledged HOWTO on manual defining of your HDD params.)
Then, you (as a root, of course) can issue the following obvious commands:
(this is a full-screen fdisk-type partitioning program, and to order a Linux-type partition you may want to choose type 83, with type 82 for a Linux swap, but we don't need the latter one, do we? Also, from now on let's call our new disk hdb, and its (single) partition as hdb1, while hda2 will be that partition with bursting /usr filesystem. Of course, there might be hdb2, hdb3, etc., partitions, if you decide so for a bigger new HDD, but it's another story.)
mkfs -t ext2 /dev/hdb
(creating a filesystem of ext2 type. I assume you'd better have this type for your old bursting /usr filesystem, but you probably can make it work for other filesystem types, too. But look, I'm almost of no help with those. At least, you must be very careful with moving /proc and /dev -- if they are movable at all, that is.)
e2fsck -f -y /dev/hdb (or some prefer fsck -f -y /dev/hdb here; it's no big deal)
Now we must define a mounting point for our new, presumably clean disk:
(while in root directory, to be always on the safe side)
mount /dev/hdb1 /foo
Obviously, you want your HDD mounted at the boot time, so edit/append your /etc/fstab in the following manner (or close to it:)
/dev/hdb1 /foo ext2 defaults 0 0
There is your certain inalienable freedom in what exact parameters you write here, but don't forget to hit your CR (Enter) key if this is the last line in your /etc/fstab. Many sorrows await a non-CR hitter!
If all above was accomplished without any glitches, you could use your new HDD right away. Copy something big enough to /foo, to hear a new chirping sound, or see your new HDD LED merrily blinking. Now delete everything, play time is over, because it's /foo, and you need a /usr there! Here comes the hardest part.
Chapter 2. Transferring the filesystem between partitions
'Soglasiye yest' produkt pri polnom
I. Ilf and E. Petrov
So far, there was no use of writing another HOWTO. That is, if I could succeed when issuing a simple mv command here. No way it's that simple! Remember, you deal with your /usr filesystem containing thousands of links. What about permissions, ownerships, inodes, superblocks? How many daemons are using the deepest and most hidden files in your /usr right now? Just stop and think twice, like I did. I also did some research.
The first tip I want to discuss here is by some Alan Cox, and it goes like this:
' 2.1 Moving directories between filesystems.
Quick way to move an entire tree of files from one disk to another:
(cd /source/directory; tar cf - . ) | (cd /dest/directory; tar xvfp -) '
It may sound like a quick way, and the tar pipelining is considered as an overall elegant and dependable tool for big-time system administration, but is it 100 % foolproof for an average home user? Well, it might be a good solution for filesystem transfers over networks, which is not exactly the case discussed here. Now, the speed of the whole operation is questionable here too, especially for slower systems. You may also want to check whether you have tar version mature enough to not include bugs once held responsible for losses of file attributes while archiving/concatenating. But if you sure you have the latest, bulletproof tar in your system, then you can follow the Mr. Alan Cox's example. Just read my Disclaimer, and that's all you will hear from me.
The same reasoning applies to another well-known archiving trick: namely, an option 3 ('Make a release of the current subdirectory (tar.gz)'), or an option 4 ('Make a release of the current subdirectory (tar.bz2)') in Midnight Commander F2 menu. These options use tar again, nothing else!
In India local Linux users favor the following Mahabharata:
find . -depth -print | cpio -pdmlu --preserve-modification-time --verbose /foo \ &>tmp/cpio.log
Looks very smart, but also intimidating because of hinting of ages of slave manual labor in deciphering and untangling zillions of errors in cpio.log. ('\' is nothing meaninful here, except for showing that the command line is unbroken.)
Rick Moen and Karsten M. Self pointed me to this resource: http://wwwsc13.custhelp.com/cgi-bin/varesearch/solution?11=010228-0000&130=0983415877&14=&2715=&15=&2716=&57=search&58=&2900=hoU2NCrGpV&25=6&3=rsync┴ which offers half a truckload of solutions for a filesystem mover at bay. You may want to check it yourself, but as long as you are with me, here's the highlights of what could be found there:
a. In general, you may use rsync, cp, cpio, tar, dd, or dump/restore, to move your filesystem. (Now I wonder, of what has left, which one or two commands, or utilities you definitely CANNOT use for the purpose?)
b. An obvious cp command is listed first, as too obvious and unsophisticated enough.
c. rsync is considered the fastest way. Thanks to Aaron Lehman, it's good to know also that it occasionally hangs with big (~1 GB and more) filesystems being whizzed over SSH transport.
d. Compression is considered as superfluous in tar, rsync and elsewhere, when doing local jobs. This is nice to hear!
e. dd utility was included as a wrong tool for the job. Only the Great Masters of Penguin Order could and may use this tool. Mere mortals shall do cp -ax --sparse for awhile. (Thanx for the '--sparse' tip, anyway.)
OK, if you haven't got so much to lose in your /usr directory (and you have your backup of it, right?) you are free to use any recipe above. Personally I preferred to stay on the safest side, and after several days of hot discussions and deep thoughts I could stand by the following solution now (again, see the Disclaimer above, anyway.)
Step 1. Go single-user mode
I made it simply by editing this line in my /etc/inittab file to look like below:
There are more elegant ways to kill other users and daemons in your system unawares, I admit (like issuing init 1, whatever you at at the moment, kudos to Eric Gray for a tip) but I somehow feel mine is cleaner, however rude. Now, after reboot, you're a root, and at least, all daemons and other users are dead by the book.
Step 2. Moving the behemoth
Actually, you do it by copying it with much less hoopla than discussed above:
cp -a /usr /foo
(The most popular warning sent to me was invariably 'add -x option' to exclude /proc, /dev from the process. Yes, it won't hurt anything issuing 'cp -ax /usr /foo' instead, but who on earth stores /proc or /dev inside /usr, I'd like to know?)
Step 3. Go grab yourself a cup of coffee (can of beer, soda)
I prefer relaxing with big cup of tea and good sandwiches with herring pate, but your mileage may vary here. It will take some time. Copying, I mean.
Step 4. Cross yourself and cross the mounts
mount /dev/hdb1 /usr
mount /dev/hda2 /foo
Your designations might be obviously different from mine, check them. Now you must have a copy of your former /usr in /usr/usr subdirectory. It's OK, it's easily mendable, and everything goes according to a plan.
Step 5. Lifting
Now simply move all the subdirectories in your /usr/usr to /usr, one by one, and you may delete /usr/usr when it's empty. Moving files and subdirectories within the scope of the same partition won't do any harm, that's for sure. You are almost done now!
Step 6. Restoration and renovation
Now we need to restore /etc/inittab to whatever run level you use. Mine was 5, so it should look like this:
Don't forget to readress your mounting instruction for /usr in /etc/fstab:
/dev/hdb1 /usr ext2 defaults 0 0
or something like this, just use whatever was assigned once to /usr on your old disk.
And if you choose to cross mounts (mount /dev/hda2 /foo, which is basically not needed, but can serve as a sort of backup, who knows?), edit the corresponding line for your /dev/hda2, or whatever you have, in the same manner.
Step 7. Reboot and enjoy!
Well, until now, it was easily reversible at every step. I mean you could roll back safely, if something went wrong. To an extent, it stays so now, too. But if all works well for couple of days (or better a week,) you may free up your old disk from its backup copy of /usr. Just delete it, no mahabharatas or bhagavadgitas about it. Once your ex-/usr is gone, there is one last optional job to consider: to merge the disk space freed up with your new /usr space (or any other filesystem you think of as critical for you.) There is a powerful utility to do this trick which is called Logical Volume Manager (LVM), and if you were smart enough to configure your kernel 2.4.x with 'Multi-device support (RAID and LVM)', plus 'Logical Volume Manager (LVM) support', even if you don't have anything resembling RAID on your system, then you can use the utility right now. Otherwise, find it at http://sistina.com/lvm/, and build it for your system. A detailed LVM HOWTO will teach you not only the right way of merging separate disk spaces, but could also suggest a drastic solution for a problem discussed here. Namely, after adding /dev/hdb disk to your system you should be able to add its space to your ailing /usr partition without moving a single bit in it.
Chapter 3. Conclusions
'O Chief, deal with us not according to our merits.
But deal with us according to our desires.
Let us bray.'
R.F. Laird, in 'The Boomer Bible'
Whether you have found this mini-HOWTO useful, or not, or you have other comments, corrections, amendments, etc., you're welcome to email the author aludal at softhome.net.
I am also doing some research on hdparms-HOWTO right now, and on some other hazardous tweaking, and I would appreciate any comments on these matters, too.
More information about the svlug