[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: fsck fails (then succeeds)

On Sat, 14 Jun 2003 14:09:57 -0400
Bryan Kadzban <bryan kdzbn homelinux net> wrote:


Hello Brian,

Thanks for responding.

> Depending on which LFS version you're using (which version
> is this, anyway?), these messages ("errors have been found
> that cannot be fixed", and then "waiting for manual
> intervention") were probably both printed by the init
> script that runs fsck.

I have LFS 3.3 (almost a year old now), but it has been
continually upgraded and extended - often by reference to
the current cvs LFS book. Apart from a few extensions, the
init scripts are, however, the originals.


> If it
> returns anything between 4 and 15, inclusive, then the
> script prints the big red "I failed, halting system"
> message.  This corresponds to the description of the
> return value of e2fsck in its manpage (and probably other
> fsck's).
> Ted is right, though -- fsck should have displayed its own
> errors before it returned 1.  When the script runs fsck
> after a shutdown -r -F, it runs it with the -f -a -A -C -T
> options, so it's not like it's suppressing the errors.

It was definitely this part of of checkfs that I saw, so it
was an error higher than 2.

if [ "$error_value" -gt 2 ]
	echo "File system errors were encountered that couldn't be"
	echo "fixed automatically. This system cannot continue to
boot"	echo "and will therefore be halted until those errors
fixed manually"	echo "by a System Administrator."
	echo -n "When you press enter, this system will be halted."
	print_status failure
	echo "Press enter to continue..."

I am as sure as I can be that there was no fsck output
printed before I saw that. The check was past 90% and (I
think), past 95%- the point at which (on my system at
least), it is only a couple seconds from completion, and I
was staring at the screen.

In case, you, or Ted is interested, I extracted the relevant
parts of the kern.log, and I am attaching them with


> In the future, too, you can pass "init=/bin/bash" to the
> kernel at boot time using your bootloader (lilo is still
> the LFS loader, right?), and that way you can run fsck -f
> yourself, interactively, to see (and fix) what all it
> thinks is wrong with the filesystem.

Yes, still lilo.  I will bear that in mind.



Attachment: kern_log.txt
Description: Binary data

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]