mountall should cause fsck to show progress on text console

Also observed in Natty. Given that full fscks are rare (like, once every 6 months), it is not the first thing you think about when your machine seemingly hangs forever in the boot process.

I ended up booting the machine with a rescue CD and mounting the disks by hand in order to find out what the heck was going on. That was an hour wasted. I'd much rather have seen a progress bar or the little twirly thing: -/|\-/|\-...

This is *also* a problem in the regular desktop ubuntu.

In regular desktop ubuntu, progress is not shown anymore in plymouth. which is annoyingly because of the reasons mentioned above.

Still no progress bar in Precise. This really is bad, particularly on server because we get stuck with very long fscks on large disks and the progress bar is critical during unexpected downtimes. We need to be able to provide at least rough ETA's for our bosses/customers, and have assurance the system isn't hung.

I took a look at mountall.c and the following change restored the bar:

2247c2247
< arg = NIH_MUST (nih_sprintf (NULL, "-C%d", fds[1]));
---
> arg = NIH_MUST (nih_sprintf (NULL, "-C", fds[1]));

...although I can see how this would obviously not work in the distribution, is there something we can do to restore the progress bar? Looking through the code, it shouldn't be hard to implament (e.g. a setting in /etc/default/rcS).

The attachment "mountall.patch" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

Problem in 11.10 32bit also

Having this problem in 12.04!

Regarding this, I rebuilt a mountall package that fixed this bug and uploaded it to my PPA about two years ago.

I added the "--fsck-console" option to mountall, and then added the option to enable this at boot time by adding the line "FSCKCONSOLE=yes" to /etc/defaults/rcS. From the changelog:

   * Added "--fsck-console" parameter to use console progress bar. To
     enable, add "FSCKCONSOLE=yes" to /etc/defaults/rcS.

My PPA package is still sitting on Launchpad here: https://launchpad.net/~mark-syminet/+archive/syminet/+packages

If this seems a good approach, I'm willing to spend the time to take a look at this again but only if someone is willing to consider getting it into the distribution, since I only want to use distribution packages on servers for critical boot-things like this.

This really is a particularly nasty bug because servers can run for a long time without a power cut, etc. - but then that fateful day arrives and we are stuck without any idea if the remote machine is even hung, while bosses and customers are screaming about downtime demanding ETA's.

On 09.10.2012 20:33, Mark - Syminet wrote:
> Regarding this, I rebuilt a mountall package that fixed this bug and uploaded it to my PPA about two years ago.
>
> I added the "--fsck-console" option to mountall, and then added the
> option to enable this at boot time by adding the line "FSCKCONSOLE=yes"
> to /etc/defaults/rcS. From the changelog:
>
> * Added "--fsck-console" parameter to use console progress bar. To
> enable, add "FSCKCONSOLE=yes" to /etc/defaults/rcS.
>
> My PPA package is still sitting on Launchpad here:
> https://launchpad.net/~mark-syminet/+archive/syminet/+packages
>
> If this seems a good approach, I'm willing to spend the time to take a
> look at this again but only if someone is willing to consider getting it
> into the distribution, since I only want to use distribution packages on
> servers for critical boot-things like this.
>
> This really is a particularly nasty bug because servers can run for a
> long time without a power cut, etc. - but then that fateful day arrives
> and we are stuck without any idea if the remote machine is even hung,
> while bosses and customers are screaming about downtime demanding ETA's.
>

Could you perhaps update your package to version 2.41?

@Steve: Would you then consider picking up the change developped by Mark?

Cheers
    Mike

On Tue, Oct 09, 2012 at 09:03:00PM -0000, Michael Neuffer wrote:
> Could you perhaps update your package to version 2.41?

2.42 now.

> @Steve: Would you then consider picking up the change developped by
> Mark?

I don't think this is the right way to address this issue. This really
needs to happen transparently, without having to change any config files. I
think the best way to address this would be a change to the plymouth details
theme, to make it process fsck progress information the way the ubuntu theme
does.

Am Di, 9.10.2012, 23:46 schrieb Steve Langasek:
> On Tue, Oct 09, 2012 at 09:03:00PM -0000, Michael Neuffer wrote:
>> Could you perhaps update your package to version 2.41?
>
> 2.42 now.
>
>> @Steve: Would you then consider picking up the change developped by
>> Mark?
>
> I don't think this is the right way to address this issue. This really
> needs to happen transparently, without having to change any config files.
> I
> think the best way to address this would be a change to the plymouth
> details
> theme, to make it process fsck progress information the way the ubuntu
> theme
> does.

I wouldn't know, since plymouth and all those graphical gadgets did
nothing but create a world of hurt for me, I gave up on it and always take
out all graphical booting nonsense immediately after an installation on
any of the zoo of Debian and Ubuntu servers and clients that I maintain.

One of the reasons beeing that booting with more then one encrypted device
didn't work.

I want to know what is happening (or failing) behind the curtains during
the boot process. Otherwise I could instead use OS X or Windows.....

A config file is very acceptable for me. Those who don't want it can
switch it off. Those who don't want to stay blind and uninformed will
switch it on.

@Steve: Don't you agree?

Cheers
   Mike

On Wed, Oct 10, 2012 at 01:03:36PM -0000, Michael Neuffer wrote:
> I wouldn't know, since plymouth and all those graphical gadgets did
> nothing but create a world of hurt for me, I gave up on it and always take
> out all graphical booting nonsense immediately after an installation on
> any of the zoo of Debian and Ubuntu servers and clients that I maintain.

"Taking out the graphical booting nonsense" is precisely the reason you are
affected by this bug.

> One of the reasons beeing that booting with more then one encrypted device
> didn't work.

There are no open bug reports about such an issue.

> I want to know what is happening (or failing) behind the curtains during
> the boot process. Otherwise I could instead use OS X or Windows.....

You always have access to this information by pressing 'Esc' to toggle the
details plugin.

> A config file is very acceptable for me. Those who don't want it can
> switch it off. Those who don't want to stay blind and uninformed will
> switch it on.

> @Steve: Don't you agree?

No, I 100% disagree. This bug report is relevant because the server
install, by request of the server team, uses the plymouth details plugin by
default instead of a splash screen. *Desktop* users who have gone out of
their way to modify the boot experience have made their own bed, and
accomodating such deviations from the defaults is not a priority.

Does the desktop theme on Precise provide a progress bar? If anyone can chime in, please do otherwise I'll test it myself later this week in a VM.

On Oct 9, 2012, at 2:46 PM, Steve Langasek <email address hidden> wrote:

> On Tue, Oct 09, 2012 at 09:03:00PM -0000, Michael Neuffer wrote:
>> Could you perhaps update your package to version 2.41?
>
> 2.42 now.
>

Surprise, surprise.

>> @Steve: Would you then consider picking up the change developped by
>> Mark?
>
> I don't think this is the right way to address this issue. This really
> needs to happen transparently, without having to change any config files. I
> think the best way to address this would be a change to the plymouth details
> theme, to make it process fsck progress information the way the ubuntu theme
> does.
>

I've browsed other bug reports and can responibly say that unless plymouth is removed as a
a strong dependency from the mountall - it is HARMFUL TOWARD FREE _ FREE _ SOFTWARE.

Admit it.

> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/765735
>
> Title:
> mountall should cause fsck to show progress on text console
>
> Status in “mountall” package in Ubuntu:
> Triaged
>
> Bug description:
> Binary package hint: mountall
>
> mountall should cause fsck to show progress information (-C 0).
>
> Especially on large FS that take very long to fsck (sometimes many hours) it is very important
> to know that the fsck isn't actually hanging and still working.
> It is not possible to log in via console or ssh to check the status even for filesystems that are not boot- essential.
>
> Plymouth splash screen is disabled as this machine is a server.
>
> This behaviour has caused trouble several times already as the system
> was believed to be hanging and unresponsive and got rebooted while the
> fsck was still running.
>
> ProblemType: Bug
> DistroRelease: Ubuntu 11.04
> Package: mountall 2.25ubuntu1
> ProcVersionSignature: Ubuntu 2.6.38-8.42-generic 2.6.38.2
> Uname: Linux 2.6.38-8-generic x86_64
> NonfreeKernelModules: nvidia
> Architecture: amd64
> Date: Tue Apr 19 11:51:06 2011
> InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Beta amd64 (20100901.1)
> ProcEnviron:
> SHELL=/bin/bash
> PATH=(custom, no user)
> LANG=en_US.UTF-8
> LANGUAGE=en_US:en
> SourcePackage: mountall
> UpgradeStatus: No upgrade log present (probably fresh install)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/765735/+subscriptions
>

You've failed to consider your userbase; nobody cares.

I read some other thread regarding Ubuntu making plymouth a too-strong dependency. et. al., so I guesss this is our bug. Most importantly, this:

https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/556372

...to which you ignored your users? And this:

https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/553285

...to which

It's increasingly possible that you have bug reporters who are capable of what they are doing, yet thwarted by "best approach" methods determined by people who are looking out for their own best interests. Although I might not question your take, if you would like this to go away then your users would greatly appreciate an explicitly sound explanation as to why you've decided to ram plymouth, which apparently ignores the console, our throats.

I've browsed at least a half-dozen other bug reports, some of them very long, which do not exist in debian systems.
Although debian is a pain too, at least they are open about everything and those of us wiling and capable of modifying C code, are not unilaterally thrown into the dustbin.

If someone at Canonical is willing to get onto a con-call regarding your userbase, I am happy to do so.

This is an Ubuntu-specific bug. Politically saying, that freedom should extend to new users. Hiding the boot process behind a compiled C program is a BAD THING. Our users should always have the option to understand and learn from the boot process from any terminal. And this should be an easy thing for them to do.

TL;DR please give your users an exact explanation as to why you made plymouth such a strong dependency. This is ridiculous to those of us who don't understand the specifics which must be happening here. Please fully explain this decision.

And BTW, there are *multiple* bugs regarding crypsetup. To wit:

https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/556372

Is this correct? I see similar complaints nestled within a myriad of other bug threads similar to this one.

On Fri, Oct 12, 2012 at 01:04:44PM -0000, Mark - Syminet wrote:
> TL;DR please give your users an exact explanation as to why you made
> plymouth such a strong dependency.

This explanation has been given repeatedly in bug reports. Which just goes
to show why launchpad bugs are the wrong place to give such explanations,
because nobody reads them. But ok, I'll try once more.

The misunderstanding here is that you are viewing plymouth as a "boot
splash". It is not. It is a boot-time I/O serializer. This is an absolute
requirement on a system with a fast event-based boot like upstart, because
without it you can never reliably interact with the system at boot time -
interaction that's needed for processes like fsck, and cryptsetup. You have
one console, and N fscks that may be running in parallel, and you need to be
darned sure that your keypresses are controlling the right process.

That's why having fsck spit output directly to the console is not a suitable
solution. And the fact that the display of the plymouth splash screen can
be toggled at runtime is why having a config file to control where mountall
sends it output is not suitable either.

Now, in addition to multiplexing we also care about users having a
nice-looking boot experience, which is why the graphical splash is the
default (and has been since long before plymouth was around) and most of the
engineering work has been around making the graphical experience work
smoothly. This unfortunately means that some things don't work as well when
using the details plugin - such as this issue described here. But that's a
priority because of server, not because desktop users might opt out of the
graphical splash when it's working.

Thanks Steve for taking the time to explain. This is exactly it - people think that plymouth is only "annoying graphical stuff" without realizing that upstart is replacing the System-V init entirely - already has for the symlinks in /etc/init.d. And the way upstart communicates with the display (text or graphical - does not matter) is through plymouth. Which is why if you do a hacked removal of plymouth, upstart jobs don't show up on the boot messages - only the old System-V jobs do.

I have only ubuntu servers here but will take a look at desktop this week. If desktop has a progress bar during fscks, then I guess one approach might be to merge that with details so that we can toggle between them using <esc>? I don't think anybody would mind that much, so long as we have at least some way to get the progress info (graphical or otherwise).

The details plugin shows the fsck now in Trusty. (if booted with splash press Esc to see details or change/remove "splash" from default grub linux kernel args in /etc/default/grub) -> that's resolve bug #540645

The ubuntu-logo plugin has always shown fsck progress, as far as I can tell.

The ubuntu-text plugin does not still. -> separate bug #660151.

I'm marking this bug as duplicate of bug #540645.

Screenshot of the new behaviour is: https://plus.google.com/u/0/109160032876474505377/posts