fsck progress stalls at boot, plymouthd/mountall eats CPU

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.

I get this on a Dell Mini 9; the slowdown starts at 70% and gets even worse at 90%,to the point that I eventually just shut down the machine.

The odd behaviour from 70% on has been present ever since I installed the beta. Initially there was a complete hang at 70%; this was "fixed" (#554737) inasmuch as the machine no longer locked up, but there was clearly something still wrong; fsck got to 70% and stopped and then the login screen came up.

Over the past couple of days something has changed; fsck proceeds beyond 70% but impossibly slowly.

I am waiting for fscheck to finish booting my other PC since 7 minutes now... stil all 95%, very very slow.

This not happening only on ext4: on ext3 it is even worst

Thanks for the report, guys.

It _sounds_like this could be a plymouth issue, but I'd like to collect some more information to be sure.

Could you install the "bootchart" package and reboot (with fsck forced I guess), attach the resulting image from /var/log/bootchart

Thanks

Bootchart logs

Dell Inspiron Mini 10v 8Gb SSD running Lucid 10.4 with latest updates.
I have exactly the same fault. As with the other reports, three or so updates back, the boot process froze completely. Taking out quiet splash showed that it froze after fsck had completed. The last two updates have stopped it freezing, but fsck now takes in excess of 20 mins to complete on this netbook.

My suggestion for now would be to kill plymouth when /forcefsck is detected. I don't think this would be a popular suggestion, but for me, it would be nice!
Barry.

Forgot to say: I'm running an ext2 partition!!!

I'm sorry if this end up as a hijack, but I'm assuming this is the same issue...

This seems to be a very common thing.
I would suspect plymouth for the problem, since if you do jump out to a TTY during this then the boot seems to complete nicely.

In fact, if you jump to tty and then jump back to plymouth it's noticable that it has managed to get much further in the percent compared to what it would have if you just stayed on the plymouth screen...

Each time I jump to tty the normal "fsck...clean...non-contiguous #%" message is repeated (one extra each jump) which presumably indicates that fsck has finished, and plymouth (or something else) is messing about with other things...

srv-1-lucid-20100430-1.tgz and srv-1-lucid-20100430-1.png
'quiet splash' set in grub kernel commandline
takes 6:30 to complete

srv-1-lucid-20100430-2.tgz and srv-1-lucid-20100430-2.png
*NO* 'quiet splash' set in grub kernel commandline
takes 00:26 to complete

Also notable is that if I boot with quiet and splash disabled, everything is fine and I'm up in less than a minute.

One thing worth notice is that there is no fsck progress given when booting without the splash.

All my testing done on a virtualbox instance of Lucid

Here is the picture from bootchart. Again, boot process completed after some 20mins or so. Bootchart also produces a compressed archive containing some logs - do you need this as well?

Just to confirm - with quiet splash removed from grub, my netbook boots in seconds rather than minutes when fsck is forced.

I saw this too, and can reproduce with touch /forcefsck; reboot. Here’s a bootchart; it shows mountall spinning at 100% CPU for about 15s after the first fsck finishes, and again for over 200s after the last fsck finishes. I wonder what it’s doing with all that CPU…

I think removing ‘quiet splash’ is a red herring. I can reproduce the problem by creating /forcefsck, whether or not ‘quiet splash’ is in the boot flags. Here is a bootchart without ‘quiet splash’ that demonstrates the same problem (mountall spins at 100% CPU for 200 seconds after all the fscks are complete).

@Anders Kaseorg:
Sorry, I was in the process of updating the bug description and inadvertedly overwrite your changes.

I am however most definitely able to work around the issue removing quiet and splash...

Maybe we're even bunching two or more separate bugs here...

Yup, just tested now, and disabling quiet and splash makes this virtualbox able too boot no problem...

I'm trying to figure out the arrow-out workaround now... it seems to be very fickle.

Here’s a backtrace from mountall while it is spinning. It starts with
#0 0x00007ff69c9fc6e3 in ply_list_find_node (list=0x7ff69e0af860,
    data=0x7ff69faf6460) at ply-list.c:105

Comaparing letstrynl's and Anders Kaseorg's bootcharts it seems like there a two separate issues here.
On letstrynl's bootchart it's plymouthd that's eating the CPU, whereas on Anders Kaseorg's it's mountall.

This could account for our disagreement as to the workarounds.

We should maybe split off the plymouthd instance into a new bug, to avoid confusion.

Okay. Let me first start out retracting pretty much everything I've said so far... there, now let's start anew:

(Using a virtualbox Lucid 32bit guest on 32bit Karmic host)

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 (in my case, around an hour).

TEST CASE:

(sudo aptitude install bootchart)
sudo touch /forcefsck && sudo reboot

WORKAROUNDS

1. Removing "quiet" and "splash" from the kernel boot line

3. 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 "somethingsomething non-contiguous somethingsomething" Which I assume indicates the end of the fsck, is printed in the Virtual Terminal (Not-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-simultaneously:
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.

BOOTCHARTS
(attached along with complete bootchart log as arand_bootcharts.tar.gz)

0arand_clean
######
Reference clean boot, with plymouth and no fsck.

1arand_switch_to_vt_early
######
In this boot I switched to VT (allowkey out from splash) quite early, as seen in that the shift plymouthd->mountall cpu-hogging is early. mountal takes a little over 100 seconds to finish.

2arand_switch_to_vt_later
######
In this boot I switched to VT later on.
It might be noteworthy that the time that mountall cpu-hogs is approximately the same (100s)

3arand_no_quiet_splash
#####
mountall still hogs the cpu, but for a considerably shorter time, overall boot finishes much faster.

Please do tell if there is anything else useful I could provide.

the installation on my desktop computer was a fresh install and it is NOT AFFECTED from this bug.
the installation on my laptop is an upgrade from karmic and it is AFFECTED from this bug.
all these two installations where done starting from release candidate and are now updated.

could the bug be related to DISTRIBUTION UPGRADE (i.e. from karmic)?

I did a fresh installation on my desktop machine (64-bit) also.
Still has the bug. Removing 'splash' fixed the problem, as before.

Could it be that it is hardware related?

commands I used:
  bios: hwinfo --bios | grep Socket:
  video: hwinfo --gfxcard | grep Modules:

desktop 64-bit:
  bios: Socket: "LGA1366"
  video: Driver Modules: "nvidia"

server 64-bit:
  bios: Socket: "Socket437"
  graphics: Model: "Intel 945G"

frnstefano, can you check this, and tell us if you're using the 'nouveau' driver?

I would guess that it is not hardware related, since I'm seeing this on a virtualbox 32bit.
This one is not an upgraded system but it has been around since beta somewhere.

I'm having exactly the same problem fsck stalling at 70% and then finishes after a very long time. I've upgraded from karmic and use the nvidia closed driver not the nouveau one. The process eates my CPU and it's very disturbing.

i will post something more complete in late afternoon because i cannot connect to the desktop system now.

laptop 32-bit:
$ hwinfo --bios |grep Socket
    Socket: "uFCPGA2"
    Socket Type: 0x04 (ZIF Socket)
    Socket Status: Populated
    Location: 0x00 (Internal, Not Socketed)
$ hwinfo --gfxcard
22: PCI(AGP) 100.0: 0300 VGA compatible controller (VGA)
  [Created at pci.318]
  UDI: /org/freedesktop/Hal/devices/pci_1002_4e50
  Unique ID: VCu0.PkvpIaxQqbF
  Parent ID: vSkL.oF7y00qHwA3
  SysFS ID: /devices/pci0000:00/0000:00:01.0/0000:01:00.0
  SysFS BusID: 0000:01:00.0
  Hardware Class: graphics card
  Model: "ATI RV350 NP"
  Vendor: pci 0x1002 "ATI Technologies Inc"
  Device: pci 0x4e50 "RV350 NP"
  SubVendor: pci 0x1025 "Acer Incorporated [ALI]"
  SubDevice: pci 0x005d
  Memory Range: 0xd8000000-0xdfffffff (rw,prefetchable)
  I/O Ports: 0x3000-0x3fff (rw)
  Memory Range: 0xd0100000-0xd010ffff (rw,non-prefetchable)
  Memory Range: 0xd0120000-0xd013ffff (ro,prefetchable,disabled)
  IRQ: 11 (116070 events)
  I/O Ports: 0x3c0-0x3df (rw)
  Module Alias: "pci:v00001002d00004E50sv00001025sd0000005Dbc03sc00i00"
  Driver Info #0:
    XFree86 v4 Server Module: radeon
  Driver Info #1:
    XFree86 v4 Server Module: radeon
    3D Support: yes
    Extensions: dri
  Config Status: cfg=new, avail=yes, need=no, active=unknown
  Attached to: #11 (PCI bridge)

i have these problem the problem of fsck stall with both dri (KMS disabled) and dri2

desktop 64-bit:
Core Duo Q9400 (socket 775)
Ati Radeon 4870x2 (fglrx driver from ubuntu packages)

I hope this could help for the moment... i'll post other informations about 64-bit system later

Interesting thought that this could be related to upgrading from Karmic rather than a fresh install. Both my machines suffer from the problem and were upgraded, for what it's worth. How about everyone else?

On Monday 03,May,2010 06:49 PM, D J Eddyshaw wrote:
> Interesting thought that this could be related to upgrading from Karmic
> rather than a fresh install. Both my machines suffer from the problem
> and were upgraded, for what it's worth. How about everyone else?
>
I think if you read some of the comments made before yours, you'll notice that
there was a fresh install test case which suffered from this problem as well.

--
Kind regards,
Chow Loong Jin

> Arand:
> I would guess that it is not hardware related, since I'm seeing this on a virtualbox 32bit.

I just tested a fresh 32-bit installation within virtualbox.
No problems whatsoever (with or without quiet/flash).
I don't see any progressmeter, by the way.

This could mean it *IS* hardware related.

Plymouth has hooks into graphics drivers, so...

People, can everyone (with or without problems) run the two hwinfo commands mentioned (with grep please) , so we can see if there's a connection between hardware and the behavior of plymouth ?

As allready said, mine are:

desktop 64-bit:
  bios: Socket: "LGA1366"
  video: Driver Modules: "nvidia"

server 64-bit:
  bios: Socket: "Socket437"
  graphics: Model: "Intel 945G"

commands:
  bios: hwinfo --bios | grep Socket:
  video: hwinfo --gfxcard | grep Modules:

to letstrynl: hwinfo --gfxcard | grep Modules doesn't produce any output. do you mean hwinfo --gfxcard | grep Model??

desktop 32-bit
   bios: Socket: "uFCPGA2"
   video: Model: "ATI RV350 NP"

only splash directive reproduces the bug.
removing or not quiet directive doesn't change nothing in my case.

quiet AND splash --> fsck stalls
ONLY splash --> fsck stalls
ONLY quiet --> all works fine
NO both --> --> all works fine

Linux Plato 2.6.32-21-generic-pae #32-Ubuntu SMP Fri Apr 16 09:39:35 UTC 2010 i686 GNU/Linux

 hwinfo --bios | grep Socket:
(nothing. Blank)

hwinfo --gfxcard | grep Modules:
  Driver Modules: "nvidia"

Just investigating on the long time fsck during boot on my netbook with ubuntu 10.04 (around 15 minutes)

I want to confirm, but can't give you hwinfo output, as I'm not @home right now.

It's a Samsung NC10 Netbook on Atom platform with Intel Video.
Maybe somebody else can supply additional information if necessary. Thx.

hwinfo --bios | grep Socket requires root permission to produce the
output.

Fabio Marzocca try using sudo hwinfo --bios | grep Socket

addition to comment #36:

updated from 9.10 karmic (and still use grub legacy if this should affect boottime)

hwinfo --bios | grep Socket requires root permission to produce the
output.

try using sudo hwinfo --bios | grep Socket

On Mon, 2010-05-03 at 13:34 +0000, letstrynl wrote:
> People, can everyone (with or without problems) run the two hwinfo
> commands mentioned (with grep please) , so we can see if there's a
> connection between hardware and the behavior of plymouth ?

I looked at this, and hwinfo doesn't seem to exist on my netbook. I
looked at installing it, but is seems to be asking for a crazy amount of
drive space that I actually don't have. I only have 8 Gig on this
little netbook. Dell Inspiron Mini 10v - 8Gig SSD

I do have the problem. Will the output from lshw help? If so, do you
want that piped through grep? Please give the command you would like
and I'll run it.

BTW - this morning, fsck was forced automatically. I pressed an arrow
key when it stalled, and the process completed in < 1min.

15.11.2010 00:11, Chow Loong Jin wrote:
> Status in “mountall” source package in Lucid: Fix Released
>
> Again, Get The Facts™. I don't care what Mint LTS does, but Ubuntu LTS has it
> fixed, so please don't confuse the two again.
>

Thanks for pointing out on this. So, what is the _real_ current status for this
bug? I know how does it behave in Linux Mint 9 LTS (bug is still there). But
what about Ubuntu 10.04 LTS? I've seen reports here that it is still not fixed
too (most recent was by Richard Postlewait). So whom too believe?

P.S. Needless to say that an argument that it took a way to long to fix it in
Ubuntu (in case it is really fixed) still counts. And another thing to note: Get
The Facts™, this bug is not about Ubuntu only. So I don't care if you care about
what Mint LTS does - this bug applies to Mint LTS so all people here blaming
about have got all rights and reasons to do so.

--
Best regards,
Alexey Loukianov mailto:<email address hidden>
System Engineer, Mob.:+7(926)218-1320
*nix Specialist

On Monday 15,November,2010 05:43 AM, ingo wrote:
>> Status in “mountall” source package in Lucid: Fix Released
>
> But when - too late!
>
> Such things happen when releases are time based instead of "when it's
> done". What is a LTS-release worth when takes months to become ready for
> use.They are almost done approximately with second point release, so
> remaining sevice period is by far less then advertised.

The bug was reported on 2010-04-29. When was Lucid released? 2010-04-29. Given
the complexity of this bug, as you would have discovered if you had actually
read through the original comments, it was not an easy one to identify. When did
it get fixed *in Lucid*? 2010-05-09. That's 10 days after release. Ten days for
a tough bug like this one. I believe we deserve a little credit.

Then Mint appears, without deploying our patched packages properly, and a whole
bunch of Mint users come here to complain that Mint doesn't work, and blame
Ubuntu for it, and then talk about Mint's superiority. Oh, the irony. Thank you
for trolling, guys. That was fun, wasn't it?

> Why is Mint considering a Debian-based version?

Hell if I know, and I don't give a damn. Maybe some other Ubuntu developers do,
but I don't. Mint can do whatever they want.

--
Kind regards,
Loong Jin

On Monday 15,November,2010 08:54 AM, Alexey Loukianov wrote:
> 15.11.2010 00:11, Chow Loong Jin wrote:
>> Status in “mountall” source package in Lucid: Fix Released
>>
>> Again, Get The Facts™. I don't care what Mint LTS does, but Ubuntu LTS has it
>> fixed, so please don't confuse the two again.
>>
>
> Thanks for pointing out on this. So, what is the _real_ current status for this
> bug? I know how does it behave in Linux Mint 9 LTS (bug is still there). But
> what about Ubuntu 10.04 LTS? I've seen reports here that it is still not fixed
> too (most recent was by Richard Postlewait). So whom too believe?

Well, given that it is a pretty noticeable bug, and a very annoying one when you
notice it, and that the only users complaining about this bug now are Mint
users, I would believe that Ubuntu has it fixed, even in 10.04 LTS, but perhaps
not in Mint.

And Ubuntu 10.04 LTS had it fixed since May 9th, which is 10 days after release,
and also 10 days after this bug was reported (it was reported on release date).

> P.S. Needless to say that an argument that it took a way to long to fix it in
> Ubuntu (in case it is really fixed) still counts.

10 days is too long? Really? If you used Ubuntu, you should have only
encountered this once, if at all, since fsck only happens every 30 days or after
a set number of mounts I can't remember. Unless you do reboot your computer that
many times in a day..

> And another thing to note: Get The Facts™, this bug is not about Ubuntu only.
> So I don't care if you care about what Mint LTS does - this bug applies to
> Mint LTS so all people here blaming about have got all rights and reasons to
> do so.

Then you can use this as basis to report about Mint's failures to your clients,
but please keep in mind that Ubuntu is not Mint.

--
Kind regards,
Loong Jin

Sorry for my bad english and the following is translatet by google:

At certain intervals Mint 9 tries to examine me before the start of the hard drives for errors. The process ever run for several hours, but he has not come to an end. In the beginning, I can still read "Mint examined 1 of 2 hard drives (progress". The text appears exactly without 2.Clamp and progress bar. Then disappears at some point this line and today I canceled the process after about an hour.

The LED will disappear when the two line stops blinking. It also does nothing for hours.

The problem have many users of Mint 9 and you can read the Thread in the german community of www.linuxmintusers.de

I hope the problem will fixed soon.

Thanks
Andreas

Here you can read the Thread in the community of linuxmintusers.de:

http://www.linuxmintusers.de/index.php?PHPSESSID=372fd229d183e69a2002e19784600d19&topic=2532.msg18576#new

15.11.2010 06:14, Chow Loong Jin wrote:
> 10 days is too long? Really?
>
If it was really fixed in that 10 days and all people reporting here blaming
Ubuntu are in reality just hadn't installed fresh updates or are using Mint
instead then it was fast enough to call it "good level of support". If not -
it's a shame for Ubuntu. And it is certainly a shame for Mint that this bug is
still unfixed.

> Then you can use this as basis to report about Mint's failures to your clients,
> but please keep in mind that Ubuntu is not Mint.
>
It is certainly not. As for clients - unfortunately they prefer working
workstations instead of reports about Mint's failures. About half of linux
installations in production environment I've done last year were based on Mint
LTS (rest were CentOS 5 based). Looking at the history of this bug I would
reconsider to use Ubuntu instead of Mint in a near future, probably switching to
the CentOS 6 as soon as it would be released.

--
Best regards,
Alexey Loukianov mailto:<email address hidden>
System Engineer, Mob.:+7(926)218-1320
*nix Specialist

It is a shame that this bug is not yet solved for Mint 9

It's all very sad, after almost seven months.

Hello,

If people using a up-to-date 10.04 (or later) of stock Ubuntu are still seeing symptoms described in this bug I would STRONGLY recommend they file a new bug report. Mint users are similarly better off filing a bug report in their distribution's bug tracker as it is difficult to tell whether the exact same problems they are seeing exist in stock (updated) Ubuntu too). It possible an issue still exists in Ubtunu but if so posting to this bug report is not going to help as it has become quite long and too confused. A new bug report for Linux Mint users might serve them better.

For what it is worth, in Ubuntu 10.04 the 2.15 version of mountall resolved the problem I was seeing. I have just retested the system that showed the problem and the fix still seems to be holding. This suggests that anyone seeing the symptoms described in this bug report with a version of mountall of *2.15 or later* is almost certainly seeing a bug stemming from a different root cause and as such should definitely be reporting the issue in a different bug report (a good bug report should generally only cover one root cause so that separate issues can be closed individually).

Good luck!

Well pardon me. I'm sorry for the wrong info. I just know what took place on
my system. So until you have walked in my shoes, you need to keep your
attitude and that I know all bull crap to yourself. So cancel my account,
who really cares. Its just a linux distro, life still goes on.

On Nov 14, 2010 3:32 PM, "Chow Loong Jin" <email address hidden> wrote:

On Monday 15,November,2010 01:38 AM, Richard Postlewait wrote:
> I can't answer that one; sorry. I ...
No, I don't believe this issue is present in Ubuntu any longer, see this
bug's
status on mountall, which was flooding plymouth with events. All the recent
noise here was caused by Mint users and Mint users alone. Please Get The
Facts™
before posting next time.

--
Kind regards,
Loong Jin

--

fsck progress stalls at boot, plymouthd/mountall eats CPU
https://bugs.launchpad.net/bugs/571707
You...

https://bugs.launchpad.net/linuxmint/+bug/675462

On Tuesday 16,November,2010 12:17 AM, Richard Postlewait wrote:
> Well pardon me. I'm sorry for the wrong info. I just know what took place on
> my system. So until you have walked in my shoes, you need to keep your
> attitude and that I know all bull crap to yourself. So cancel my account,
> who really cares. Its just a linux distro, life still goes on.

Don't get me wrong. Nobody's interested in cancelling your account. I just
requested that you try your best to keep the spreading of misinformation to a
minimum.

My issue was with how you phrased "If I'm not mistaken, Ubuntu still has the
same problem." If you don't know, please don't pretend that you have an idea. It
was pretty much that comment there that sparked the whole bunch of scathing
false accusations about Ubuntu not bothering to fix serious bugs within
reasonable time for its LTS releases.

If it was not your intention to cause this situation, then I genuinely am sorry
for lashing out at you like that. Otherwise, please find better uses of your
energy and time that do not involve wasting others' time.

--
Kind regards,
Loong Jin

@ Loong Jin

please accept my excuse regarding the statement that "fixing the bug in Lucid did take too long" - 10 days ist really fast.

On the other hand - and that is probably why people including me get upset so easily - the real root cause is something different and in no way addressed to you personally - it is related to plymouth:

I followed the development of Lucid since alpha stage and experienced that an enormous effort was put into plymouth to get it working somehow. This eye-candy splash screen had priority over functional features and still today plymouth is causing troubles (the normal user can't un-install it because artificially tied to mountall and cryptsetup and Canonical refuses to correct dependencies).

A lot of bug reports like this one are in my opinion related to plymouth which requires to patch 'mountall' and 'cryptsetup'. And these are really patches and no fixes, because they all have to consider not to disturb buggy plymouth. The logical way to solve this issues/bugs would be to purge plymouth and set up a good functional system.

Best regards, Ingo

16.11.2010 00:25, ingo wrote:
> The logical way to solve this issues/bugs would
> be to purge plymouth and set up a good functional system.

Correct me if I'm wrong but it is perfectly possible to get rid of plymouth in
initramfs and following boot process by simply not installing plymouth themes
packages. Yes, it might require to delete metapackages like "mint-meta-*", but I
don't see much trouble in having them uninstalled anyway because the default set
of packages that Mint tends to install is far from "minimal" set required to get
a slim linux installation perfectly fitting the "normal office workstation"
requirements.

--
Best regards,
Alexey Loukianov mailto:<email address hidden>
System Engineer, Mob.:+7(926)218-1320
*nix Specialist

Enough. Your points are both understood. Quit spamming.

I activated level 4 and 5 updates in mitupdate and updated all packages that are possibly related to this bug (mountall, upstart, plymouth) so they are the same version as in Ubuntu 10.04 now. But the bug still remains.

Does anybody know if Ubuntu 10.04 users still suffer from this bug?

mountall 2.19 is available for Ubuntu 10.10. The description of the bugfix between 2.15 and 2.19 appears to tackle this bug. The dependencies of 2.19 are satisfied by Ubuntu 10.04. This bug hasn't gone away with 2.15-3. So why has 2.19 not been provided to 10.04? This bug is very annoying and potentially dangerous, since inevitably one has to cancel fsck. Can we get 219 into the 10.04 repositories please?

When a disk check is performed, the progress stalls (I don't see any progress bar or % but I can't hear a hard disk not working) and I press F2 I see: plymouth main process terminated with status 1.

Good day.

Clem please action the introduction of mountall 2.19 into the repos for Linux Mint 9 LTS so this issue may be resolved.

Thanks

- Justin

mountall 2.19 added to Mint 9 repository as a level 4 upgrade.

@Justin: Let's keep an eye on it so we can eventually reduce the level to 3 or even 2 in a week or so.

I installed new mountall 2.19 and did "sudo touch /forcefsck && sudo reboot"
but nothing has changed. It stucks and I can't see any % progression only information ...presss C...
But when I press F1 I can see some info about ... plymouth main process terminated with status ...
I wish I could sent a log report but I don't know how to.

Dear Clement,

first of all I would like to thank you very much for the creation of this great OS Linux Mint.
What I'm using:
HW: Lenovo Thinkpad T410
OS: Linux Mint Isadora 64bit with ext4 filesystem
I've updated the mountall package to version 2.19, but the problem still exists.
The fsck process on boot is faster now but when it stops at 100% only the splash screen with no additional info appears on the screen.
When hitting ESC the message "/dev/sda1: .../... files (0,2% discontiguous) , .../... blocks" appears
The boot process can only be continued by pressing the "c" button.

* I'm getting the same problem on an Acer Laptop with Linux Mint Isadora 32bit!

Thanks in advance for your help!
Best regards,
Kurt

the problem is not fixed yet

Is there any help available regarding this bug please??
It is open since 2010-04-29 (!)

On 22.08.2011 17:31, queo wrote:
> Is there any help available regarding this bug please??
> It is open since 2010-04-29 (!)

Here: http://www.debian.org/devel/debian-installer/ - works reliably.

Excerpts from ingo's message of Mon Aug 22 16:07:50 UTC 2011:
> On 22.08.2011 17:31, queo wrote:
> > Is there any help available regarding this bug please??
> > It is open since 2010-04-29 (!)
>
> Here: http://www.debian.org/devel/debian-installer/ - works reliably.
>

Bug reports are for helping developers fix and/or prioritize bugs,
including dialog with affected users. Ingo, if you are no longer affected,
and/or have nothing constructive to add, please refrain from posting
comments.

this fix doesn't work

Oddly this was fixed in Ubuntu 10.4.2 and its sub-sequent releases. Mint
maintains that the bug lies upstream. Oh wth I'm using LMDE now

On Wed, Aug 24, 2011 at 3:34 PM, queo <email address hidden> wrote:

> this fix doesn't work
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (607507).
> https://bugs.launchpad.net/bugs/571707
>
> Title:
> fsck progress stalls at boot, plymouthd/mountall eats CPU
>
> Status in The Linux Mint Distribution:
> Fix Released
> Status in “mountall” package in Ubuntu:
> Fix Released
> Status in “plymouth” package in Ubuntu:
> Triaged
> Status in “mountall” source package in Lucid:
> Fix Released
> Status in “plymouth” source package in Lucid:
> Triaged
>
> 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/reporting a new bug.
>
> [Earlier patch comments:]
> Tero Mononen has published a patch for Bug #553745 which applies to the
> issue described here as well (see
> https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/553745/comments/76and
> https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/553745/comments/77)
>
> I have created corresponding packages which are available through my
> PPA: https://launchpad.net/~arand/+archive/unstable
>
> !!!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-simultaneously:
> 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...

Please, are there any updates on this issue?
The mountall package 2.19 doesn'nt fix the problem.
Is anybody working on this to resolve this bug???

Just installed ubuntu 10.04.3 64 bits, mountall is 2.15 and getting the same problem. In this post looks like its solved, is it?
Tried workaround but is not working.

Any hint,

Thanks in advance

Please, are there any updates on this issue?
The bug is open since 2010-04-29!
I'm using Linux Mint Isadora 64bit and 32bit, both are having the same bugs.
Please update the Status to "Won't fix"!!!

On 25/10/2011 21:31, queo wrote:
> Please, are there any updates on this issue?
> The bug is open since 2010-04-29!
> I'm using Linux Mint Isadora 64bit and 32bit, both are having the same bugs.
> Please update the Status to "Won't fix"!!!
>

But it's fixed in Ubuntu Oneiric.

--
Kind regards,
Loong Jin

25.10.2011 18:38, Chow Loong Jin wrote:
>
> But it's fixed in Ubuntu Oneiric.
>

And what does it change with regards to Linux Mint 9 Isadora users? Who cares if
this bug was fixed in some fresh-n-shiny Ubuntu and/or Mint release while it is
still not fixed in so-called "Long Term Support" version of Linux Mint? And - to
be honest - I still occasionally hit this bug on Ubuntu 10.04 LTS despite the
fact that it had been marked as "fixed" for Ubuntu months ago. Released "fix"
had only changed the frequency this bug happens: before fix I've been hitting
this bug every time I force my system to do fsck on next boot. After the "fix" I
hit this bug about once in 4-5 fsck-enabled reboots. Better than nothing but
still smells like crap.

--
Best regards,
Alexey Loukianov mailto:<email address hidden>
System Engineer, Mob.:+7(926)218-1320
*nix Specialist

Dear Loong Jin,

thanks for your reply.
I always thought there is a support for 3 years for LTS releases (Ubuntu 10.04 is LTS).
Do I have the wrong information here?

Best regards,
Kurt

On 25/10/2011 22:59, queo wrote:
> Dear Loong Jin,
>
> thanks for your reply.
> I always thought there is a support for 3 years for LTS releases (Ubuntu 10.04 is LTS).
> Do I have the wrong information here?
>
> Best regards,
> Kurt
>

Sorry, let me correct myself. It's been fixed from lucid-updates all the way up
to oneiric, and I have not experienced this ever since the fix landed in
lucid-updates. That said, I had no part in the creation of the patch that fixed
this bug, and don't have a clear idea on what's going wrong where. And I don't
use Linux Mint, so I have no idea what's going wrong there either.

The status of the bug is correct -- it's fixed in mountall on Ubuntu, and
mountall in Lucid (via lucid-updates). If it's still broken in Linux Mint, then
open a task there and set it to the appropriate status. There is no reason to
demand that the "Fix released" status in Ubuntu be changed to "Won't Fix" when
it clearly has been fixed over here.

So to sum it all up in a nutshell, it's all fixed on Ubuntu, but not fixed on
Linux Mint, so obviously something went wrong somewhere in porting the fix from
Ubuntu to Mint, so please stop blaming Canonical or Ubuntu for not paying
attention to this bug report. If you need someone to badger about this bug
occurring in Mint, find a Mint developer.

--
Kind regards,
Loong Jin

On Tue, Oct 25, 2011 at 05:42:18PM -0000, Chow Loong Jin wrote:
> The status of the bug is correct -- it's fixed in mountall on Ubuntu, and
> mountall in Lucid (via lucid-updates). If it's still broken in Linux Mint, then
> open a task there and set it to the appropriate status. There is no reason to
> demand that the "Fix released" status in Ubuntu be changed to "Won't Fix" when
> it clearly has been fixed over here.

> So to sum it all up in a nutshell, it's all fixed on Ubuntu, but not fixed on
> Linux Mint, so obviously something went wrong somewhere in porting the fix from
> Ubuntu to Mint, so please stop blaming Canonical or Ubuntu for not paying
> attention to this bug report. If you need someone to badger about this bug
> occurring in Mint, find a Mint developer.

There is a task for Linux Mint on this bug already, and its status has been
set to 'fix released' by a Mint developer, apparently on the basis that the
lucid-updates version of mountall was copied into Linux Mint 9. I believe
it's the status of *this* task that the Mint users are concerned with.
Unfortunately, the Launchpad bug workflow doesn't make this at all clear.
(I think for this reason it might be better for derivatives to use separate
bugs for tracking issues, instead of tasks on Ubuntu bugs.)

There are also comments that the bug is still reproducible with 10.04 with
much lower frequency. This may be true; when this bug was being worked on,
the analysis was that there was still a bug in plymouth here, just one with
much less user impact now that the mountall side has been fixed. However
(as you know, but it appears the users subscribed to this bug do not), "LTS"
does not mean that all bugs reported against that release will be fixed; it
means that security support, upgrade support, and commercial support are
provided, and that bugfixes will be made on a best-effort basis.

And there are a number of other plymouth bugs present that are higher-impact
than this one, so it is unlikely that this bug will receive further
attention for 10.04.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Steve Langasek (vorlon) wrote on 2011-10-25:

> And there are a number of other plymouth bugs present that are higher-impact
> than this one, so it is unlikely that this bug will receive further
> attention for 10.04.

That's true for sure. With this in mind it is definitely a shame that Canonical tries to prevent
users from un-installing plymouth by artificially setting plymouth as dependency for mountall.
Workarounds see bug #556372 - which is marked "won't fix".

On Sun, Oct 30, 2011 at 06:49:14PM -0000, ingo wrote:
> Steve Langasek (vorlon) wrote on 2011-10-25:

> > And there are a number of other plymouth bugs present that are higher-impact
> > than this one, so it is unlikely that this bug will receive further
> > attention for 10.04.

> That's true for sure. With this in mind it is definitely a shame that
> Canonical tries to prevent users from un-installing plymouth by
> artificially setting plymouth as dependency for mountall.

It is not an artificial dependency. *mountall cannot communicate with the
user without plymouth.* There must be some framework for multiplexing
boot-time I/O in order to let packages like mountall communicate with the
user, and that framework is plymouth. There aren't even any other
contenders in the field.

And your persistent sniping here about Ubuntu design decisions is an
inappropriate use of the bug system. Please stop.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

I'm using 9x64 with all updates and I've posted question on mint forums for last 6 month and have 0 replies. Auto fsck has never finished for me on this install. Seems everyone is working on the newest disaster, ahh, distribution. The problem with all linux distributions is that no-one cares about a finished product. They just barely get it to work, then it is on to the next thing.

PLEASE FINISH ONE THING COMPLETELY BEFORE GOING ON TO THE NEXT. BECAUSE THE NEXT THING WILL JUST HAVE ANOTHER SET OF BUGS, AND YOU WILL NEVER HAVE A UN-BUGGED, CLEAN RUNNING PROGRAM.

Eol is very close; so its time to use a newer release