On Tue, Feb 22, 2011 at 01:40:51PM +0100, Lennart Poettering wrote:
the same time. That should give you a minimal idea on what is going
on. However no progress bar. In the syslog output the progress bar would
not make much sense probably. fsck (at least in the ext234
implementation) supports the -C parameter to direct progress bar
information (and only the progress bar) to a specific fd. However, that
information is intended for applications to parse it, not to show on the
screen. I am not really sure what to do about this. One option would be
to extend -C to show a "human readable" progress bar on the file name
passed. Then we could just invoke fsck with "-C /dev/console" and would
get a progress bar printed on the console, and the console only. But it
keeps me wondering how that would look like if multiple fs are handled
in parallel.
It would look pretty ugly. But having no output at all is very undesirable,
because it makes the system look hung, and particularly because (as in this
case) the most recently-printed messages may have nothing at all to do with
what is blocking the boot.
Another option would be to parse fsck's output and forward it in
some
form to Plymouth to show in the normal progress bar. But I am not sure
if Plymouth can actually do that. (Ray?) Also, this doesn't solve the
Also, it doesn't solve the problem in cases where one isn't running
plymouth, which I hope is a use case that systemd intends to take seriously.
I think not having the progress bar for F15 is acceptable, but I am
all
ears for suggestions how to implement this best post-F15. Especially if
somebody wants to do the work... ;-)
I don't think it's a blocker, but it should probably get put into the
release notes. Things like this cause end-user and support-center pain.
--
Matthew Miller <mattdm(a)mattdm.org>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences