> I would say that you might want to have -P work with parallelisation
> such that it only uses one meter.

Actually, what I would imagine (for what little it may be worth) for a
parallel fsck progress meter would be something like

|****.................................|**********************................|

or

|*************............|**********************...|***.....................|

where of course there are as many sections as there are fscks in
progress at the moment, with it dropping from (say) three sections to
two, resizing the two meters remaining, when one spindle of three
finishes.

Of course, doing that requires designing, defining, and implementing a
way for the sub-fscks to report progress percentages to common meter
code, or else running the sub-fscks on ptys, with the common frontend
watching the progress meters and scaling them down (which amounts to
the same thing, with the defined interface being the progress meters
themselves).

Of course, since I'm not implementing it, my thoughts are limited to at
most suggestions to others.

Now if only we could count on (a) having a display terminal and (b)
having $TERM set correctly, we could do multiple progress bars on
different lines.  But those are a pretty tall order for boot time.

> Hmm, what if one wants the progress meter but not the getpw* and err*
> stuff?

What if one wants pass 3 but not the other passes?

There will always be things one might want that would require hacking
on the source to get.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B