[svlug] Consider my mini-HOWTO

Al Udal aludal at SoftHome.net
Fri Mar 16 23:51:02 PST 2001


Attached is my humble contribution, more of a joke of a sort. Anyway, I would 
appreciate any views, corrections, etc., what may help me to do something 
more serious next time.

Thank you,

AU
-------------- next part --------------
Adding a new HDD -- mini-HOWTO

'Salvation of a drowning person
is in the hands of this very 
drowning person'
I. Ilf and E. Petrov

Abstract
Version 0.0.1-4, March 14 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. 

Disclaimer
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.

Introduction

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

Acknowledgments:

-- 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.

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:

cfdisk /dev/hdb

(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?)

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 of no help with those)

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)

mkdir /foo
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
neprotivlenii storon'
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 -) '

Certainly, it's a quick way, even one of the quickest, but is it safe? With all those recent comments on glitches in backup function of tar command, I can't recommend it. They say there is a bugfix, or patch for tar somewhere now, to mend its habitual loss of file attributes when archiving in certain conditions, but I'm suspicious still, as I'm sure this bugfix hardly addressed the exact manner of use in the command line above. Well, 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:

cd /usr
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.)

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:

id:1:initdefault

There are more elegant ways to kill other users and daemons in your system unawares, I admit, but this is the fastest, 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:

cd /usr
cp -a /usr /foo

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

umount /usr
umount /foo
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 so far.

Step 5. Lifting up

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:

id:5:initdefault

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 the mounts again (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. Strictly speaking, the procedure retains a reversibility even now. But if all works well, you may free up your old disk from its backup copy of /usr. Just delete it, no mahabharatas or bhagavadgitas about 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 mailing list