UbuntuWiki:UsplashFsckProgress

来自Ubuntu中文
跳到导航跳到搜索

{{#ifexist: :UbuntuWiki:UsplashFsckProgress/zh | | {{#ifexist: UbuntuWiki:UsplashFsckProgress/zh | | {{#ifeq: {{#titleparts:UbuntuWiki:UsplashFsckProgress|1|-1|}} | zh | | }} }} }} {{#ifeq: {{#titleparts:UbuntuWiki:UsplashFsckProgress|1|-1|}} | zh | | }}


Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.

Summary

This specification outlines the method for displaying the results of a necessary fsck using usplash, without needing to switch to text mode, and only if one is required.

Rationale

A filesystem check, when required, is a lengthy process that occurs during boot time. This adds a significant enough delay that users may believe there is some kind of problem, and reboot their machine or worse.

Use cases

Scope

Design

Implementation

Code

Data preservation and migration

Unresolved issues

What sort of progress bar are you looking for? Currently what is implemented in the fsck driver permits you to know how far you have gotten in checking one filesystem, and once it completes, it will switch to another filesystem and tell you how far that one needs to go before it is complete. We don't currently have an overall progress bar indicator (and in order to do that it would require modification of both fsck and the low-level, underlying fsck programs --- and I don't think it would be trivial). The question is how desirable is that? -- tytso, 2006-Dec-21

BoF agenda and discussion

  • Presumably some changes would need to be done to usplash for something like this to fit, so I have some thoughts for a tidy direction to aim those changes. What if, instead of showing no information at all besides the progress bar when booting up, the uSplash had one or two lines for Messages? That way, if something goes wrong during startup a message would be displayed there. Also, (more importantly!) the output for fsck could be displayed in that message box. Such a change would silence a lot of the people who want verbose startup and it would make it obvious when something goes wrong / must happen that is extraordinary, while at the same time keeping with the clean, friendly startup that Ubuntu is used to. I also think that would be a good way to go because of how the startup procedure already changes screens way too many times for my liking. On a slower computer it is less noticeable, but there is the usplash, a black screen (and maybe even some text!) followed by the background colour for the login screen, then there is finally the login screen. Looks kind of ugly and gives an effect that Ubuntu is an ugly hack. With fsck doing that every 20th startup it can be even worse, and then even if fsck is not texty it would still be an obvious change from one thing to another. Therefore, integrating the two is very useful from an aesthetic point of view. --- DylanMcCall (Mr. Picklesworth), 2007-Feb-09
  • Probably only marginally connected to this but currently user input during bootup is not integrated into usplash at all. This is needed for encrypted partitions, for example. https://launchpad.net/products/upstart/+bug/62751 is related to that problem.
  • Why users need to fsck their fs every 30 mounts (or so) at all? If that is needed, it means the journaling code is broken - diegocg
      • I, for one, find it a nice feature to have. The first time I bumped into that, Aptitude had apparently checked on the results and learned that one of my packages was placed in an area containing a consistency error. It offered to reinstall it and everything was peachy. It is certainly a useful thing! (Although a way to skip it would be nice).
  • Ext2/3 forces a check every 30 (+/-) mounts (it's also possible to base it on number of days, such as after 180 days) because of paranoia due to hardware/memory failures, and a desire to find out about filesystem corruptions before the corruption causes severe data loss. Keep in mind that most users don't have ECC memory, and traditional parallel scsi has but a single parity check, and old-style IDE interfaces did not checksums or parity checking whatsoever (mercifully, UDMA added a CRC checksum). Kernel bugs (particularly in the suspend/resume code, historically) or bugs in propietary binary-only video drivers have caused random memory locations to be corrupted, which have also in some cases lead to some extremely spectacular filesystem corruption. Remember Ted's Rule of Cheap PC Hardware: "All PC-class hardware is cr*p." The only question is that some PC class hardware is worse than others.... --- tytso, 2006-Dec-21
  • Another thing to consider --- currently e2fsck can print an informative message indicating that the filesystem check has been skipped because the laptop is running on battery, or that a filesystem check will be due after n mounts (where n < 5). Should this information be also displayed via the Usplash interface? If so we will need to consider how to get this information communicated from e2fsck to usplash. -- tytso, 2006-Dec-21