Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 233267 - media-gfx/splashutils: fsck vs bootsplash
Summary: media-gfx/splashutils: fsck vs bootsplash
Status: RESOLVED OBSOLETE
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Unspecified (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: No maintainer - Look at https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers if you want to take care of it
URL:
Whiteboard: Pending removal: 2018-11-21
Keywords: NeedPatch, PMASKED
Depends on:
Blocks:
 
Reported: 2008-07-29 12:55 UTC by Imre Péntek
Modified: 2018-11-28 13:19 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Imre Péntek 2008-07-29 12:55:27 UTC
fsck status should be displayed on the bootsplash. At current state, current bootsplash leaves the user with no idea about what's happening. Some minutes later the user would press 'F2' to find out what is going on. Currently when checking rootfs there are no display about that, when checking anything else, only a little glyph shows it, it would be great to add a percentage indicator in both cases, also something informative in the case of rootfs.

Reproducible: Always
Comment 1 Carsten Lohrke (RETIRED) gentoo-dev 2008-07-29 13:10:59 UTC
> At current state, current bootsplash leaves the user with no idea about what's happening.

And /me thought this is the whole point about a boot splash - not to provide/irritate joe user with boot messages.
Comment 2 Imre Péntek 2008-07-29 13:22:18 UTC
there's point in not irritating user with details, but maybe there's a chance all users wants to know why booting takes much longer now than yesterday. It wouldn't be irritating to have the same glyph when checking rootfs, also a little progress bar wouldn't irritate the user. For me, not knowig why my system boots that slow is more irritating than seeing that glyph and maybe a little progress bar.

That way, average joe would have a chance to take a coffe break as it sees instantly that this boot will take that much longer, otherwise he would assume it somehow would take only 10 secs longer... 10 more secs longer... 10 more secs longer... 10 more secs longer... and so on, F2, 97%, now there's no time for a coffe now...
Comment 3 Michal Januszewski (RETIRED) gentoo-dev 2008-09-07 20:23:42 UTC
First of all, whether any additional indicator is displayed is and has to be theme-specific.  If you're using e.g. the gentoo-livecd-2007.0 theme, you aren't left completely in the dark, since you see a fsck icon and some text (like "Starting fsck...").  If you're using a theme with supports the fbsplash message log, you can press F3 to see a semi-verbose text window which will tell you which services are starting and which have already been started.

That being said, I'll see how complex implementing a progress bar for fsck in fbsplash would be.
Comment 4 Imre Péntek 2008-09-08 06:54:09 UTC
gentoo-livecd-2007.0 doesn't display fsck icon (nor even any text), when fscking the rootfs.
Comment 5 Michal Januszewski (RETIRED) gentoo-dev 2008-09-08 09:03:29 UTC
(In reply to comment #4)
> gentoo-livecd-2007.0 doesn't display fsck icon (nor even any text), when
> fscking the rootfs.

Which version of baselayout are you using?

Comment 6 Roy Marples 2008-10-03 19:54:54 UTC
(In reply to comment #3)
> That being said, I'll see how complex implementing a progress bar for fsck in
> fbsplash would be.

I think we'll need some kind of generic framework here - although it's likely only fsck would need a secondary progress bar on the splash we cannot rule out another service wanting one.

fsck -C 0 | splash_service_progress

Is the best I can come up with in my head. splash_service_progress opens a socket to the splash daemon and passes stdin to it. If it cannot open the socket to the splash daemon then it simple echos to stdout.
Comment 7 Michal Januszewski (RETIRED) gentoo-dev 2008-10-04 19:27:22 UTC
(In reply to comment #6)

> I think we'll need some kind of generic framework here - although it's likely
> only fsck would need a secondary progress bar on the splash we cannot rule out
> another service wanting one.

Agreed.
 
> fsck -C 0 | splash_service_progress
> 
> Is the best I can come up with in my head. splash_service_progress opens a
> socket to the splash daemon and passes stdin to it. If it cannot open the
> socket to the splash daemon then it simple echos to stdout.

This could work, but there are at least two problems:

- it won't work unless using the non-interactive mode:
  # fsck.ext3 -C 0 /dev/sdb2 | splash_service_progress
  e2fsck 1.41.2 (02-Oct-2008)
  e2fsck: need terminal for interactive repairs

- it hides any diagnostic messages that might be displayed by fsck.

An alternative would be:

eval "exec 3> >(splash_service_progress fsck)"
fsck -C 3 ...

splash_service_progress would be a simple function taking a single argument (to decide what kind of input it is processing) and reading from stdin, converting the progress data into some universal format defined by splashutils and doing a splash_comm_send if available.

Comment 8 Roy Marples 2008-10-16 07:40:58 UTC
(In reply to comment #7)
> An alternative would be:
> 
> eval "exec 3> >(splash_service_progress fsck)"
> fsck -C 3 ...

That won't fly as it's bash only (process substitution)
How about this?

splash_service_progress -- fsck -C \$SPLASH_PROGRESS_FD

splash_service_progress opens an fd, sets the env var SPLASH_PROGRESS_FD to it and then calls the program.
Comment 9 Michal Januszewski (RETIRED) gentoo-dev 2008-10-18 18:15:59 UTC
(In reply to comment #8)
> > eval "exec 3> >(splash_service_progress fsck)"
> > fsck -C 3 ...
> 
> That won't fly as it's bash only (process substitution)
> How about this?
> 
> splash_service_progress -- fsck -C \$SPLASH_PROGRESS_FD
> 
> splash_service_progress opens an fd, sets the env var SPLASH_PROGRESS_FD to it
> and then calls the program.

That should work.  But, in order to avoid bashisms anywhere, splash_service_progress would have to be a binary provided by splashutils, right?  Also, the fsck script would have to check if this binary is present and execute fsck the standard way if it's not.
Comment 10 Roy Marples 2008-10-26 19:46:47 UTC
(In reply to comment #9)
> That should work.  But, in order to avoid bashisms anywhere,
> splash_service_progress would have to be a binary provided by splashutils,
> right?  Also, the fsck script would have to check if this binary is present and
> execute fsck the standard way if it's not.

Which makes it an argument for splash_service_progress to be supplied by OpenRC which in turn calls the right splash helper. As OpenRC also supplied the fsck script we shouldn't need to actively test for its existance either.

splash_service_progress could load all OpenRC plugins and see if they have a service progress fd to write to.
Comment 11 Michal Januszewski (RETIRED) gentoo-dev 2008-10-31 14:36:11 UTC
> Which makes it an argument for splash_service_progress to be supplied by OpenRC
> which in turn calls the right splash helper. As OpenRC also supplied the fsck
> script we shouldn't need to actively test for its existance either.

OK, sounds good.

> splash_service_progress could load all OpenRC plugins and see if they have a
> service progress fd to write to.

I think we need more than just a fd, in order to be able to handle more than
one progress source.  The point would be to:
- avoid intermixing progress data from different sources being piped into a single fd,
- make it possible to translate different progress formats to a common format recognized by the splash subsystem.

Instead of a fd, we could have a function, say int splash_progress(char *svc_name).  The function would take the name of the initscript and open 
an appropriate fd.   In practice, it would probably spawn a subprocess 
which would read the data from a pipe, translate it to a common format
and send it to the splash daemon.
Comment 12 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2018-11-28 13:19:55 UTC
Package removed.