can't fsck after failing to boot

Hi all,

I am new here, I came across the forum while searching for a possible solution to a problem and I hope that posting this question does not violate any forum rules:

I have a virtual machine at work, the only linux VM in the office. I connect to it only via teamviewer. The VM was offline for 2 weeks and when I started it today I got these messages:

dev/sda3 contains a filesystem with errors check forced.
dev/sda3 inodes that were part of a corrupted orphan linked list found
unexpected inconsistency run fsck manually (without -a or -p options)

I booted from disk and entered the rescue. Logged in as root (no password needed) and I tried to:

fsck dev/sda3

but the only result I get is:

fsck from util-linux 2.23.2

and the same results I get even when I just fsck --help.

Does anyone have an idea of what could I do do recover the system?

Thanks a lot to everyone.

You choose OTHER VERSION from our foremost piece of information: which version of openSUSE are you using?

That the version you use is not in in the list only means that it is not one of those currently supported. It does NOT mean that nobody wants to help you. But it does mean that you must then tell us as the first information in your post what you use. Nobody here is clairvoyant ;).

And of course the file system type that should be there is also one of those things that help in helping.

Try putting a forward slash in front of your dev/sd3, currently your command works only if your command prompt location is in the root partition. Inserting the forward slash forces the command to operate based on the system root regardless where you command prompt happens to be eg

fsck /dev/sd3/

If you are unable to boot to emergency/recovery mode, and you need to execute from a recovery LiveCD, then you will have to further specify the location which will depend on how your LiveCD mounts your hard drive.


Thank you both for your replies. My version is opensuse 13.1. Honestly I never thought of updating to a newer version. I use this system in order to work on and compile my finite element code and you know this old quote from engineers, “never change a running system”.

I tried putting a slash in front of dev/sd3 and here is the result:

Rescue:/ #  fsck/dev/sda3/
fsck from util-linux 2.23.2
e2fsck 1.42.8 (20-Jun-2013)
fsck.ext2: No such file or directory while trying to open /dev/sd3
Possibly non-existent device?


I first fsck /dev/sda2 and then /dev/sda3 and it worked! Thanks a lot to both of you. You saved me form a lot of trouble. Do you think that is essential to upgrade to the newest version? I am mostly concerned with the compilers and compatibility of the libraries, I wouldn’t want to bother you again with questions about a non working makefile. Thanks!

Read for yourself. You say to check the file system on /dev/sda3 and the error says it can not find /dev/sd3.

Several possibilities here, but the most likely is that you did not copy/paste this, but copied it down by typing. When that is true, you should be very, very careful and check again and again if you type correctly. (and I think you typed, because I miss a blank space in your command, that could not have worked at all).

Thus we still do not know very much.

  • did you try to fsck /dev/sd3 and this is wrong of course;
  • did you try to fsck /dev/sda3 and was the error about /dev/sda3 and thus can we conclude you tried a non existing file system on a non-existing partition?

Maybe we should start from the begin. Please explain what you think is on /dev/sda3. Check if there IS a /dev/sda3

ls -l /dev/sda3

More info with (but when you have to copy this by typing, please don’t, it is to much, only tell if there is a list of several lines):

s -l /dev /dev/disk/by* | grep sda3

Problem solved, it worked, thanks again.

As for 13.1,
The last update was published awhile ago, so from now on it’s completely unsupported and vulnerable to threats.

I suppose if you pulled the network card so it would be impossible to connect to any network, you could continue to use your machine.

If you use your machine to build a very specific type of software, you <may> not be able to upgrade.
Because things break down eventually, you might consider looking into deploying a virtualized version of your existing system, while it’s running you can probably use a P2V tool to lessen the burden of a completely new build.