fsck progress stalls at boot, plymouthd/mountall eats CPU
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Linux Mint |
Fix Released
|
High
|
Clement Lefebvre | ||
mountall (Ubuntu) |
Fix Released
|
High
|
Unassigned | ||
Lucid |
Fix Released
|
High
|
Unassigned | ||
plymouth (Ubuntu) |
Invalid
|
Undecided
|
Unassigned | ||
Lucid |
Invalid
|
Undecided
|
Unassigned |
Bug Description
PROBLEM
When a disk check is performed, the progress stalls somewhere around 70% and will then take a very long time finishing the remaining percent (10 minutes or more).
PATCH
Patch for mountall has now been pushed as an update for Lucid, if you are still seeing this problem, make sure you have mountall 2.15 installed before commenting/
[Earlier patch comments:]
Tero Mononen has published a patch for Bug #553745 which applies to the issue described here as well (see https:/
I have created corresponding packages which are available through my PPA: https:/
!!!Do note that this is an unofficial, untested, preliminary patch!!!
However testing and feedback is welcome, please especially report if there are ANY (new) problems seen when using the patched version.
TEST CASE:
(sudo aptitude install bootchart)
sudo touch /forcefsck && sudo reboot
POSSIBLE TEMPORARY WORKAROUNDS
1. Removing "quiet" and "splash" from the kernel boot line
2. When the progress has stalled, switch away from the splash screen using the left arrowkey (presumably any arrowkey works).
* Both these approaches speeds up the boot process to ~1 minute instead.
OBSERVATIONS
The fsck message "(...) non-contiguous (...)" Which I assume indicates the end of the fsck, is printed in the Virtual Terminal ("outside" plymouth) at around 70% + ~10-20 seconds.
Disk activity is null from this point on (presumed end of fsck above).
Bootchart crashes if trying to catch the whole boot at once with plymouth (at least for my 1h boot).
This problem seems to occur in both plymouthd and mountall, semi-simultaneo
If you are in the plymouth screen, plymouthd is the cpu-gobbler, if you switch away from it using the arrow keys, mountall instead takes over the cpu-eating.
#####
ORIGINAL REPORT
Binary package hint: mountall
On my system when fsck runs at boot plymouth % completion count goes up quickly (<10 seconds) up to about 80% and then slows down considerably: the complete fsck of my 125GB HD, 30% full takes more than 5 minutes.
While this goes on the text VTs are all completely blank: just a blinking cursor.
An fsck from a recovery disk completes in ~10 seconds so it doesn't look like "fsck just being slow".
This slowdown was *not* happening on 2010-04-14 with the PPA described by this comment: https:/
The fix in the PPA is now in the mainline lucid but somewhere in between then and today (2010-04-29) something introduced this slowdown.
ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: mountall 2.14
ProcVersionSign
Uname: Linux 2.6.32-21-generic i686
NonfreeKernelMo
Architecture: i386
Date: Thu Apr 29 15:38:56 2010
InstallationMedia: Ubuntu 10.04 "Lucid Lynx" - Beta i386 (20100317.1)
ProcEnviron:
LANGUAGE=
PATH=(custom, user)
LANG=en_IE.utf8
SHELL=/bin/bash
SourcePackage: mountall
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
summary: |
- fsck at bootstrap is too slow + fsck progress stalls at boot, plymouthd/mountall eats CPU |
description: | updated |
tags: | added: patch |
tags: | removed: apport-bug i386 |
description: | updated |
description: | updated |
Changed in plymouth (Ubuntu): | |
status: | New → Confirmed |
Changed in mountall (Ubuntu Lucid): | |
status: | New → Triaged |
Changed in mountall (Ubuntu): | |
status: | Confirmed → Triaged |
Changed in plymouth (Ubuntu Lucid): | |
status: | New → Triaged |
Changed in plymouth (Ubuntu): | |
status: | Confirmed → Triaged |
Changed in mountall (Ubuntu Lucid): | |
status: | Triaged → In Progress |
importance: | Undecided → High |
Changed in mountall (Ubuntu Lucid): | |
status: | In Progress → Fix Committed |
tags: | added: verification-needed |
description: | updated |
tags: |
added: verification-done removed: verification-needed |
Changed in mountall (Ubuntu Lucid): | |
status: | Fix Committed → Fix Released |
Changed in mountall (Ubuntu): | |
status: | Triaged → Fix Committed |
status: | Fix Committed → Fix Released |
Changed in mountall (Ubuntu Lucid): | |
status: | Fix Released → Fix Committed |
Changed in mountall (Ubuntu Lucid): | |
status: | Fix Committed → Fix Released |
status: | Fix Released → Fix Committed |
Changed in mountall (Ubuntu Lucid): | |
status: | Fix Committed → Fix Released |
Changed in mountall (Ubuntu Lucid): | |
status: | Fix Released → Fix Committed |
Changed in mountall (Ubuntu Lucid): | |
status: | Fix Committed → Fix Released |
Changed in plymouth (Ubuntu): | |
status: | Triaged → Invalid |
Changed in plymouth (Ubuntu Lucid): | |
status: | Triaged → Invalid |
Changed in plymouth (Ubuntu): | |
status: | Invalid → Triaged |
Changed in plymouth (Ubuntu Lucid): | |
status: | Invalid → Triaged |
description: | updated |
Changed in linuxmint: | |
status: | Confirmed → Fix Released |
tags: | added: testcase |
As four people are affected, I set the status to confirmed.
I experience this behavior on 64 bit. The 'problematic' area starts at 74%. I'm running a fully up to date Lucid.