Update 01 - i couldn't fint /etc/fstab and couldn't find /boot/grub/menu.lst i mount my filesystem partition again coz it wasn't mounted and when i do
i found /tmp/loop0 mounted on /mmnt/runtime and inodes free is zero it's 100% full i really don't know what is that i go inside it and i found etc , lib , modules , proc , usr , var never mind
when i go to my file system i found lib , pin ,var are not a directory i do e2fsck -fpv /dev/sda5 <--- which is my file system is here and it's done when i reboot nothing change same error appear :( what did u suggest me to do ?
We need a little more information.
Is this happening when you logout, login, try and mount a volume?
Can you give precise info on what you are doing, or trying to do for that matter.
However to give a push in the right direction: It looks like filesystem corruption, did you recently have an outage, or have a hard shutdown?
Also what filesystem is this? ext3, ext2?
Essentially your filesystem is corrupt in some parts. It can't find what to mount. When you boot in with the boot disk, can you see /etc/fstab and /boot/grub/menu.lst?
When you boot, it's missing a number of files it needs such as /var which you stated looks like a file instead of a directory.
The next step would be to boot in with a boot disk, and run fsck on the unmounted
The above command will auto-repair the filesystem, and will force it to run even if the filesystem appears clean. The -v flag tells it to be verbose, log all the output in case you need to refer back to it.
If it comes across an error that requires further intervention it will print it to the screen.
Do the above and then come back and let us know whether it worked. We'll go from there.
Maybe I was unclear, when you boot with the rescue cd it normally mounts the filesystem to /mnt/sysimage
You then have the option of chrooting to /mnt/sysimage which would make it so your filesystem is at / effectively.
Assuming you are NOT chrooting to /mnt/sysimage your files would be located at /mnt/sysimage/etc/fstab and /mnt/sysimage/boot/grub/menu.lst
Check for those files in those locations. Also check and see if /mnt/sysimage/var is a directory as well.
You can try running fsck again as well, but after 3-4 times of running you may have to accept the filesystem is isn't able to be repaired by fsck.
Are they present? if not and you have tried fsck'ing the filesystem you may be out of luck. If your filesystem is corrupted the next step after this would be to salvage your user data and go from there.
This would probably be the easiest explanation without typing it all out. Just FYI. www.google.com/linux is a good way to research.
answered 11 Jul '10, 16:17
WOW!! There are some good answers here, all of which I'd recommend, so I'll just add my little 2 cents here.... check /var/log and also dmesg... the first step of any troubleshooting is data-gathering, followed by the next step of sorting, filtering, and disseminating said gathered information so you can now make a proper assessment and then either proceed to gather more/different data, or fix the issue directly based on information gathered.
answered 13 Apr '11, 13:57