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.