6:47 p.m.
[ CC'ing and setting Reply-To to fedora-devel ]
On Sun, 2003-10-05 at 07:47, Jaap A. Haitsma wrote:
I've installed Severn including all the updates (except Mozilla
because
mozilla mail seems to freeze according to all the posts on this list
after updating) on my laptop (A Dell Latitude C600).
First thing I noticed that booting was a lot slower (I even thought the
init script was frozen). Then I changed the GRAPHICAL_BOOT variable in
/etc/syconfig/init to no. Booting time reduced from 2 minutes till 1 minute.
The problem seems to be the kudzu service, which probes for new devices.
If I disable the kudzu service a graphical boot takes also 1 minute.
Anybody experiencing the same thing?
The problem is likely that kudzu thinks your hardware has changed and
is patiently waiting on the other screen waiting you to press a key.
This will add 30 seconds to the boot time. Then by disabling kudzu
you gain another 8-10 seconds.
Jonathan and Bill are working on a fix for this; if kudzu wants to
interact with the user, a vte terminal will appear on the graphical
boot screen.
I did some timing of booting with and without rhgb this evening and
the conclusion is that rhgb slows the entire boot
(on a PIII-700 with a similar-era hard drive) by about 20 seconds,
from ~1:00 to ~1:20.
This slow down is virtually all in starting up rhgb ... from the
point where X takes control to the point where rhgb appears on the
screen is just about 20 seconds; likely this time is mostly spent
simply reading in libraries from disk, though there are some puzzling
factors:
- When booting up without rhgb, starting gdm (X => appears on screen)
takes around 10 seconds. But gdm uses all the libraries that
rhgb uses and more.
- gdm is no faster to start when rhgb has started before, even though
many of the libraries that gdm needs should already be in ram.
- Running rhgb from runlevel 3 "hot" takes about 4 seconds from
X => appears on screen.
- Running gdm from runlevel 3 "hot" takes about 5 seconds from
X => appears on screen.
Possible explanations of these facts that really don't convince me:
A) Many of the libraries used by rhgb and gdm are used by various
bits of the init process and are loaded parallelized with
other tasks between the point that rhgb starts and the point
that gdm starts. (This only makes sense if most of the load time for
rhgb was non-GUI libraries. Which I don't believe.)
B) One of the init steps that runs *after* we start rhgb speeds up
the system by a large factor. (What? /etc/sysconfig/harddisks
is run later but does nothing on this test system)
Next thing I want to do is to boot into runlevel 3 and see how long
rhgb takes to run cold there.
(Both A) and B) predict that it should take around 9-10 seconds, so it
can't distinguish between them. But if it takes much longer that would
tend to disprove both of them.)
Regards,
Owen
7:22 p.m.
New subject: Graphical boot issues: a.o. graphical boot twice slower then text boot!!!
On Tue, 2003-10-07 at 19:47, Owen Taylor wrote:
Possible explanations of these facts that really don't convince
me:
A) Many of the libraries used by rhgb and gdm are used by various
bits of the init process and are loaded parallelized with
other tasks between the point that rhgb starts and the point
that gdm starts. (This only makes sense if most of the load time for
rhgb was non-GUI libraries. Which I don't believe.)
B) One of the init steps that runs *after* we start rhgb speeds up
the system by a large factor. (What? /etc/sysconfig/harddisks
is run later but does nothing on this test system)
Next thing I want to do is to boot into runlevel 3 and see how long
rhgb takes to run cold there.
(Both A) and B) predict that it should take around 9-10 seconds, so it
can't distinguish between them. But if it takes much longer that would
tend to disprove both of them.)
Takes 8 seconds. Which is consistent with these theories and many
others.
So, I tried:
- Boot into runlevel 1. Run rhgb.
Run rhgb. 22 seconds from X => on screen
- Remove all network services and xfs from runlevel 3.
Run rhgb. 8 seconds from X => on screen
- Remove *all* services from runlevel 3 (syslog and all)
Run rhgb. 8 seconds from X => on screen
So, the evidence at this point is that with *more* services in
runlevel 1 then in runlevel 3, starting in runlevel 1 takes 10+
seconds extra.
In fact, I can use 'telinit' to switch between the two levels
and observe this.
So, now I need to figure out what is different between runlevel 1
and runlevel 3 other than the services running.
Regards,
Owen
9:19 p.m.
New subject: Graphical boot issues: a.o. graphical boot twice slower then text boot!!!
On Tue, 2003-10-07 at 20:22, Owen Taylor wrote:
So, I tried:
- Boot into runlevel 1. Run rhgb.
Run rhgb. 22 seconds from X => on screen
- Remove all network services and xfs from runlevel 3.
Run rhgb. 8 seconds from X => on screen
- Remove *all* services from runlevel 3 (syslog and all)
Run rhgb. 8 seconds from X => on screen
So, the evidence at this point is that with *more* services in
runlevel 1 then in runlevel 3, starting in runlevel 1 takes 10+
seconds extra.
In fact, I can use 'telinit' to switch between the two levels
and observe this.
So, now I need to figure out what is different between runlevel 1
and runlevel 3 other than the services running.
OK, tracked things down. Basically the xfs init script and
fc-cache are both making each other think that the font information
in fonts.dir and fonts.cache-1 files are out of date, so
all the users have to create their own fonts cache in
$HOME/.fonts-cache-1.
rhgb is getting run without $HOME set, so it can't even look
in /root/.fonts.cache-1.
I think we can fix up the xfs init script and address the problem;
should also make user logins work better, especially in
NFS homedir situations.
Regards,
Owen
8:34 a.m.
New subject: Graphical boot issues: a.o. graphical boot twice slower then text boot!!!
Owen Taylor <otaylor(a)redhat.com> writes:
Jonathan and Bill are working on a fix for this; if kudzu wants to
interact with the user, a vte terminal will appear on the graphical
boot screen.
This feature is now in version 0.10.2 in rawhide.
Thanks,
-Jonathan
3:31 p.m.
New subject: Graphical boot issues: a.o. graphical boot twice slower then text boot!!!
> Jonathan and Bill are working on a fix for this; if kudzu wants
to
> interact with the user, a vte terminal will appear on the graphical
> boot screen.
This feature is now in version 0.10.2 in rawhide.
What's the point of having a graphical boot process if kudzu is going to
interact with the user via VTE? Shouldn't some GTK+ frontend be written? Or
is the VTE thing just a temporary solution, and the long-term idea is to have a
proper frontend?
Peace out,
Derek
3:43 p.m.
New subject: Graphical boot issues: a.o. graphical boot twice slower then text boot!!!
Derek P. Moore (derek.moore(a)sbcglobal.net) said:
> This feature is now in version 0.10.2 in rawhide.
What's the point of having a graphical boot process if kudzu is going to
interact with the user via VTE? Shouldn't some GTK+ frontend be written? Or
is the VTE thing just a temporary solution, and the long-term idea is to have a
proper frontend?
Correct.
Bill
11:53 a.m.
New subject: Graphical boot issues: a.o. graphical boot twice slower then text boot!!!
The updates of today solved the initial problem I had that graphical
booting was much slower then text booting :-)
Furthermore it looks much nicer and there is a possibility to show
details. (Great work)
I still have to minor issues:
1. If I show details then after a while when the service keytable gets
loaded "[ OK ]" changes to "A OK U" (actually it are an A and an U
with
two dots on top, don't know how you call those letters in English)
2. Furthermore interactive startup now works :-). However I have to push
show details after I pushed the "I" otherwise it boots right trough.
Would be nice that it would flip automatically to detailed mode if you
pressed "I".
Jaap
2:41 p.m.
New subject: Graphical boot issues: a.o. graphical boot twice slower then text boot!!!
Jaap A. Haitsma (jaap_haitsma(a)zonnet.nl) said:
I still have to minor issues:
1. If I show details then after a while when the service keytable gets
loaded "[ OK ]" changes to "A OK U" (actually it are an A and an U
with
two dots on top, don't know how you call those letters in English)
Yup, just disable the keytable script. It probably needs to be
removed anyway (it's superfluous).
Bill
12:27 a.m.
New subject: Graphical boot issues: a.o. graphical boot twice slower then text boot!!!
On Thu, 9 Oct 2003, Bill Nottingham wrote:
Jaap A. Haitsma (jaap_haitsma(a)zonnet.nl) said:
> I still have to minor issues:
>
> 1. If I show details then after a while when the service keytable gets
> loaded "[ OK ]" changes to "A OK U" (actually it are an A and an
U with
> two dots on top, don't know how you call those letters in English)
Yup, just disable the keytable script. It probably needs to be
removed anyway (it's superfluous).
why is it superfluous?? I actually remap the del and backspace keys. Is there a
better way to do this??
--
......Tom Registered Linux User #14522 http://counter.li.org
tdiehl(a)rogueind.com My current SpamTrap -------> mtd123(a)rogueind.com
5:16 a.m.
New subject: Graphical boot issues: a.o. graphical boot twice slower then text boot!!!
On Mon, 13 Oct 2003, Tom Diehl wrote:
On Thu, 9 Oct 2003, Bill Nottingham wrote:
> Jaap A. Haitsma (jaap_haitsma(a)zonnet.nl) said:
> > I still have to minor issues:
> >
> > 1. If I show details then after a while when the service keytable gets
> > loaded "[ OK ]" changes to "A OK U" (actually it are an A
and an U with
> > two dots on top, don't know how you call those letters in English)
>
> Yup, just disable the keytable script. It probably needs to be
> removed anyway (it's superfluous).
So how is keyboard mapping going to be done in console?
why is it superfluous?? I actually remap the del and backspace keys.
Is there a
better way to do this??
behdad,
who is going to study after finishing this mail.
3:04 p.m.
New subject: Graphical boot issues: a.o. graphical boot twice slower then text boot!!!
Tom Diehl (tdiehl(a)rogueind.com) said:
> Yup, just disable the keytable script. It probably needs to be
> removed anyway (it's superfluous).
why is it superfluous?? I actually remap the del and backspace keys. Is there a
better way to do this??
keymaps are loaded in rc.sysinit already.
Bill
8:18 p.m.
New subject: Graphical boot issues: a.o. graphical boot twice slower then text boot!!!
On Mon, 13 Oct 2003, Bill Nottingham wrote:
Tom Diehl (tdiehl(a)rogueind.com) said:
> > Yup, just disable the keytable script. It probably needs to be
> > removed anyway (it's superfluous).
>
> why is it superfluous?? I actually remap the del and backspace keys. Is there a
> better way to do this??
keymaps are loaded in rc.sysinit already.
Now that you are talking about rc.sysinit, I recall that on my
laptop, I have just a few services to start, say less than five,
and most of the boot time is by rc.sysinit, I can hack
/etc/rc.d/rc to load services in parallel o some other thing, but
rc.sysinit is much harder to hack to load faster, so what's the
point in moving stuff there?
Bill
behdad,
11:11 p.m.
New subject: Graphical boot issues: a.o. graphical boot twice slower then text boot!!!
Behdad Esfahbod (behdad(a)cs.toronto.edu) said:
> keymaps are loaded in rc.sysinit already.
Now that you are talking about rc.sysinit, I recall that on my
laptop, I have just a few services to start, say less than five,
and most of the boot time is by rc.sysinit, I can hack
/etc/rc.d/rc to load services in parallel o some other thing, but
rc.sysinit is much harder to hack to load faster, so what's the
point in moving stuff there?
It makes more sense to have things associated with system
boot there, as opposed to presenting them as a 'service'.
There's nothing to prevent breaking up rc.sysinit into rcS.d
(or similar) and parallelizing it, though. It's a simple matter
of code. :)
Bill
12:21 a.m.
New subject: Graphical boot issues: a.o. graphical boot twice slower then text boot!!!
On Tue, 14 Oct 2003, Bill Nottingham wrote:
Behdad Esfahbod (behdad(a)cs.toronto.edu) said:
> > keymaps are loaded in rc.sysinit already.
>
> Now that you are talking about rc.sysinit, I recall that on my
> laptop, I have just a few services to start, say less than five,
> and most of the boot time is by rc.sysinit, I can hack
> /etc/rc.d/rc to load services in parallel o some other thing, but
> rc.sysinit is much harder to hack to load faster, so what's the
> point in moving stuff there?
It makes more sense to have things associated with system
boot there, as opposed to presenting them as a 'service'.
Makes sense.
There's nothing to prevent breaking up rc.sysinit into rcS.d
(or similar) and parallelizing it, though. It's a simple matter
of code. :)
Thanks for the idea. It makes it manageable too. When's the
current initscripts schema going change? From the traffic here
about MessageBus and other things, seems that it would be a major
switch in some step. If it's not for FC2, hacking the current rc
stuff seems reasonable.
Bill
behdad,
who is going to study after finishing this mail.
2:03 a.m.
New subject: Graphical boot issues: a.o. graphical boot twice slower then text boot!!!
Le mar 14/10/2003 à 03:18, Behdad Esfahbod a écrit :
On Mon, 13 Oct 2003, Bill Nottingham wrote:
> Tom Diehl (tdiehl(a)rogueind.com) said:
> > > Yup, just disable the keytable script. It probably needs to be
> > > removed anyway (it's superfluous).
> >
> > why is it superfluous?? I actually remap the del and backspace keys. Is there
a
> > better way to do this??
>
> keymaps are loaded in rc.sysinit already.
Then would changing the default keyboard now translate in "please reboot
now ?" I hope not.
--
Nicolas Mailhot
8:52 a.m.
New subject: Graphical boot issues: a.o. graphical boot twice slower then text boot!!!
Nicolas Mailhot (Nicolas.Mailhot(a)laPoste.net) said:
> > keymaps are loaded in rc.sysinit already.
Then would changing the default keyboard now translate in "please reboot
now ?" I hope not.
I'm not sure I understand your question - could you rephrase?
Bill
9:01 a.m.
New subject: Graphical boot issues: a.o. graphical boot twice slower then text boot!!!
Bill Nottingham wrote:
Nicolas Mailhot (Nicolas.Mailhot(a)laPoste.net) said:
>>>keymaps are loaded in rc.sysinit already.
>
>Then would changing the default keyboard now translate in "please reboot
>now ?" I hope not.
I'm not sure I understand your question - could you rephrase?
Instead of "service keytable reload" you now need to re-run rc.sysinit.
Is it safe to run rc.sysinit at runlevel 3 or 5?
-Thomas
9:11 a.m.
New subject: Graphical boot issues: a.o. graphical boot twice slower then text boot!!!
Thomas Dodd (ted(a)cypress.com) said:
> I'm not sure I understand your question - could you
rephrase?
Instead of "service keytable reload" you now need to re-run rc.sysinit.
Is it safe to run rc.sysinit at runlevel 3 or 5?
No.
How often do you need to reload the keytable? Note that to do it
by hand is just:
loadkeys $KEYTABLE.map
Bill
9:22 a.m.
New subject: Graphical boot issues: a.o. graphical boot twice slower then text boot!!!
Le mar 14/10/2003 à 16:11, Bill Nottingham a écrit :
Thomas Dodd (ted(a)cypress.com) said:
> > I'm not sure I understand your question - could you rephrase?
>
> Instead of "service keytable reload" you now need to re-run rc.sysinit.
> Is it safe to run rc.sysinit at runlevel 3 or 5?
No.
How often do you need to reload the keytable? Note that to do it
by hand is just:
loadkeys $KEYTABLE.map
Last I looked the script did more than this.
And yes when you change this you rarely get it working at once, so
having a foolproof script did help a lot.
Cheers,
--
Nicolas Mailhot
9:36 a.m.
New subject: Graphical boot issues: a.o. graphical boot twice slower then text boot!!!
Nicolas Mailhot (Nicolas.Mailhot(a)laPoste.net) said:
> How often do you need to reload the keytable? Note that to do
it
> by hand is just:
>
> loadkeys $KEYTABLE.map
Last I looked the script did more than this.
Actually, yes, but the only other thing is calling setsysfont
(with no arguments).
Bill
9:55 a.m.
New subject: Graphical boot issues: a.o. graphical boot twice slower then text boot!!!
Le mar 14/10/2003 à 16:36, Bill Nottingham a écrit :
Nicolas Mailhot (Nicolas.Mailhot(a)laPoste.net) said:
> > How often do you need to reload the keytable? Note that to do it
> > by hand is just:
> >
> > loadkeys $KEYTABLE.map
>
> Last I looked the script did more than this.
Actually, yes, but the only other thing is calling setsysfont
(with no arguments).
Which I'd have probably never thought about myself at the time...
keytable was just damn convenient, a big monolithic script isn't.
Cheers,
--
Nicolas Mailhot
9:14 a.m.
New subject: Graphical boot issues: a.o. graphical boot twice slower then text boot!!!
Le mar 14/10/2003 à 15:52, Bill Nottingham a écrit :
Nicolas Mailhot (Nicolas.Mailhot(a)laPoste.net) said:
> > > keymaps are loaded in rc.sysinit already.
>
> Then would changing the default keyboard now translate in "please reboot
> now ?" I hope not.
I'm not sure I understand your question - could you rephrase?
Last time I had to tweak my keyboard I validated the changes with
/etc/init.d/key* restart. And now you remove this script. So I'm a bit
worried - what will happen next time I need to fiddle with it ?
Cheers,
--
Nicolas Mailhot
10:41 a.m.
New subject: Graphical boot issues: a.o. graphical boot twice slower then text boot!!!
On Tue, 14 Oct 2003, Nicolas Mailhot wrote:
Le mar 14/10/2003 à 15:52, Bill Nottingham a écrit :
> Nicolas Mailhot (Nicolas.Mailhot(a)laPoste.net) said:
> > > > keymaps are loaded in rc.sysinit already.
> >
> > Then would changing the default keyboard now translate in "please reboot
> > now ?" I hope not.
>
> I'm not sure I understand your question - could you rephrase?
Last time I had to tweak my keyboard I validated the changes with
/etc/init.d/key* restart. And now you remove this script. So I'm a bit
worried - what will happen next time I need to fiddle with it ?
As Bill said in a previous post "loadkeys $KEYTABLE.map" That is for
all practical purposes the same thing. Remember TIMTOWTDI!! :-)
--
......Tom Registered Linux User #14522 http://counter.li.org
tdiehl(a)rogueind.com My current SpamTrap -------> mtd123(a)rogueind.com
3:51 p.m.
New subject: Graphical boot issues: a.o. graphical boot twice slower then text boot!!!
Tom Diehl wrote:
...
>Last time I had to tweak my keyboard I validated the changes with
>/etc/init.d/key* restart. And now you remove this script. So I'm a bit
>worried - what will happen next time I need to fiddle with it ?
As Bill said in a previous post "loadkeys $KEYTABLE.map" That is for
all practical purposes the same thing. Remember TIMTOWTDI!! :-)
That might be a good motto for Perl, but it's a very *bad* motto for
starting services on a box...
--
Paul
http://paulgear.webhop.net
A: Because we read from top to bottom, left to right.
Q: Why should i start my reply below the quoted text?
7517
days inactive
7524
days old
24 comments
10 participants
participants (10)
-
Behdad Esfahbod -
Bill Nottingham -
Derek P. Moore -
Jaap A. Haitsma -
Jonathan Blandford -
Nicolas Mailhot -
Owen Taylor -
Paul Gear -
Thomas Dodd -
Tom Diehl