By the prompt "(Repair filesystem) 2 #" I think your system has stopped early in the boot sequence. It would be important to read the messages that appeared before the first prompt to see _which_ filesystem needs fixing. It looks like you chose the wrong one.
If you have a problem with the root filesystem, you cannot unmount it: unmounting the root filesystem would make it impossible to access any commands.
Instead, the correct procedure for fsck'ing the root filesystem is to re-mount it read-only before running a fsck on it:
mount -o remount,ro /
When the system has crashed and stops early in the boot sequence because of filesystem errors, the /etc/mtab file may be "stale" (= describing the situation before the crash, not the current situation). That may confuse the "mount" command... and the unwary sysadmin, too.
/proc/mounts is another list of currently-mounted filesystems. Because it is managed by the kernel in the virtual /proc filesystem, it is always up to date.
If the system stops early in the boot sequence, it is possible that /proc is not mounted yet: fortunately, this is simple to fix.
mount /proc
Because /proc is a virtual filesystem, it does not need fsck'ing and is always safe to mount.
In your case, the system apparently had already successfully checked the root filesystem and mounted it read/write, as part of the normal boot sequence.
After that, the system checks any other configured filesystems... but apparently your system encountered a filesystem error that it cannot fix without asking an explicit permission from the sysadmin (because the fix may require truncating a file or something).
Then the system dropped to a shell prompt, and you told it to run fsck on the root filesystem that already was checked and mounted read/write.
MK
