UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.

Bug #1939238 reported by geole0
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
e2fsprogs (Ubuntu)
New
Undecided
Unassigned

Bug Description

Hello
This problem did not occur on my computer.

https://nsa40.casimages.com/img/2021/08/07/210807015400327092.png

It occurs in users who are not competent.
This week, the French forum collapsed over this incident.

I think changing the advice phrase might improve understanding of the action to be taken.

Can these lines
" ( i.e.. without -a or -p options)
fsck existed with status code 4
The root file system on /dev/XXXXXXXX requires a manual fsck"
become
"execute this command 'fsck -y /dev/xxxxxx' to do a manual fsck on the root file system."

ProblemType: Bug
DistroRelease: Ubuntu 21.04
Package: gnome-terminal 3.38.1-1ubuntu1
ProcVersionSignature: Ubuntu 5.11.0-25.27-generic 5.11.22
Uname: Linux 5.11.0-25-generic x86_64
ApportVersion: 2.20.11-0ubuntu65.1
Architecture: amd64
CasperMD5CheckResult: unknown
CurrentDesktop: ubuntu:GNOME
Date: Sun Aug 8 15:16:28 2021
ExecutablePath: /usr/libexec/gnome-terminal-server
InstallationDate: Installed on 2020-08-02 (370 days ago)
InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423)
ProcEnviron:
 LANG=fr_FR.UTF-8
 PATH=(custom, user)
 SHELL=/bin/bash
 XDG_RUNTIME_DIR=<set>
SourcePackage: gnome-terminal
UpgradeStatus: Upgraded to hirsute on 2021-07-11 (27 days ago)

Revision history for this message
geole0 (geole0) wrote :
Revision history for this message
geole0 (geole0) wrote (last edit ):
Chris Guiver (guiverc)
affects: gnome-terminal (Ubuntu) → e2fsprogs (Ubuntu)
Revision history for this message
Theodore Ts'o (tytso) wrote :

fsck -y isn't *always* the right answer. The reason why the boot scripts don't just run fsck -y automatically is that sometimes a human with judgement can do better by manually running fsck instead of just blindly answering yes to all questions. For "users who are not competent" (your words, not mine), yes this may be beyond their capabilities. But there is a reason why some jobs, like for example, fixing airplane engines, requires people who are "competent", and certified to be so. If you have a full set of backups, then sure, you could try using fsck -y, and if that leads to unacceptable data loss, it's possible that you could recover more data by selective use of answering some fsck questions, and using debugfs. The problem is that "users who are not competent" are also not likely to be doing regular backups of their data. :-(

Revision history for this message
geole0 (geole0) wrote (last edit ):

Hello
Thanks for your answer but 99.999% of basic users are unable to answer repair software English questions other than "YES".

However the sentence can become
"EXECUTE THIS COMMAND 'fsck /dev/xxxxxx' to do a manual fsck on the root file system."

If the answer "yes" completely destroys the software, just reinstall it!

NOTE: A competent user does not store his personal data in the partition containing the software. He stores them elsewhere!

Revision history for this message
geole0 (geole0) wrote (last edit ):

Hello
"It asks me to do an fsk manually if I read between the lines, and I don't understand what that means or what to do." => https://forum.ubuntu-fr.org/viewtopic.php?pid=22480277#p22480277

"I am disarmed ... What should I do?" => https://forum.ubuntu-fr.org/viewtopic.php?pid=22480358#p22480358

Revision history for this message
Theodore Ts'o (tytso) wrote :

It doesn't matter whether you store your personal data on the partition where the OS is located, or elsewhere. Either way, you may need to know how to run e2fsck on the file system if you want to try to maximally recover data. If you don't know what you are doing, sure, go ahead and run fsck -y. But there is the chance you may lose data that you might have been able to recover if you had more skills.

Note that in the case that you referenced, the kernel had already detected some kind of file system inconsistency. That is the source of the "/dev/sda1 contains a file system with errors, checked force". This should not happen, unless there is some kind of hardware bug, or kernel bug which has led to the file system getting corrupted. This could be caused by flaky/low-quality/failing memory, or flaky/low-quality/failing HDD or SSD. An expert would have to look at the kernel logs for hints to see what might have gone wrong.

If the user has regularly been doing backups, then sure, maybe you don't care they can just run "fsck -y". But I don't want to give that advice, only to hear that some graduate student had ten years worth of thesis research, and it wasn't backed up, and they were using the lowest possible cost HDD or SSD that was not reliably storing their data. Sometimes, the best thing to do for low-comptency users, is for them to ask for help, maybe at a local Linux User's Group, so that an expert can try help them out. There is no magic incantation, no kind of "Hocus Pocus" magic set of instructions that will always do the right thing. And to give "low competency users" instructions which might not be the best thing is ultimately, IMHO, going to doing them a grave disservice.

P.S. One could argue that a graduate student who has ten years of research on cheap sh*t storage and who hasn't been doing their backups doesn't deserve to graduate with a Ph.D. But that's not a very charitable attitude....

Revision history for this message
geole0 (geole0) wrote (last edit ):

Hello
I still say that the action proposed by these lines

" dev/XXXXXXX: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY
( i.e.. without -a or -p options)
fsck existed with status code 4
The root file system on /dev/XXXXXXXX requires a manual fsck"

Is not easy to understand. So I suggested a change of presentation that could become this one:

"busybox allows you to manually repair the software partition if you hit 'fsck /dev/xxxxxx' to its command "(initramfs)". When the repair is complete, type the word 'exit' in order to continue the boot sequence."

Remember: He said "WHAT TO DO ?" https://forum.ubuntu-fr.org/viewtopic.php?id=2066117

Revision history for this message
geole0 (geole0) wrote :
Revision history for this message
Theodore Ts'o (tytso) wrote :

Your suggested message presupposes that busybox is used on a particular distribution. That's not necessarily the case. Remember, e2fsprogs is designed for all distributions, not just for Ubuntu. If Canonical wants to make a change like that to e2fsprogs, all distributions are free to make any changes they want to a package. (At which point they own any liability if the user is clueless enough that they need that amount of hand holding, but if that information is just enough to cause them to attempt to do a file system fixup, but they then lose files because they fumble the job, that's on Ubuntu, not on me.)

Or perhaps Canonical could put a multiple page, or even a book-length tutorial in its initramfs scripts that tries to teach all eventualities of what a user might need to fix when they run e2fsck by hand, if fsck exits with an error code indicating that the file system needs to be fixed by hand. Again, feel free to convince canonical to do something like that if it's really needed by novice users. Personally, I think it's roughly equivalent to trying to teach medicine to a novice as opposed to telling them to see a doctor, but hey, Ubuntu can try to break ground by trying to lead users by the hand. I do predict that after you tell users to "hit fsck /dev/xxxxxx", what will happen next is users will go to forum.ubuntu-fr.org and ask, how do I answer this question? I'm so confused.... Where does this end?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.