When i boot i get an error and it prompts me with:
/dev/sda1: recovering journal
Error reading block 59821724 (input/output error)
/dev/sda1: UNEXPECTED INCONSYSTENCY; RUN fsck MANNUALY.
(I.e., without -a or -p options)
I tried typing fsck /dev/sda1, but nothing happend.
I tried that.It asked me to ignore the error and to rewrite the block, but after I confirmed nothing happend. I waited for 30 mins and nothing. I tried to boot again and the same error.
Please, boot live ISO and run
inxi -Fza
and post output here.
System: Kernel: 5.15.2-2-MANJARO x86_64 bits: 64 compiler: gcc v:11.1.0 parameters: BOOT_IMAGE=/boot/vmlinuz-x86_64 lang=en_US keytabla=US tz=UTZ misobasedir=manjaro misolabel=MANJARO_KDE212PRE1 quiet systemd.show_status=1 apparmor=1 security=apparmor driver=nonfree nouveau.modeset=0 i915.modeset=1 radeon.modeset=1
Machine: Type: Laptop System: Hewlett-Packard Product: HP Probook 6560b v: A0001D02 serial: Chassis: type: 10 serial:
Mobo: Hewlett-Packard model: 1619 v: KBC Version 97.4A serial: BIOS: Hewlett-Packard v: 68SCE Ver. F. 22 date: 12/22/2011
Illegal division by zero at /usr/bin/inxi line 7275:
That is not current inxi 3.3.09.
Line 7275:
}
That’s the entire line, if it’s not clear. No division happening there.
Make sure you are using current inxi before saying a bug exists.
inxi --version
inxi 3.3.09-00 (2021-11-22)
No. On the live iso it seems to be 3.3.07, so the line would be this one, which translates to 7318 for 3.3.09.
The check seems to be insufficient: a string "0.0" would get through that if-condition and main::is_numeric test and ultimately trigger the devision by zero.
It has to be confirmed as still active on 3.3.09, I don’t do theoretical bug handling. I faintly remember a divide by zero bug and it was fixed, but I don’t know what line it was on, that’s why I don’t accept bug reports ever for non current inxi versions, it’s impossible to know if issues were fixed or not. I certainly don’t keep legacy versions around to check line numbers etc, nor do I try to remember what each change did. Impossible to do that. I do believe I faintly remember the 0.0 situation tripping a divide by zero error, and that was fixed, but again, I don’t try to remember this. The release notes do indicate quite thoroughly what was fixed, but not line numbers etc.
This is why I never accept bug reports for legacy inxi versions, legacy meaning anything that is not current master branch, unless it’s super obvious and kind of no dugh type mistake, which are easy to spot from output data being clearly missing with error above the missing output.
For real bugs, in general, it has to be verified as still present on pinxi, since that can have many bug fixes in it compared to master branch inxi, but in many cases, I can check the logic between master inxi and development pinxi to see if the issue was corrected, or I can check the changelog.
Another note is quite important, there’s a tendency for users to post error output but to fail to post the output FOLLOWING THE ERROR! inxi output is generated of course AFTER the data is generated, not before, so I can quite often figure out where the error happened by there being a missing value in a field in the following lines of data, which can be quite a ways after the error in some cases since sometimes inxi internally gets and saves some data quite a while before it’s going to be output and used.
So never post incomplete inxi output if you see an error, always post the entire inxi output, start to finish, since basically if you guess where the error actually refers to, you’ll almost always guess wrong.
I have probably fixed approaching 100 bugs by now by just seeing user output online with error / line Perl messages without them even realizing they were posting an error in the first place. The missing value in a key:value pair following that error often have let me figure out the error source (almost always undefined data) and fix it without anyone ever filing a bug on it at all.
Output processing and data generation are totally separate in inxi, and data generation often happens long before output processing in some cases. The only category of errors that happens during output is when the output printer gets an undefined or null value where it was expecting a defined value, those always show by an empty value in a key:value pair following the error.