On Sat, Feb 04, 2012 at 05:14:35PM -0600, Bruce Dubbs wrote:
> Bruce Dubbs wrote:
> > Ken Moffat wrote:
> >
> >> Experimentation shows that the checkfs script now writes to
> >> /dev/null during fsck (line 82):
> >> fsck ${options} -a -A -C -T >/dev/null
> >
> > Yes, I did that in November. I can't recall the details why I did that.
> > I think it had to do with the formatting of the boot script output,
> > especially when no detailed check is indicated.
> >
> > I'll take another look at it.
>
> For me, I get things like the following for each partition.
>
> e2fsck 1.41.14 (22-Dec-2010)
> /dev/sdb1: clean, 13/1310720 files, 2629636/5242880 blocks
>
> or
>
> e2fsck 1.41.14 (22-Dec-2010)
> Pass 1: Checking inodes, blocks, and sizes
> Pass 2: Checking directory structure
> Pass 3: Checking directory connectivity
> Pass 4: Checking reference counts
> Pass 5: Checking group summary information
> /dev/sdb1: 13/1310720 files (0.0% non-contiguous), 2629636/5242880 blocks
>
> in the boot screen. There are different printouts for other
> filesystems. I think what we really want to know is if there will be
> some time consuming operation and, if appropriate, that operation's
> progress, otherwise, clean can be assumed. I really don't want to see
> the e2fsck program's header either. The header would be different for
> each fs type.
>
> I suppose the easiest would be to remove the >/dev/null, but would
> prefer a better solution.
>
> A flag in the rc.site file could selectively add/not use the redirection
> to the fsck command, but that doesn't seem very elegant.
>
> We could possibly use something like:
>
> fsck ${options} -a -A -C -T | egrep -v "fsck|clean"
>
> But that interferes with the -C progress output. About the only other
> thing I can think of is to parse fstab and run the fsck for each
> partition one or two times, once with a -n option to see if fixes are
> needed and a second with full output if they are needed.
>
> I'm open to suggestions.
>
> -- Bruce
I'm thinking, but I don't really see why you wanted to get rid of
the e2fs header. I suppose I've been used to seeing it ever since I
started using linux, so it's an old friend.
Certainly, a flag looks inelegant, but parsing /etc/fstab so we can
do a dry-run sounds too much like reinventing the wheel.
The only thing that bothers me in a normal boot are the kernel
messages where it tries to mount ext4 as ext2, fails for unsupported
features, repeats as ext3, and then uses ext4. But those are kernel
messages, so I accept them. If in doubt, I prefer more information
than less when booting and shutting down - 99% of the time I can
ignore it, the other 1% it might tell me what is wrong.
ĸen
--
das eine Mal als Tragödie, das andere Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
