In a manner of speaking, all file system inconsistencies are unexpected. No one actually wants to go out and find that their file structure is damaged in some way. However, the term “unexpected inconsistency” will sometimes actually show up as a specific type of error message. Since this error message comes from the base GNU and Linux tools, you can unfortunately expect most distributions to handle it the same way. This is probably true even if they’re older ones.
You may also theoretically experience unexpected inconsistencies in a somewhat similar fashion on FreeBSD, NetBSD and other Unix-like operating systems. More than likely, you’d only receive these messages on boot. Linux, by default, preens your / file system of any irregularities when it starts up, but this means that it wasn’t able to for some reason. Crossing your fingers and issuing a simple fsck command might be all it takes to bring your file structure right back into alignment again.
Using fsck to Repair Unexpected Inconsistencies
Upon booting your machine, you might receive an error that reads something like “/dev/sda1 contains a file system with errors, check forced” or “/dev/sda1: Inodes that were part of a corrupted orphan linked list found.” The error is usually followed with a big warning message that reads something like “/dev/sda1: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY,” though the exact device file and partition number in question may be different depending on how you installed Linux to begin with.
Since e2fsck or whatever version of fsck your system runs on system startup runs with the -p or -a option to simply preen the inodes and look for orphans, the error message will remind you not to do that. Users running Ubuntu might be dropped into a busybox shell while others might just find that their system is completely hung. It’s waiting for them to restart it. You can run a file system consistency check from the (initramfs) _ prompt if you’re given one. Simply type fsck /dev/sda1 or whatever partition you might have seen in the previous error message. Don’t add the -a option to the command even if you’ve gotten into the habit of doing this before.
You need to run things interactively for the time being. While you could add -c to check for bad blocks if you fear some of this is caused by a hardware error, this can slow things down quite a bit and cause it to hang, so you may wish to hold off for the time being. You could also add the -f switch to force fsck to run if it doesn’t want to, which is perhaps a better idea in this case. Usually the unexpected inconsistency error itself will force checking, but sometimes some sort of irregularity will prevent it from doing so. While the shell you were previously operating at might have attempted to get you to type help to see further options, you don’t really need to. You may want to run fsck -f / as well as fsck -f /dev/sda1, however, just in case the damaged partition and the boot partition are different. You’ll need to replace the name and number with the actual partition device file once again.
You should have root access from this prompt in a majority of cases, but for security reasons you might not. Use sudo in front of any fsck command you’re trying to run if you can’t seem to get something working. Enter your administrative password if asked for it.
Should you be unable to view the comparatively primitive busybox ash shell in this manner, you could boot to the GRUB menu that allows you to select which operating system you wanted to start. You can generally do this by pushing the Esc key while starting. Once you’re in the GRUB menu, choose Advanced Options and then select Recovery Mode from the menu. You’ll be given a choice of access patterns, and you should select Root access when given the choice.
You’ll receive a very simple # prompt. While it’s still quite serviceable, this prompt will seem quite primitive if you’re used to working with the bash or even the tcsh shells inside Linux. Type fsck -f / and follow the prompts after you push the enter key, and then type fsck -f /dev/sda1 or whatever other device file needs checking afterwards. You may need to run fsck more than once, just like in the previous example. Since this is a busybox shell rather than something more sophisticated, you’ll be locked out of some bash niceties like the ability to move up and down through your command list with the arrow keys. Simply retype the fsck commands if you need to run them more than once. This is technically a variation of the Almquist shell, which DASH is based on, so you may have some experience working with it from within Ubuntu.
Users booting their systems from something other than an ext# file system will of course need to substitute their preferred command. In most cases, fsck can call fsck.f2fs without a problem, but since fsck.xfs doesn’t do anything, you’ll need to run xfs_repair or xfs_check without the -f switch. This is actually a different option when it comes to these commands, and you should always avoid doing this.
As soon as you have a bootable system again, you’ll want to look in the /lost+found directory. You’ll probably need root access to do so. All of the various fsck commands use this directory to shove damaged and orphaned files after it finds them, in the same manner that chkdsk creates .CHK files when repairing damaged NTFS volumes. You may find lost files in here that represent personal documents you’d like to restore. Depending on which version of fsck you ran, what these files are named could be different. Use the file command to figure out what they actually are.
The post How to Fix Unexpected Inconsistencies on Linux Partitions appeared first on Appuals.com.