Linux checking file systems failed

Linux Mint Forums

SOLVED File system check of the root filesystem failed

Forum rules
Before you post please read how to get help. Topics in this forum are automatically closed 6 months after creation.

SOLVED File system check of the root filesystem failed

Post by rdh61 » Fri Aug 06, 2021 4:30 am

Newly this morning when I try to boot into my Linux Mint 19.3 system, I get the following:

BusyBox v1.27.2 (Ubuntu 1:1.27.2ubuntu3.3) built-in shell (ash) Enter 'help' for a list of built-in commands. (initramfs)

Not having any idea what this is or what to do, I tried to boot into a previous kernel as I had recently upgraded. Same result.

I booted into recovery mode and got:

Failure: File system check of the root filesystem failed. The root filesystem on /dev/sda8 requires a manual fsck.

I do not know what ‘fsck’ is (I assume it is a file system repair utility) or how to use it.

I have read the solution provided in the link below, but it seems that there is risk involved, and that I should make sure that /dev/sda8 is unmounted first:
viewtopic.php?t=292634

Could someone please advise and take me through what I should do in simple bullet points? Many thanks.

Last edited by LockBot on Wed Dec 28, 2022 7:16 am, edited 2 times in total.
Reason: Topic automatically closed 6 months after creation. New replies are no longer allowed.

spamegg Level 10
Posts: 3281 Joined: Mon Oct 28, 2019 2:34 am Contact:

Re: File system check of the root filesystem failed

Post by spamegg » Fri Aug 06, 2021 7:53 am

You can run it with fsck /dev/sda8 . After it’s finished fixing all the file system errors, you can type exit at the BusyBox prompt, and it should continue the boot process normally. At that point in the boot process, your drive will not be mounted yet, so it’s OK. If you try to run fsck on a mounted drive, it will give you a big warning, something like (from the thread you linked):

mark@mark-VirtualBox ~ $ fsck fsck from util-linux 2.27.1 e2fsck 1.42.13 (17-May-2015) /dev/sda1 is mounted. WARNING. The filesystem is mounted. If you continue you ***WILL*** cause ***SEVERE*** filesystem damage. Do you really want to continue? no check aborted. 

If this keeps happening over and over again in the next weeks, you can automate the process by adding kernel parameters to GRUB. Run xed admin:///etc/default/grub and change the line GRUB_CMDLINE_LINUX_DEFAULT=»quiet splash» to GRUB_CMDLINE_LINUX_DEFAULT=»quiet splash fsck.mode=force fsck.repair=yes» save file, exit, then run sudo update-grub .

ricardogroetaers Level 6
Posts: 1334 Joined: Sat Oct 27, 2018 3:06 am Location: Rio de Janeiro, Brasil

Re: File system check of the root filesystem failed

Post by ricardogroetaers » Fri Aug 06, 2021 11:18 pm

. The root filesystem on /dev/sda8 requires a manual fsck.

The safest way to make repair on the defective volume is «run» the fsck by the installation media.
As I can not affirm that the problematic volume is always represented by «sda8», I ask (using the installation media) the output of the command:
lsblk -f

Re: File system check of the root filesystem failed

Post by rdh61 » Sat Aug 07, 2021 11:59 am

At BusyBox the above command did not work by itself. I hit ‘help’ to see a list of available commands and of them I guessed that I had to put ‘exec’ before the above command. That worked.

spamegg wrote: ⤴ Fri Aug 06, 2021 7:53 am If this keeps happening over and over again in the next weeks, you can automate the process by adding kernel parameters to GRUB.

However, that would mean there were an unresolved and possibly serious problem, wouldn’t it? Why would it keep happening?

Re: File system check of the root filesystem failed

Post by rdh61 » Sat Aug 07, 2021 12:00 pm

ricardogroetaers wrote: ⤴ Fri Aug 06, 2021 11:18 pm The safest way to make repair on the defective volume is «run» the fsck by the installation media.
As I can not affirm that the problematic volume is always represented by «sda8», I ask (using the installation media) the output of the command:
lsblk -f

Re: File system check of the root filesystem failed

Post by rdh61 » Sat Aug 07, 2021 12:07 pm

For the sake of curiosity.

«Why do things break?» may sound, on the face of it, like a silly question, but one can think of a list of reasons why, in general, mechanical things can break; off the top of my head: wear and tear, degradation of materials (e.g. oxidation), stress fracture, improper use, design faults, programmed end-of-life.

Why does a computer file system break?

SMG Level 24
Posts: 24712 Joined: Sun Jul 26, 2020 6:15 pm Location: USA

Re: File system check of the root filesystem failed

Post by SMG » Sat Aug 07, 2021 12:59 pm

One common reason for this to happen (if it happens repeatedly) is the hard drive is going bad and thus the operating system is not able to find the files it needs to run because of corruption in that area of the drive.

A woman typing on a laptop with LM20.3 Cinnamon.

ricardogroetaers Level 6
Posts: 1334 Joined: Sat Oct 27, 2018 3:06 am Location: Rio de Janeiro, Brasil

Re: File system check of the root filesystem failed

Post by ricardogroetaers » Sat Aug 07, 2021 3:29 pm

At BusyBox the above command did not work by itself. I hit ‘help’ to see a list of available commands and of them I guessed that I had to put ‘exec’ before the above command. That worked.

spamegg Level 10
Posts: 3281 Joined: Mon Oct 28, 2019 2:34 am Contact:

Re: SOLVED File system check of the root filesystem failed

Post by spamegg » Mon Aug 09, 2021 6:11 am

However, that would mean there were an unresolved and possibly serious problem, wouldn’t it? Why would it keep happening?

It’s happening to a lot of people, I don’t think everybody’s hard drives decided to fail all of a sudden, and it’s happening on new, or proven-good drives too. My guess is there is some sort of bug in the kernel’s file system code.

paxdriver Level 1
Posts: 10 Joined: Tue Jan 26, 2021 10:25 am Location: Canada Contact:

Re: *NOT* SOLVED File system check of the root filesystem failed

Post by paxdriver » Sat Aug 28, 2021 4:51 am

imho this is certainly a LM problem. I think I’ve figured out where the problem is but can’t figure out why nor how to fix it.

When transferring large files using nemo, like vm’s or folders, the OS seems to lose connection with the hard drive which corrupts or loses the magic block number. It happens so regularly I began booting to another distro (studio) or run copy/move commands through the terminal instead. The terminal is more stable and almost always works fine.

I thought it was a hard drive issue; then I thought it was maybe the fuse/dual-booting causing the trouble, or maybe device power controllers going to sleep while in use or something so I disabled power management of devices in OS and BIOS settings; then I thought it was the cheap PCIe sata controller I was using to expand sata ports on my system, then I thought it was chipset issues with cheap mobo, then I thought it was just me being a noob to Linux. — but after 3 years now I’m reasonably sure it’s not my fault lol. I just installed a brand new SSD, motherboard, CPU in the last 2 months. I’ve got Win10, Mint, Studio and Budgie multi-booting on my system (so no LVM). Using ext4 on system and storage, fuse for drives sharing access to win10. Partition file table was msdos default before, this time with my new ssd I created GPT partition table, thinking maybe that would fix the problem. None of my guesses seemed to lead to any solutions though, and I still don’t know exactly what’s going wrong and why it’s only occurring with large file transfers, regardless of the file system type (either ext4 or ntfs fusion).

Trying to transfer large files through nemo produces a freeze mid transfer as it did before, especially when moving files rather than copying (another of my hack workarounds over the past few years was copy first, then delete instead of straight ‘move’). After that I start getting i/o errors and random read-only errors, after which the drive becomes invisible in the left pane of window manager (where it normally shows the label even if not mounted or included in fstab). After one file transfer error, the disk starts acting like it’s failing sporadically forever after, as if it’s a file system corruption problem only triggered when certain sectors of the disk were used. Yesterday, with my new ssd installed and with the old hdd completely removed from my system (believing it was maybe failing), I got the issue again while moving virtual machine images; but this time it manifest as permissions issues then the «invalid superblock magic number» error and lose access to the drive again until reboot.

Curiously, gparted also fails to read at this point, but gparted sees no issue when running from a reboot. until you try checking the disk with fsck or disk utility’s ‘check file system’, I get error «Error repairing filesystem on /dev/sde1: process reported exit code 1: e2fsck 1.44.1 (24-Mar-2018) (udisks-error-quark, 0). Checking the file system with disk utility returns «Filesystem intact: Filesystem on KINGSTON is undamaged».

I can’t seem to find the solution to this problem anywhere but I do hear people getting hard drive filesystem-like corruption issues but the specific errors are not always consistent, nor the triggers to the bug.

Источник

Arch Linux

Hi,
I have been getting a filesystem check error since yesterday now and am unable to start Arch. Upon googling and searching the arch fora, I came upon some advice which I tried which has not worked yet. Hence the new post.

Basically, I was attempting to print something off and accidentally chose a printer that was not connected to my laptop. After half a minute or so, it repeatedly started giving me notifications that the printer was not connected. in excess of 200 messages that the printer was not working which continued to pop up despite me canceling the print job. The whole system got really sluggish (for the first time in the last year) and I had to restart the laptop upon which the boot messages appear.
It gets to the point where its loading the various filesystems. It mounts root and says it fine. Then it says

/dv/sda3: clean, 171642/915712 files, 1837167/3662820 blocks /dev/sda2 is mounted. /dev/sda5 is mounted. Filesystem check failed. Please repair manually and reboot. Note that the root file system is currently mounted readonly. To remount it read-write type: mount -n -o remount ,rw / When you exit the maintenance shell the system will reboot automatically.

In my system,
/dev/sda3 is root
/dev/sda2 is boot
/dev/sda5 is home

I tried fsck which tells me that home and boot are still mounted.
So I booted up using an Ubuntu Live CD and checked and repaired each file system which it successfully did. Upon rebooting into Arch, I am getting the same message.
I have not installed anything new and had upgraded the whole system a few days before the problem started.
Not sure where to go from here.
Any help, please
Thanks

Last edited by samsom (2010-01-24 22:42:41)

Источник