scsi hard disk removed
 

i have a linux system with 4 scsi hard-disks . I have removed scsi disk 2 .ie. sdb1.
Now the system boots and takes to me to shell and it says repair file system or press cntrl-D to continue.
Do i have to run fdisk and just rewrite the partition table.
Fdisk -l shows all my exsisiting partions intact with the ext3 partitions (but ofcourse except for the removed disk).

I assume this disk was just a data disk. Try removing the reference to sdb1 in the /etc/fstab file.

what i did was removed the disk entry from /etc/fstab and shutdown and removed the disk. And on reboot it tells to correct the filesystem.

So what was on this partition?

There was a single filesystem /mydata on this entire disk. I moved the data elsewhere and removed the disk.I want to start the sytem with only three disks and all data intact...

OK I solved the problem --my mistake i should have concentrated a bit more
"All I need to know I could have learned in Kindergarten
... if I'd just been paying attention."
I just edited the /etc/fstab and changed the sdc1 to sdb1 and sdd1 to sdc1
I should have paid attenton to the error message.
It was trying to fsck sdd1 which did not exist because the drive names had changed.
Thanks any way..

Ah...

That's been one of my biggest complaints about Linux handles disk devices: It's not much better than DOS disk drive letters. Add or remove a drive and everything "downstream" gets a new name. If you did this to the first SCSI bus, not only do the downstream devices get new names but the entire second (or third, etc.) bus is screwed up. Insane, IMHO. I had hoped, a few years ago, that the SCSI team might do well to adopt the SCSI naming convention used by, say, SYSV and some of the other commercial UNIxes and give devices names that specify the controller number, SCSI ID, partition numbers (ought to be familiar to anyone who's spent five minutes poking around on a Solaris box). I eas encouraged when I learned that the devfs filesystem was moving in that direction. It handled IDE devices in a similar fashion, IIRC. But now devfs is pretty much phased out. Using udev might be of some help but so far it looks to me to be a work in progress and a bit too complex to be really useful for this. (OK, end of rant :-) )

There is a method for making the OS less aware of changes to the SCSI devices names and it involves assigning a volume label to each partition. You then refer to that volume label in /etc/fstab. For example, instead of having in fstab, you could label the partition using and then the record on fstab would be changed to read The downside to using the labels is that you eventually forget just where things are physically located and if a device fails, you may not immediately be able to tell just what's been clobbered. Keep a comment in /etc/fstab noting what the label is on each physical partition to avoid confusion later.

In your case, the boot process would still have complained but you would have seen the volume name that it was having trouble with. Then you would have been able go into single user mode and edit /etc/fstab and comment out the line(s) corresponding to the removed device.

Here's a couple of interesting situations where volume labels are handy: 1.) The boot time filesystem check complains that /dev/sdb1 has problems. Checking it in single user show all sorts of errors. You panic because that's where half of the OS is supposed to be. What happend? The second disk didn't spin up (future failure looming) and fsck just tried to check a swap partition on /dev/sdc1. (I just had this happen about a week ago.) 2.) The check of all of the filesystems on the last SCSI disk fail. What happened? Well, the same thing as case one could have happened; it depends on the layout of the partitions. Or drive three could have been the culprit and drive four got seen as drive three. Whatever. The use of labels would have nailed exactly which drive was the problem. (Like I mentioned above, having a record of what's where is still important.)

Check labels out. They aren't just a gimimicky thing thrown into tune2fs just for the heck of it.