Bootup speed for F8

[Dimi Paun]

Hi folks,

I've currently upgraded to F8, congrats!

Just thought of sharing a data-point for startup speed
(measured from GRUB, so excluding all the BIOS stuff):
  * to graphical init: 30s
  * to login prompt: 1m8s
  * after login, to responsive state: 14s

That's 1m22s to start. On a good desktop: Intel Duo 2.13GHz, 2GB RAM.
With the BIOS thrown in, it takes over 2minutes to be able to get
into the box.

That's rather slow, no?

-- 
Dimi Paun <dimi(a)lattica.com&gt;
Lattica, Inc.

[Gary Thomas]

Dimi Paun wrote:
>  Hi folks,
>  
>  I've currently upgraded to F8, congrats!
>  
>  Just thought of sharing a data-point for startup speed
>  (measured from GRUB, so excluding all the BIOS stuff):
>    * to graphical init: 30s
>    * to login prompt: 1m8s
>    * after login, to responsive state: 14s
>  
>  That's 1m22s to start. On a good desktop: Intel Duo 2.13GHz, 2GB RAM.
>  With the BIOS thrown in, it takes over 2minutes to be able to get
>  into the box.
>  
>  That's rather slow, no?
>   
Try upgrading to the latest kernel and remeasure.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

[Eric Sandeen]

Dimi Paun wrote:
>  Hi folks,
>  
>  I've currently upgraded to F8, congrats!
>  
>  Just thought of sharing a data-point for startup speed
>  (measured from GRUB, so excluding all the BIOS stuff):
>    * to graphical init: 30s
>    * to login prompt: 1m8s
>    * after login, to responsive state: 14s
>  
>  That's 1m22s to start. On a good desktop: Intel Duo 2.13GHz, 2GB RAM.
>  With the BIOS thrown in, it takes over 2minutes to be able to get
>  into the box.
>  
>  That's rather slow, no?
>   
Readahead was not installed by default in F8 because it appeared to be
doing more harm than good, without careful custom configuration.  But,
you could try installing the readahead scripts, and see if it changes
things.

Or, if you already have readahead installed due to the upgrade,
chkconfig it off and see how that goes.  :)

-Eric

[Kulbir Saini]

On Thu, 29 Nov 2007, Eric Sandeen wrote:

>  Dimi Paun wrote:
> > Hi folks,
> >
> > I've currently upgraded to F8, congrats!
> >
> > Just thought of sharing a data-point for startup speed
> > (measured from GRUB, so excluding all the BIOS stuff):
> >   * to graphical init: 30s
> >   * to login prompt: 1m8s
> >   * after login, to responsive state: 14s
> >
> > That's 1m22s to start. On a good desktop: Intel Duo 2.13GHz, 2GB RAM.
> > With the BIOS thrown in, it takes over 2minutes to be able to get
> > into the box.
> >
> > That's rather slow, no?
> > 
    Try disabling service that you think you'll never use. Also don't start 
network (and yum-updatesd also) at startup and delay it by putting 
'service network start &' in /etc/rc.local. Because you can't use network

unless you login.

    My Fedora 8 takes 50seconds from Grub to login screen (I mean time from 
pressing enter in grub screen to the time when login screen appears and i 
can login) on AMD64 3000+ (solo core) and 1GB RAM :)


-------------------------------------------------------
Thank you,
Kulbir Saini,
Computer Science and Engineering,
International Institute of Information Technology,
Hyderbad, India - 500032.

My Home-Page: http://saini.co.in/
My Institute: http://www.iiit.ac.in/
My Linux-Blog: http://linux.saini.co.in/
My Web-Blog: http://life.saini.co.in/
-------------------------------------------------------

[Mark]

Here is my bootchart [1]. It's was with the normal fedora setup but
with apache and mysql added.

In my bootchart i see something i rather don't see.. about 7 seconds
nothing in the begin. and the overall speed seems about half of what
could be reached... so if that was optimized:

50 sec - 7 (pure nothing) = 43 seconds.
43 / 2 (it it would use the max in reads and cpu) = 21.5 seconds which
is a decent boot time.

If that's ever gonna happen (don't think so in the near future) than
you still have to add about 10 seconds in the begin (bios, grub and
kernel boot) and about another 10 seconds for gnome to be completely
loaded.

Total time at this moment:
70 seconds

If it was optimized it could be:
42.5 seconds (but that's under perfect conditions)

2007/11/30, Kulbir Saini <kulbirsaini(a)students.iiit.ac.in&gt;:
>  On Thu, 29 Nov 2007, Eric Sandeen wrote:
>
>  > Dimi Paun wrote:
>  >> Hi folks,
>  >>
>  >> I've currently upgraded to F8, congrats!
>  >>
>  >> Just thought of sharing a data-point for startup speed
>  >> (measured from GRUB, so excluding all the BIOS stuff):
>  >>   * to graphical init: 30s
>  >>   * to login prompt: 1m8s
>  >>   * after login, to responsive state: 14s
>  >>
>  >> That's 1m22s to start. On a good desktop: Intel Duo 2.13GHz, 2GB RAM.
>  >> With the BIOS thrown in, it takes over 2minutes to be able to get
>  >> into the box.
>  >>
>  >> That's rather slow, no?
>  >>
>
>      Try disabling service that you think you'll never use. Also don't start
>  network (and yum-updatesd also) at startup and delay it by putting
>  'service network start &' in /etc/rc.local. Because you can't use
> network
>  unless you login.
>
>      My Fedora 8 takes 50seconds from Grub to login screen (I mean time from
>  pressing enter in grub screen to the time when login screen appears and i
>  can login) on AMD64 3000+ (solo core) and 1GB RAM :)
>
>
>  -------------------------------------------------------
>  Thank you,
>  Kulbir Saini,
>  Computer Science and Engineering,
>  International Institute of Information Technology,
>  Hyderbad, India - 500032.
>
>  My Home-Page: http://saini.co.in/
>  My Institute: http://www.iiit.ac.in/
>  My Linux-Blog: http://linux.saini.co.in/
>  My Web-Blog: http://life.saini.co.in/
>  -------------------------------------------------------
>
>
>  --
>  fedora-devel-list mailing list
>  fedora-devel-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

[Mark]

2007/11/30, Mark <markg85(a)gmail.com&gt;:
>  Here is my bootchart [1]. It's was with the normal fedora setup
> but
>  with apache and mysql added. 
And here is the image (pressed "send" to fast):
[1] http://img530.imageshack.us/img530/6483/bootchartsw0.png

[Bill Nottingham]

Mark (markg85(a)gmail.com) said: 
>  Here is my bootchart [1]. It's was with the normal fedora setup
> but
>  with apache and mysql added.
>  
>  In my bootchart i see something i rather don't see.. about 7 seconds
>  nothing in the begin. and the overall speed seems about half of what
>  could be reached... so if that was optimized:
>  
>  50 sec - 7 (pure nothing) = 43 seconds. 
So, that seven seconds could be two things:

1) bootchart weirdness (as it's from when bootchart starts)
2) hotplug issues with a driver in the initrd not initializing right

Beyond that, the two big gaps I see are when X starts - we're working
on helping fix this.

Bill

[Adam Jackson]

On Fri, 2007-11-30 at 11:18 -0500, Bill Nottingham wrote:
>  Mark (markg85(a)gmail.com) said: 
>  > Here is my bootchart [1]. It's was with the normal fedora setup but
>  > with apache and mysql added.
>  > 
>  > In my bootchart i see something i rather don't see.. about 7 seconds
>  > nothing in the begin. and the overall speed seems about half of what
>  > could be reached... so if that was optimized:
>  > 
>  > 50 sec - 7 (pure nothing) = 43 seconds.
>  
>  So, that seven seconds could be two things:
>  
>  1) bootchart weirdness (as it's from when bootchart starts)
>  2) hotplug issues with a driver in the initrd not initializing right
>  
>  Beyond that, the two big gaps I see are when X starts - we're working
>  on helping fix this. 
I hit most of the low-hanging fruit for X startup performance already in
rawhide.  The rest is... harder.

- ajax

[Bernie Innocenti]

Adam Jackson wrote:

>  I hit most of the low-hanging fruit for X startup performance already
> in
>  rawhide.  The rest is... harder. 
What did you actually do?

We'd also like to reduce boot time and possibly move X early
in the startup process.

-- 
 \___/
 |___|   Bernardo Innocenti - http://www.codewiz.org/
  \___\  One Laptop Per Child - http://www.laptop.org/

[Adam Jackson]

On Fri, 2007-11-30 at 19:02 -0500, Bernardo Innocenti wrote:
>  Adam Jackson wrote:
>  > I hit most of the low-hanging fruit for X startup performance already in
>  > rawhide.  The rest is... harder.
>  
>  What did you actually do? 
http://cgit.freedesktop.org/xorg/xserver/commit/?id=f01e149d1af14ef9ee0e8...
http://cgit.freedesktop.org/xorg/xserver/commit/?id=22f0e3a8b04e574047a51...
http://cgit.freedesktop.org/xorg/xserver/commit/?id=cecac794451b793871f29...
http://cgit.freedesktop.org/xorg/driver/xf86-input-keyboard/commit/?id=b1...
http://cgit.freedesktop.org/xorg/driver/xf86-input-mouse/commit/?id=76a22...

I haven't looked at evdev yet, I'm sure there's disasters there too.

- ajax

[Bernie Innocenti]

Adam Jackson wrote:

>  I haven't looked at evdev yet, I'm sure there's disasters
> there too. 
I had a look, and I'm still recovering :-)

-- 
 \___/
 |___|   Bernardo Innocenti - http://www.codewiz.org/
  \___\  One Laptop Per Child - http://www.laptop.org/

[Dimi Paun]

On Fri, 2007-11-30 at 11:18 -0500, Bill Nottingham wrote:
>  1) bootchart weirdness (as it's from when bootchart starts)
>  2) hotplug issues with a driver in the initrd not initializing right 
Well, maybe, but I think it's a common problem:
    http://lattica.com/pub/bootchart-20071130-f8.png

In my case, that initial time is close to 11s! And mind
you, it's no bootchard weirdness, I've always noticed it.

Wall time for the above boot sequence is:
  * GRUB -> X:       25s
  * X -> login:      40s
  * login -> usable: 20s

That's almost 1.5 minutes, with all the user interaction
removed.

-- 
Dimi Paun <dimi(a)lattica.com&gt;
Lattica, Inc.

[Jesse Barnes]

On Friday, November 30, 2007 6:06 pm Dimi Paun wrote:
>  On Fri, 2007-11-30 at 11:18 -0500, Bill Nottingham wrote:
>  > 1) bootchart weirdness (as it's from when bootchart starts)
>  > 2) hotplug issues with a driver in the initrd not initializing
>  > right
>
>  Well, maybe, but I think it's a common problem:
>      http://lattica.com/pub/bootchart-20071130-f8.png
>
>  In my case, that initial time is close to 11s! And mind
>  you, it's no bootchard weirdness, I've always noticed it. 
Yeah, I'm seeing the same thing, ~10s on one machine and ~15s on 
another.  I briefly looked at the nash scripts and hotplug code in the 
initrd.  It looks like we spend a lot of time waiting for the kernel to 
generate hotplug events and settle down the devices... I'm not sure how 
much of it could reasonably be trimmed, maybe comparing to a non-initrd 
config would make sense?  I think this is pjones' stuff, so there are 
probably good reasons for the way things are.

Jesse

[David Zeuthen]

On Fri, 2007-11-30 at 21:50 -0800, Jesse Barnes wrote:
>  On Friday, November 30, 2007 6:06 pm Dimi Paun wrote:
>  > On Fri, 2007-11-30 at 11:18 -0500, Bill Nottingham wrote:
>  > > 1) bootchart weirdness (as it's from when bootchart starts)
>  > > 2) hotplug issues with a driver in the initrd not initializing
>  > > right
>  >
>  > Well, maybe, but I think it's a common problem:
>  >     http://lattica.com/pub/bootchart-20071130-f8.png
>  >
>  > In my case, that initial time is close to 11s! And mind
>  > you, it's no bootchard weirdness, I've always noticed it.
>  
>  Yeah, I'm seeing the same thing, ~10s on one machine and ~15s on 
>  another.  I briefly looked at the nash scripts and hotplug code in the 
>  initrd.  It looks like we spend a lot of time waiting for the kernel to 
>  generate hotplug events and settle down the devices... I'm not sure how 
>  much of it could reasonably be trimmed, maybe comparing to a non-initrd 
>  config would make sense?  I think this is pjones' stuff, so there are 
>  probably good reasons for the way things are. 
In the perfect world (and on 99% of the other distros), the initramfs
can exit to real user space as soon as the root device is mounted.

I know that on Fedora (at least in the past) we play some really ugly
tricks to make sure that the kernel names (e.g. sda, sdb etc.) for the
devices are in a specific order (scsi_wait_scan.ko etc.). Seems
literally like a waste of time; better fix the rest of the OS not to
rely on things like kernel names.

Then again, I haven't looked at this for some time... It would be
interesting to compare to other distros like SUSE, Debian and Ubuntu to
see how much slower or faster we are.

       David

[Mark]

Here is my bootchart from initng [1]
with the note that NetworkManager doesn't want to start and sound is
out of the question as well.

Those first 8 seconds are exactly the same in initd [2] as they are in
initng. With initd it isn't much of an issue because it's slow already
and ust doesn't mather much. with initng it's nearly HALF of the boot
time!! now it's gonna something that would be nice to get fixed.

About looking in scripts in initrd.. how do you do that? is there a
guide for it somewhere? or is this [3] still good for it?

[1] http://img252.imageshack.us/img252/2538/bootchartpx1.png
[2] http://img530.imageshack.us/img530/6483/bootchartsw0.png
[3] http://www.mail-archive.com/[e-mail]/msg0444...

2007/12/1, David Zeuthen <david(a)fubar.dk&gt;:
>  On Fri, 2007-11-30 at 21:50 -0800, Jesse Barnes wrote:
>  > On Friday, November 30, 2007 6:06 pm Dimi Paun wrote:
>  > > On Fri, 2007-11-30 at 11:18 -0500, Bill Nottingham wrote:
>  > > > 1) bootchart weirdness (as it's from when bootchart starts)
>  > > > 2) hotplug issues with a driver in the initrd not initializing
>  > > > right
>  > >
>  > > Well, maybe, but I think it's a common problem:
>  > >     http://lattica.com/pub/bootchart-20071130-f8.png
>  > >
>  > > In my case, that initial time is close to 11s! And mind
>  > > you, it's no bootchard weirdness, I've always noticed it.
>  >
>  > Yeah, I'm seeing the same thing, ~10s on one machine and ~15s on
>  > another.  I briefly looked at the nash scripts and hotplug code in the
>  > initrd.  It looks like we spend a lot of time waiting for the kernel to
>  > generate hotplug events and settle down the devices... I'm not sure how
>  > much of it could reasonably be trimmed, maybe comparing to a non-initrd
>  > config would make sense?  I think this is pjones' stuff, so there are
>  > probably good reasons for the way things are.
>
>  In the perfect world (and on 99% of the other distros), the initramfs
>  can exit to real user space as soon as the root device is mounted.
>
>  I know that on Fedora (at least in the past) we play some really ugly
>  tricks to make sure that the kernel names (e.g. sda, sdb etc.) for the
>  devices are in a specific order (scsi_wait_scan.ko etc.). Seems
>  literally like a waste of time; better fix the rest of the OS not to
>  rely on things like kernel names.
>
>  Then again, I haven't looked at this for some time... It would be
>  interesting to compare to other distros like SUSE, Debian and Ubuntu to
>  see how much slower or faster we are.
>
>         David
>
>
>  --
>  fedora-devel-list mailing list
>  fedora-devel-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

[Mark]

2007/12/1, Mark <markg85(a)gmail.com&gt;:
>  About looking in scripts in initrd.. how do you do that? is there a
>  guide for it somewhere? or is this [3] still good for it? 
reply to myself..
i just found this link [1]. seems to be oke for me.
i have the boot at about 20 seconds now.
the loading of the kernel modules seems to take up most time.. perhaps
it's better if those default kernel modules got compiled in? And there
was indeed a scsi_wait module in the init script. i kicked it out and
it gave me a (about) 2 second boot boost. My new bootchart: [2].

[1] http://bbs.archlinux.org/viewtopic.php?pid=282849#p282849
[2] http://img401.imageshack.us/img401/6272/bootchartsnel20secql1.png
(20 seconds)

[Jesse Barnes]

On Saturday, December 01, 2007 5:02 am Mark wrote:
>  Here is my bootchart from initng [1]
>  with the note that NetworkManager doesn't want to start and sound is
>  out of the question as well.
>
>  Those first 8 seconds are exactly the same in initd [2] as they are
>  in initng. With initd it isn't much of an issue because it's slow
>  already and ust doesn't mather much. with initng it's nearly HALF of
>  the boot time!! now it's gonna something that would be nice to get
>  fixed.
>
>  About looking in scripts in initrd.. how do you do that? is there a
>  guide for it somewhere? or is this [3] still good for it? 
Nice... initng does seem like a nice project and a conceptual 
improvement over what we currently have.

And yeah, I just pulled apart the initrd to poke around, and also 
downloaded the mkinitrd package so I could look at the nash and other 
sources.

Jesse

[Mark]

2007/12/1, Jesse Barnes <jbarnes(a)virtuousgeek.org&gt;:
>  On Saturday, December 01, 2007 5:02 am Mark wrote:
>  > Here is my bootchart from initng [1]
>  > with the note that NetworkManager doesn't want to start and sound is
>  > out of the question as well.
>  >
>  > Those first 8 seconds are exactly the same in initd [2] as they are
>  > in initng. With initd it isn't much of an issue because it's slow
>  > already and ust doesn't mather much. with initng it's nearly HALF of
>  > the boot time!! now it's gonna something that would be nice to get
>  > fixed.
>  >
>  > About looking in scripts in initrd.. how do you do that? is there a
>  > guide for it somewhere? or is this [3] still good for it?
>
>  Nice... initng does seem like a nice project and a conceptual
>  improvement over what we currently have.
>
>  And yeah, I just pulled apart the initrd to poke around, and also
>  downloaded the mkinitrd package so I could look at the nash and other
>  sources.
>
>  Jesse 
i (sadly) don't think there is a lot to you can speed up in the
initrd->init script.. it's all loading modules and
initializing/mounting the partitions... speeding it up means excluding
modules or removing them completely and compile them in the kernel
(which would be better for the default modules like lvm, sata and
pata)

LinuxBIOS would give some seconds speed boost.. but that's not really
a solution that is possible for anyone.

btw.. it would be nice if bootchart could run before nash.. and right
after grub.. Thosefirst few seconds in bootchart (about 7 in my case
now) seem to be waste but seem to be RedHat Nash running...

[Dave Jones]

On Sat, Dec 01, 2007 at 01:23:09AM -0500, David Zeuthen wrote:
 
>  I know that on Fedora (at least in the past) we play some really
> ugly
>  tricks to make sure that the kernel names (e.g. sda, sdb etc.) for the
>  devices are in a specific order (scsi_wait_scan.ko etc.). Seems
>  literally like a waste of time; better fix the rest of the OS not to
>  rely on things like kernel names. 
We scsi_wait_scan for the root disk to come up.  We don't enforce any
kind of ordering. 

	Dave

-- 
http://www.codemonkey.org.uk

[David Zeuthen]

On Sat, 2007-12-01 at 21:52 -0500, Dave Jones wrote:
>  On Sat, Dec 01, 2007 at 01:23:09AM -0500, David Zeuthen wrote:
>   
>   > I know that on Fedora (at least in the past) we play some really ugly
>   > tricks to make sure that the kernel names (e.g. sda, sdb etc.) for the
>   > devices are in a specific order (scsi_wait_scan.ko etc.). Seems
>   > literally like a waste of time; better fix the rest of the OS not to
>   > rely on things like kernel names.
>  
>  We scsi_wait_scan for the root disk to come up.   
Uhm no.

First, you hardly have to use a kernel module to wait for a device to
appear; come one, this is uevent 101: a single udev rule that
investigates the block device and exits the initramfs if it's indeed the
root fs will suffice. Or, if you want to rewrite all of udev like Peter
has done, just hook into the uevent event processing yourself.

Second, the point of scsi_wait_scan.ko is to make the SCSI stack wait
for all scans to have finished before uevents are generated. A side
effect of this is that the order is deterministic; e.g. since events are
only generated when all devices have been detected, one can send them in
order.

>  We don't enforce any kind of ordering.  
Reality also suggest otherwise. Just try an old livecd image (F8t3 will
do I think) using an initramfs from mayflower (using udev; waiting only
for the rootfs)  vs. a newer one using an initramfs from mkinitrd. In
the former the devices are randomly assigned; in the latter they're
not... 

As an anecdote, the former freaked Anaconda out as I wanted to install
to /dev/sdf (the hard disk in my box; /dev/sda through /dev/sde was my
disk tower). Which again confirms we do stupid things in the initramfs
because user space is just utterly broken.

In conclusion: scsi_wait_scan.ko is a stupid stopgap fix because some
people can't be bothered to fix their user space. Fedora is an example
of that. The price that we all pay is that it takes longer to boot for
_everyone_.

There's a host of other problems with mkinitrd that I won't go into
here.

      David

ata and scsi modules in initrd (was: Re: Bootup speed for F8)

[Thorsten Leemhuis]

On 02.12.2007 12:31, David Zeuthen wrote:
>  There's a host of other problems with mkinitrd that I won't go into
>  here. 
There is something about mkinitrd I'd like to bring up while we're
discussing its problems here.

Fedora afaics normally has a "hardware should just work" approach (which
is a good thing). But why do we have only the modules in the initrd
which are strictly needed on the system where the initrd was created?
Shouldn't we put the most important ones into the inird and load them on
demand if the root-fs could not be found with the default module?

Sure, with the current approach the initrd is small. But if you take the
harddisk and connect it to another storage controller or an motherboard
with a different chipset vendor then in most cases Fedora won't boot
there (ahci will hopefully solve that sooner or later, but that's a
different topic).

Heck, it's even worse: on those popular Intel chipsets (ICH5 and later)
you can configure the integrated storage controller in different ways
through the BIOS Setup. As you need different drivers depending on the
settings you might run into situations like this sometimes:

* you get your new computer where somebody enabled ahci in the BIOS
Setup for you
* you install F8 during which an initrd with the ahci module gets created
* you have problems with the system and do a BIOS update (during which
its settings from the BIOS Setup normally get reseted; thus ahci is off
again and the storage controller gets a different PCI-ID)
* you try to boot F8 and it won't find the root filesystem, because the
module (ata_piix) with drives the chipsets storage controller in its
default mode is missing in the initrd -> trouble that a lot of our users
are unable to solve

Cu
knurd

ata and scsi modules in initrd (was: Re: Bootup speed for F8)

[Leszek Matok]

Dnia 2007-12-02, o godz. 18:09:58 Thorsten Leemhuis <fedora(a)leemhuis.info&gt;
napisał(a):

>  * you try to boot F8 and it won't find the root filesystem,
> because the
>  module (ata_piix) with drives the chipsets storage controller in its
>  default mode is missing in the initrd -> trouble that a lot of our users
>  are unable to solve 
Happened to me after a BIOS upgrade, as well, but come on, the
website
specifically said something like "don't upgrade the BIOS yourself" and
"don't
mess with the BIOS unless you're sure the upgrade will fix something".

And it took me 15 seconds to switch to AHCI mode and boot Fedora again.

And it's probably not a problem for new users of the chipset, because they'll
never have to switch to AHCI in order to install Fedora (which was the case
some time ago).

On the other hand, the answer to many of such problems is simply "use rescue
image". You can try to run kudzu from there or something. It's not THAT hard.

To summarize, it's not a big deal, and I can't imagine having EVERY storage
driver in the initrd just in case someone replugs the disk between two very
rare controllers.

Lam

ata and scsi modules in initrd

[Thorsten Leemhuis]

On 02.12.2007 19:16, Leszek Matok wrote:
>  Dnia 2007-12-02, o godz. 18:09:58 Thorsten Leemhuis
> <fedora(a)leemhuis.info&gt;
>  napisał(a):
>  
> > * you try to boot F8 and it won't find the root filesystem, because the
> > module (ata_piix) with drives the chipsets storage controller in its
> > default mode is missing in the initrd -> trouble that a lot of our users
> > are unable to solve
>  Happened to me after a BIOS upgrade, as well, but come on, the website
>  specifically said something like "don't upgrade the BIOS yourself" and
> "don't
>  mess with the BIOS unless you're sure the upgrade will fix something". 
Sure, but there are good reasons to update the BIOS now and then.

>  And it took me 15 seconds to switch to AHCI mode and boot Fedora
> again. 
If you know about it. What do ordinary users do that don't know about
such things that got told by a "good" friend to update the BIOS?

>  [...]
>  On the other hand, the answer to many of such problems is simply "use rescue
>  image". You can try to run kudzu from there or something. It's not THAT hard.
I want it to just work. Isn't that what we aim for normally? The reason
why we install drivers or firmware for nearly all hardware by default,
even if it consumes a disk space?

>  To summarize, it's not a big deal, and I can't imagine having
> EVERY storage
>  driver in the initrd just in case someone replugs the disk between two very
>  rare controllers. 
I didn't say we should have all modules in the initrd. But having the
most common would IMHO a good thing.

Cu
knurd

ata and scsi modules in initrd

[drago01]

[..]
>  I didn't say we should have all modules in the initrd. But having
> the
>  most common would IMHO a good thing. 
+1 for having all pata/sata drivers in the initrd by default.

ata and scsi modules in initrd

[Jonathan Dieter]

On Sun, 2007-12-02 at 20:03 +0100, dragoran wrote:
>  [..]
>  > I didn't say we should have all modules in the initrd. But having the
>  > most common would IMHO a good thing.
>  
>  +1 for having all pata/sata drivers in the initrd by default.
>   
The whole kernel/drivers/ata directory is 1.2MB for 2.6.23.1-49.fc8.  My
initrd is already 3.6MB.  Another 1.2MB won't hurt.

+1

Jonathan

ata and scsi modules in initrd

[Callum Lerwick]

On Sun, 2007-12-02 at 20:03 +0100, dragoran wrote:
>  [..]
>  > I didn't say we should have all modules in the initrd. But having the
>  > most common would IMHO a good thing.
>  
>  +1 for having all pata/sata drivers in the initrd by default. 
One of the things that used to make Linux superior to Windows is the
fact that you could pop out a hard drive and plug it into an entirely
different machine, and it would Just Work. Well, except for X. Stupid X.
But at least you could boot it, switch the X driver and be done with it.

But then initrds were introduced, and now we're baking in system
specifics into it. Now I have all kinds of trouble with drivers not
being found, and volume groups not being found. Only solution is to boot
a rescue disk and rebuild the initrd, using an incredibly arcane series
of commands. I pity the n00b who tries to upgrade their system.

And Windows has gotten worse in this regard too. Back in the days of
Win95/98, you could ALWAYS, at the very least, boot the system into
rescue mode, go into the device manager, select the PCI bus and remove
it. This forced it to rescan and reload all the drivers. 5-10 reboots
later, bam, you're done. But now with Windows XP, if you change the
motherboard out from under it, its quite likely to not boot. At all. Not
even rescue mode. You're screwed. You have to re-install from scratch.
Supposedly there's a way to "reseal" Windows XP, but you have to do it
*before* you switch the board. I was unaware of this method until it was
too late so I didn't get a chance to try it. And no, I'm even using a
copy of XP Pro which is free of activation bullshit. I pity the fool who
buys a legitimate XP. (And no, I do in fact have a legitimate XP Pro
license, it came stuck to the bottom of my (used) laptop :)

http://www.motherboard.windowsreinstall.com/winxp.htm#Solution%204:%
20Microsoft%20SYSPREP%A0

ata and scsi modules in initrd

[Thorsten Leemhuis]

On 03.12.2007 02:10, Callum Lerwick wrote:
>  On Sun, 2007-12-02 at 20:03 +0100, dragoran wrote:
> > [..]
> >> I didn't say we should have all modules in the initrd. But having the
> >> most common would IMHO a good thing.
> > +1 for having all pata/sata drivers in the initrd by default.
>  One of the things that used to make Linux superior to Windows is the
>  fact that you could pop out a hard drive and plug it into an entirely
>  different machine, and it would Just Work.  
strong +1

>  Well, except for X. Stupid X. 
Which is getting fixed afaik, so it should "just work" in the future as
well.

>  [...]
>  But then initrds were introduced, and now we're baking in system
>  specifics into it. Now I have all kinds of trouble with drivers not
>  being found, and volume groups not being found. Only solution is to boot
>  a rescue disk and rebuild the initrd, using an incredibly arcane series
>  of commands. I pity the n00b who tries to upgrade their system. 
+1 -- for us here on the list it's no big deal, but for ordinary users
its a PITA that often leads them to reinstall linux, which leads to
"Linux is complicated" statements.

CU
knurd

ata and scsi modules in initrd

[Warren Togami]

dragoran wrote:
>  [..]
> > I didn't say we should have all modules in the initrd. But having the
> > most common would IMHO a good thing.
>  
>  +1 for having all pata/sata drivers in the initrd by default.
>   
Has anyone checked how much larger this would make a typical initrd image?

The experimental bash-branch of mkinitrd has a simple for loop to load 
all available kernel modules matching available PCI devices, so we could 
possibly load the drivers dynamically.  But then actually using the 
devices that appear to boot might be more challenging, unless the device 
names haven't changed since mkinitrd time.

Warren Togami
wtogami(a)redhat.com

ata and scsi modules in initrd

[Thorsten Leemhuis]

On 03.12.2007 03:01, Warren Togami wrote:
>  dragoran wrote:
> > [..]
> >> I didn't say we should have all modules in the initrd. But having the
> >> most common would IMHO a good thing.
> > +1 for having all pata/sata drivers in the initrd by default.
>  Has anyone checked how much larger this would make a typical initrd image? 
$ du /lib/modules/2.6.23.8-63.fc8/kernel/drivers/{ata,scsi}/  --max-depth\=0
1604    /lib/modules/2.6.23.8-63.fc8/kernel/drivers/ata/
4004    /lib/modules/2.6.23.8-63.fc8/kernel/drivers/scsi/

Not sure if the SCSI drivers (and their firmware) should get included as
well, but it might make sense. At least including the most common ones
makes sense -- the space that was confused by the initrd is free later,
isn't it?

>  The experimental bash-branch of mkinitrd has a simple for loop [...]
I didn't look into the bash-branch. The idea sounds nice, but well,
getting a bash prompt if the root-device was not found isn't much of a
help if you don't have the different storage drivers available, because
one of the top reasons why the root device does not get mounted are
missing drivers for the storage controller.

CU
knurd

ata and scsi modules in initrd

[David Zeuthen]

On Sun, 2007-12-02 at 21:01 -0500, Warren Togami wrote:
>  dragoran wrote:
>  > [..]
>  >> I didn't say we should have all modules in the initrd. But having the
>  >> most common would IMHO a good thing.
>  > 
>  > +1 for having all pata/sata drivers in the initrd by default.
>  > 
>  
>  Has anyone checked how much larger this would make a typical initrd image?
>  
>  The experimental bash-branch of mkinitrd has a simple for loop to load 
>  all available kernel modules matching available PCI devices, so we could 
>  possibly load the drivers dynamically.   
Code in the initramfs shouldn't have to be modified just because you
throw extra kernel modules in. Seriously. The initramfs isn't hard, it's
a solved problem [0], it goes like this

 - figure out UUID or LABEL [1] for rootfs. Write out an udev rule that
   will create a /dev/root symlink to said device

 - include other udev rules such as /etc/udev/rules.d/80-drivers.rules
   This will automagically load kernel modules in the initramfs if they
   are there. And only the modules that match the hardware will be
   loaded.

 - Do the equivalent of /sbin/start_udev (notably this one can be
   replaced by a three line shell script or so. That's what the upstream
   udev maintainer says anyway)

 - Once /sbin/start_udev is done, see if you have a /dev/root symlink;
   if not, drop to a shell. If you do, mount rootfs, delete yourself and
   exec /sbin/init on the real rootfs

If you're saying that our current initramfs as generated by mkinitrd
can't even do this, just another reason to find and apply the cluebat.

[0] : Of course, then there's all the crap with dm, md, iscsi, nfsroot,
whatever etc. that isn't really interesting and not really hard either
since most of this can also be driven by one-line udev rules.

[1] : Or device name though it should never ever be necessary to use
      device names.

>  But then actually using the 
>  devices that appear to boot might be more challenging, unless the device 
>  names haven't changed since mkinitrd time. 
I'm not sure what this means. One should always use UUID, if that's not
available use LABEL. All but exotic file systems (jffs2 - hi dwmw2!)
supports this. Of course if you change LABEL / UUID then it's your own
fault.

     David

ata and scsi modules in initrd

[Les Mikesell]

David Zeuthen wrote:

>  Code in the initramfs shouldn't have to be modified just because
> you
>  throw extra kernel modules in. Seriously. The initramfs isn't hard, it's
>  a solved problem [0], it goes like this
>  
>   - figure out UUID or LABEL [1] for rootfs. Write out an udev rule that
>     will create a /dev/root symlink to said device 
[...]

>  [1] : Or device name though it should never ever be necessary to
> use
>        device names. 
How do you get the UUID or LABEL or filesystem on the device without 
knowing the device name?

-- 
   Les Mikesell
    lesmikesell(a)gmail.com

ata and scsi modules in initrd

[David Zeuthen]

On Mon, 2007-12-03 at 10:23 -0600, Les Mikesell wrote:
>  David Zeuthen wrote:
>  
>  > Code in the initramfs shouldn't have to be modified just because you
>  > throw extra kernel modules in. Seriously. The initramfs isn't hard, it's
>  > a solved problem [0], it goes like this
>  > 
>  >  - figure out UUID or LABEL [1] for rootfs. Write out an udev rule that
>  >    will create a /dev/root symlink to said device
>  [...]
>  
>  > [1] : Or device name though it should never ever be necessary to use
>  >       device names.
>  
>  How do you get the UUID or LABEL or filesystem on the device without 
>  knowing the device name? 
You know it at initramfs generation time and you include that
information in the initramfs image.

    David

ata and scsi modules in initrd

[Bill Nottingham]

David Zeuthen (david(a)fubar.dk) said: 
>  [0] : Of course, then there's all the crap with dm, md, iscsi,
> nfsroot,
>  whatever etc. that isn't really interesting and not really hard either
>  since most of this can also be driven by one-line udev rules. 
Aside from the rest of it, if you've got a one line udev rule that can
mount a nfs loopback device, I'm all for seeing it. :)

(Similarly, unless udev has grown a block device daemon to assemble
raid/lvm/etc....)

Bill

ata and scsi modules in initrd

[David Zeuthen]

On Mon, 2007-12-03 at 12:08 -0500, Bill Nottingham wrote:
>  David Zeuthen (david(a)fubar.dk) said: 
>  > [0] : Of course, then there's all the crap with dm, md, iscsi, nfsroot,
>  > whatever etc. that isn't really interesting and not really hard either
>  > since most of this can also be driven by one-line udev rules.
>  
>  Aside from the rest of it, if you've got a one line udev rule that can
>  mount a nfs loopback device, I'm all for seeing it. :) 
If you think I'm suggesting to use udev like that you're misguieded.
I'm not suggesting to use udev for that; that'd be like using a
screwdriver for nails. Of course, nfsroot just another path in the
initramfs. News at 11.

>  (Similarly, unless udev has grown a block device daemon to assemble
>  raid/lvm/etc....) 
Uhm, no, no daemon is needed; ffs, this is just handling events. Look
e.g. here 

 https://launchpad.net/ubuntu/+source/mdadm/

and see [1] for excerpt. 

Seriously, the point of my messages in this subthread is to fix user
space instead of keep pretending the world isn't event driven. The other
distros are doing this already. Fedora not participating in this means
just that.. not participating. Meaning we will have little influence to
fix things once someone realizes that our current course of action was a
mistake. 

Instead, as Fedora, we should be the one leading this effort and rally
all the distros around a common toolset. It's just frakking amazing how
people working for Red Hat, in 2007, still don't understand why it's
important to do their work upstream. Just mind boggling. And, in my
view, also inexcusable.

Not participating also means that doing things like LTSP is just going
to get harder and harder; ask Warren about that

http://wtogami.livejournal.com/20047.html

    David

[1] :

  * md activation:
    - We now have a single udev rule for both the real system and the
      initramfs, since doing things differently there will only result in bugs
      and confusion.
    - This rule runs "mdadm --assemble --scan --no-degraded", automatically
      activating any non-degraded device as their components are detected.
    - Drop the mdadm-raid init script, since this does the same thing.
    - Also drop mdadm-startall which uses the mdadm-raid init script, and its
      associated sgml file (thus dropping the build-dep on docbook-to-man)
    - Simplify the configuration, since we always autostart all devices so do
      not need to specify any required root devices, etc.
    - Drop the deprecated mdrun entirely.
    - Since udev autostarts arrays, much of the initramfs script can be
      dropped.

ata and scsi modules in initrd

[Ian Chapman]

Thorsten Leemhuis wrote:

> > To summarize, it's not a big deal, and I can't imagine
> having EVERY storage
> > driver in the initrd just in case someone replugs the disk between two very
> > rare controllers.
>  
>  I didn't say we should have all modules in the initrd. But having the
>  most common would IMHO a good thing. 
Imaging would be another thing that would benefit from this. We like to 
have identical images even though the hardware can vary quite 
considerably. 99% of the time this isn't an issue because the hardware 
is detected dynamically and largely requires no manual intervention, but 
this is one minor area that sometimes requires a bit of manual 
intervention. A work around at the moment is to add an alias in 
/etc/modprobe.conf on the master image for every disk controller type we 
use, when the kernel is installed it pulls in the appropriate modules so 
that it doesn't matter what controller the target is using.

-- 
Ian Chapman.

ata and scsi modules in initrd

[Manuel Wolfshant]

Thorsten Leemhuis wrote:
>  On 02.12.2007 19:16, Leszek Matok wrote:
>    
> > Dnia 2007-12-02, o godz. 18:09:58 Thorsten Leemhuis <fedora(a)leemhuis.info&gt;
> > napisał(a):
> >
> >     
> >> * you try to boot F8 and it won't find the root filesystem, because the
> >> module (ata_piix) with drives the chipsets storage controller in its
> >> default mode is missing in the initrd -> trouble that a lot of our users
> >> are unable to solve
> >>       
> > Happened to me after a BIOS upgrade, as well, but come on, the website
> > specifically said something like "don't upgrade the BIOS yourself" and
> "don't
> > mess with the BIOS unless you're sure the upgrade will fix something".
> >     
>
>  Sure, but there are good reasons to update the BIOS now and then.
>
>    
> > And it took me 15 seconds to switch to AHCI mode and boot Fedora again.
> >     
>
>  If you know about it. What do ordinary users do that don't know about
>  such things that got told by a "good" friend to update the BIOS?
>     
When I've told my girl friend to press DEL to enter the BIOS in order to 
do a change (-> load safe defaults), the reply was "press what ?", 
followed by "what's a BIOS?"
And she is actively using a computer daily for several (6+) years.

[Stewart Adam]

On Fri, 2007-11-30 at 21:06 -0500, Dimi Paun wrote:
>  Well, maybe, but I think it's a common problem:
>      http://lattica.com/pub/bootchart-20071130-f8.png
>  
>  In my case, that initial time is close to 11s! And mind
>  you, it's no bootchard weirdness, I've always noticed it.
>  
>  Wall time for the above boot sequence is:
>    * GRUB -> X:       25s
>    * X -> login:      40s
>    * login -> usable: 20s
>  
>  That's almost 1.5 minutes, with all the user interaction
>  removed. 
IIRC development stopped on gdm-early-login because it was trouble for
users with system files that were NFS-mounted (/var and /usr I think),
but that was one really easy way to make things seem faster without
actually the decreasing boot time.

Stewart

[Linus Walleij]

On Sat, 1 Dec 2007, Stewart Adam wrote:

>  IIRC development stopped on gdm-early-login because it was trouble
> for
>  users with system files that were NFS-mounted (/var and /usr I think),
>  but that was one really easy way to make things seem faster without
>  actually the decreasing boot time. 
Depends on how you define boot time. If you say boot is done when the 
system is interactive, you cut several seconds.

"Other OS:es" obviously use this approach, the perceptual being what 
matters.

Surely, this must be fixable, it'd be such a boost..

Linus

[Stewart Adam]

On Sat, 2007-12-01 at 23:40 +0100, Linus Walleij wrote:
>  Depends on how you define boot time. If you say boot is done when the
>
>  system is interactive, you cut several seconds.
>  
>  "Other OS:es" obviously use this approach, the perceptual being what 
>  matters.
>  
>  Surely, this must be fixable, it'd be such a boost..
>  
>  Linus 
That's exactly what I mean - An early login can make the boot seem to
boot much faster even if it really isn't. Waiting is what makes things
seem long; the faster the user interacts, the faster things seem.

Stewart

[Andrew Farris]

Stewart Adam wrote:
>  On Sat, 2007-12-01 at 23:40 +0100, Linus Walleij wrote:
> > Depends on how you define boot time. If you say boot is done when the 
> > system is interactive, you cut several seconds.
> >
> > "Other OS:es" obviously use this approach, the perceptual being what 
> > matters.
> >
> > Surely, this must be fixable, it'd be such a boost..
> >
> > Linus
>  That's exactly what I mean - An early login can make the boot seem to
>  boot much faster even if it really isn't. Waiting is what makes things
>  seem long; the faster the user interacts, the faster things seem.
>  
>  Stewart 
Sure thats true, but perception is also just a fake improvement, and once the
user gets used to seeing the login earlier... they'll get more and more
discontent with how long it takes to be usable after they logged in (afterall
they *already logged in*).  For a great example of why this can be frustrating,
install a copy of Vista; its 'boot time' is great, but you login and wait... and
wait... and wait.  When you do see the desktop you still can't do anything
useful with it because the system is still so heavily loaded with background
processes starting.  Its much the same with xp, but vista made it even worse,
while the 'boot time' is even lower.

I have always appreciated the fact that a machine thats STARTED in linux can be
logged into quickly and be useful with minimal delay.  The general case with
windows which delays many background processes until login is that you can boot
your system and walk away to get coffee... but when you come back you'll still
sit there waiting after login before you can work.

I'm only bringing up the windows comparison for contrast, because MS has been
working hard to bring about this same early login illusion.

Making the system *actually usable* sooner is where development time and effort
should be spent rather than spending time to fake it.  If a valid argument can
be made for a method to get desktop software to begin processing earlier due to
early login then lets talk about that.  If its nothing more than login without
letting CPU cycles go toward the desktop startup then why bother?

-- 
Andrew Farris <lordmorgul(a)gmail.com&gt; <ajfarris(a)gmail.com&gt;
   gpg 0xC99B1DF3 at pgp.mit.edu

No one now has, and no one will ever again get, the big picture. - Daniel Geer
----                                                                       ----

[nodata]

Am Sonntag, den 02.12.2007, 22:58 -0800 schrieb Andrew Farris:
>  Stewart Adam wrote:
>  > On Sat, 2007-12-01 at 23:40 +0100, Linus Walleij wrote:
>  >> Depends on how you define boot time. If you say boot is done when the 
>  >> system is interactive, you cut several seconds.
>  >>
>  >> "Other OS:es" obviously use this approach, the perceptual being what 
>  >> matters.
>  >>
>  >> Surely, this must be fixable, it'd be such a boost..
>  >>
>  >> Linus
>  > That's exactly what I mean - An early login can make the boot seem to
>  > boot much faster even if it really isn't. Waiting is what makes things
>  > seem long; the faster the user interacts, the faster things seem.
>  > 
>  > Stewart
>  
>  Sure thats true, but perception is also just a fake improvement, and once the
>  user gets used to seeing the login earlier...  
I want to login more quickly and start gnome-terminal, sometimes
Firefox. What do other people want to do?

>  they'll get more and more
>  discontent with how long it takes to be usable after they logged in (afterall 
Better stay away from that slippery slope of progress then!

>  they *already logged in*).  For a great example of why this can be
> frustrating,
>  install a copy of Vista; its 'boot time' is great, 
Yep. It's really fast, versus Fedora which takes a couple of minutes.

>   but you login and wait... and
>  wait... and wait.  When you do see the desktop you still can't do anything
>  useful  
I can load putty or Firefox. That's quite useful.

>  with it because the system is still so heavily loaded with
> background
>  processes starting.  Its much the same with xp, but vista made it even worse,
>  while the 'boot time' is even lower. 
Works for me. Resume takes just a few seconds too.

>  I have always appreciated the fact that a machine thats STARTED in
> linux can be
>  logged into quickly and be useful with minimal delay.  The general case with
>  windows which delays many background processes until login is that you can boot
>  your system and walk away to get coffee... but when you come back you'll still
>  sit there waiting after login before you can work.
>  
>  I'm only bringing up the windows comparison for contrast, because MS has been
>  working hard to bring about this same early login illusion.
>  
>  Making the system *actually usable* sooner is where development time and effort
>  should be spent rather than spending time to fake it.  If a valid argument can
>  be made for a method to get desktop software to begin processing earlier due to
>  early login then lets talk about that.  If its nothing more than login without
>  letting CPU cycles go toward the desktop startup then why bother?
>  
>  -- 
>  Andrew Farris <lordmorgul(a)gmail.com&gt; <ajfarris(a)gmail.com&gt;
>     gpg 0xC99B1DF3 at pgp.mit.edu
>  
>  No one now has, and no one will ever again get, the big picture. - Daniel Geer
>  ----                                                                       ----
>

[Stewart Adam]

-  
Stewart Adam
Diffingo Solutions Inc.
Tel: [phone]    Web: www.diffingo.com

On Sun, 2007-12-02 at 22:58 -0800, Andrew Farris wrote:
>  Sure thats true, but perception is also just a fake improvement, and
> once the
>  user gets used to seeing the login earlier... they'll get more and more
>  discontent with how long it takes to be usable after they logged in (afterall
>  they *already logged in*).  For a great example of why this can be frustrating,
>  install a copy of Vista; its 'boot time' is great, but you login and wait... and
>  wait... and wait.  When you do see the desktop you still can't do anything
>  useful with it because the system is still so heavily loaded with background
>  processes starting.  Its much the same with xp, but vista made it even worse,
>  while the 'boot time' is even lower.
>  
>  I have always appreciated the fact that a machine thats STARTED in linux can be
>  logged into quickly and be useful with minimal delay.  The general case with
>  windows which delays many background processes until login is that you can boot
>  your system and walk away to get coffee... but when you come back you'll still
>  sit there waiting after login before you can work.
>  
>  I'm only bringing up the windows comparison for contrast, because MS has been
>  working hard to bring about this same early login illusion.
>  
>  Making the system *actually usable* sooner is where development time and effort
>  should be spent rather than spending time to fake it.  If a valid argument can
>  be made for a method to get desktop software to begin processing earlier due to
>  early login then lets talk about that.  If its nothing more than login without
>  letting CPU cycles go toward the desktop startup then why bother? 
I agree, but the point I'm trying to bring up is let's do both in
moderation. Hacking to reduce boot time can only shorten it by so much;
At one point, there will be nothing left to shorten. An early login can
also only do so much before annoying the users (because like you say do
it too much and it makes the login unresponsive). But the two put
together and you get a quick and responsive boot up.

Stewart

[Lubomir Kundrak]

On Thu, 2007-11-29 at 17:34 -0500, Dimi Paun wrote:
>  Hi folks,
>  
>  I've currently upgraded to F8, congrats!
>  
>  Just thought of sharing a data-point for startup speed
>  (measured from GRUB, so excluding all the BIOS stuff):
>    * to graphical init: 30s
>    * to login prompt: 1m8s
>    * after login, to responsive state: 14s
>  
>  That's 1m22s to start. On a good desktop: Intel Duo 2.13GHz, 2GB RAM.
>  With the BIOS thrown in, it takes over 2minutes to be able to get
>  into the box.
>  
>  That's rather slow, no? 
You forgot to attach the patch to fix that.

-- 
Lubomir Kundrak (Red Hat Security Response Team)

[Adam Jackson]

On Thu, 2007-11-29 at 17:34 -0500, Dimi Paun wrote:
>  Hi folks,
>  
>  I've currently upgraded to F8, congrats!
>  
>  Just thought of sharing a data-point for startup speed
>  (measured from GRUB, so excluding all the BIOS stuff):
>    * to graphical init: 30s
>    * to login prompt: 1m8s
>    * after login, to responsive state: 14s
>  
>  That's 1m22s to start. On a good desktop: Intel Duo 2.13GHz, 2GB RAM.
>  With the BIOS thrown in, it takes over 2minutes to be able to get
>  into the box.
>  
>  That's rather slow, no? 
It is!  Have you installed bootchart to see what's taking so much time?

- ajax

[Rudolf Kastl]

Personally i am working on straightening out initng which is part of
the repos and with selinux disabled (there is a bug in current initng
regarding selinux so dont use it if you want selinux enabled until the
next fix shows up) from start if init to gdm in 15 seconds with
NetworkManager and all that stuff enabled.
I guess with a bit more hacking and optimising you could go close to 10 seconds.

kind regards,
Rudolf Kastl

On Nov 29, 2007 10:34 PM, Dimi Paun <dimi(a)lattica.com&gt; wrote:
>  Hi folks,
>
>  I've currently upgraded to F8, congrats!
>
>  Just thought of sharing a data-point for startup speed
>  (measured from GRUB, so excluding all the BIOS stuff):
>    * to graphical init: 30s
>    * to login prompt: 1m8s
>    * after login, to responsive state: 14s
>
>  That's 1m22s to start. On a good desktop: Intel Duo 2.13GHz, 2GB RAM.
>  With the BIOS thrown in, it takes over 2minutes to be able to get
>  into the box.
>
>  That's rather slow, no?
>
>  --
>  Dimi Paun <dimi(a)lattica.com&gt;
>  Lattica, Inc.
>
>  --
>  fedora-devel-list mailing list
>  fedora-devel-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

[Mark]

2007/11/30, Rudolf Kastl <che666(a)gmail.com&gt;:
>  Personally i am working on straightening out initng which is part of
>  the repos and with selinux disabled (there is a bug in current initng
>  regarding selinux so dont use it if you want selinux enabled until the
>  next fix shows up) from start if init to gdm in 15 seconds with
>  NetworkManager and all that stuff enabled.
>  I guess with a bit more hacking and optimising you could go close to 10 seconds. 
That's a real speed boost!
and how fast was your boot without nintng? (just init)
Or better.. could you post yout init bootchart and your initng
bootchart? would be interesting to see.

[Rudolf Kastl]

On Nov 30, 2007 9:48 AM, Mark <markg85(a)gmail.com&gt; wrote:
>  2007/11/30, Rudolf Kastl <che666(a)gmail.com&gt;:
>  > Personally i am working on straightening out initng which is part of
>  > the repos and with selinux disabled (there is a bug in current initng
>  > regarding selinux so dont use it if you want selinux enabled until the
>  > next fix shows up) from start if init to gdm in 15 seconds with
>  > NetworkManager and all that stuff enabled.
>  > I guess with a bit more hacking and optimising you could go close to 10 seconds.
>
>  That's a real speed boost!
>  and how fast was your boot without nintng? (just init)
>  Or better.. could you post yout init bootchart and your initng
>  bootchart? would be interesting to see. 
i surely can do that. of course bootchart also slows down everything.
if i get around to it i might do that within the next week and try
with a comparable setup to show the differences.

kind regards,
Rudolf Kastl

>  --
>
>  fedora-devel-list mailing list
>  fedora-devel-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

[Jonathan Dieter]

On Fri, 2007-11-30 at 09:30 +0000, Rudolf Kastl wrote:
>  Personally i am working on straightening out initng which is part of
>  the repos and with selinux disabled (there is a bug in current initng
>  regarding selinux so dont use it if you want selinux enabled until the
>  next fix shows up) from start if init to gdm in 15 seconds with
>  NetworkManager and all that stuff enabled.
>  I guess with a bit more hacking and optimising you could go close to 10 seconds.
>   
I just gave initng a shot, and, while it started up my system extremely
fast, I noticed a number of failure messages on the screen and when I
logged in, I noticed that my CPU Frequency applet said that my CPU
wasn't capable of scaling (it's a laptop with a Core Duo processor and
three different levels of scaling).

Do you want bug reports or does it need a bit more work before it can
replace normal init?

Jonathan

[Rudolf Kastl]

On Nov 30, 2007 12:09 PM, Jonathan Dieter <jdieter(a)gmail.com&gt; wrote:
>  On Fri, 2007-11-30 at 09:30 +0000, Rudolf Kastl wrote:
>  > Personally i am working on straightening out initng which is part of
>  > the repos and with selinux disabled (there is a bug in current initng
>  > regarding selinux so dont use it if you want selinux enabled until the
>  > next fix shows up) from start if init to gdm in 15 seconds with
>  > NetworkManager and all that stuff enabled.
>  > I guess with a bit more hacking and optimising you could go close to 10 seconds.
>  >
>  I just gave initng a shot, and, while it started up my system extremely
>  fast, I noticed a number of failure messages on the screen and when I
>  logged in, I noticed that my CPU Frequency applet said that my CPU
>  wasn't capable of scaling (it's a laptop with a Core Duo processor and
>  three different levels of scaling). 
the cpuspeed script has to be fixed. actually as a workaround you can
just use the following wrapper:

#!/sbin/itype
# This is a i file, used by initng parsed by install_service

# NAME:
# DESCRIPTION:
# WWW:

service service/cpuspeed {
        need = system/bootmisc;
        use = system/modules system/coldplug;
        exec start = /etc/init.d/cpuspeed start;
        exec stop = /etc/init.d/cpuspeed stop;
}

put the above script into:

/etc/initng/service/cpuspeed.i

of course that is just a workaround :D

>  Do you want bug reports or does it need a bit more work before it can
>  replace normal init? 
That is a pretty much known problem and if i am not too wrong i even
filed it into fedora bugzilla. If you encounter something and dont
find a report for it yet please report it as many people have the
chance then to attach a fix for it.

Of course there is still alot of work to do to smooth things out. What
should work now is getting the system to boot in any case. There is
also lots of things to improve in the base system to make things go
smoother. e.g. you will see that NetworkManager will fail upon bootup.
That is because dbus daemon needs 5 seconds when it has been started
until the service is available. The above numbers i gave for boottime
include having a sleep 5 in the NetworkManager startup script (hacky
workaround that needs a fix with dbus).

It is definitely not ready for real end user consumption because
things have to be checked and improved all over the place but with
more people contributing actually that could get done rather fast in
my eyes. It is just alot work if only a few people with not much spare
time fix things here and there as time permits, so every small bit of
help and patch is a nice thing to have.

Yes the bootup time is very fast but i think to get broader acceptance
more stuff has to be fixed. Actually the new version of it in the pipe
is supposed to be able to take dbus events to get things started up
and uses posix compliant startup scripts (note that the upcoming
scripts are automatically generated from the ifiles it uses now so it
makes sense to just fix the current stable release). The svn scripts
also allow the addition of new events like beeing able to add status
scripts/routines and configcheck etc.

kind regards,
Rudolf Kastl


>  Jonathan
>
>  --
>  fedora-devel-list mailing list
>  fedora-devel-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

[Rudolf Kastl]

On Nov 30, 2007 12:32 PM, Rudolf Kastl <che666(a)gmail.com&gt; wrote:
>  On Nov 30, 2007 12:09 PM, Jonathan Dieter <jdieter(a)gmail.com&gt;
> wrote:
>  > On Fri, 2007-11-30 at 09:30 +0000, Rudolf Kastl wrote:
>  > > Personally i am working on straightening out initng which is part of
>  > > the repos and with selinux disabled (there is a bug in current initng
>  > > regarding selinux so dont use it if you want selinux enabled until the
>  > > next fix shows up) from start if init to gdm in 15 seconds with
>  > > NetworkManager and all that stuff enabled.
>  > > I guess with a bit more hacking and optimising you could go close to 10
> seconds.
>  > >
>  > I just gave initng a shot, and, while it started up my system extremely
>  > fast, I noticed a number of failure messages on the screen and when I
>  > logged in, I noticed that my CPU Frequency applet said that my CPU
>  > wasn't capable of scaling (it's a laptop with a Core Duo processor and
>  > three different levels of scaling).
>
>  the cpuspeed script has to be fixed. actually as a workaround you can
>  just use the following wrapper:
>
>  #!/sbin/itype
>  # This is a i file, used by initng parsed by install_service
>
>  # NAME:
>  # DESCRIPTION:
>  # WWW:
>
>  service service/cpuspeed {
>          need = system/bootmisc;
>          use = system/modules system/coldplug;
>          exec start = /etc/init.d/cpuspeed start;
>          exec stop = /etc/init.d/cpuspeed stop;
>  }
>
>  put the above script into:
>
>  /etc/initng/service/cpuspeed.i
>
>  of course that is just a workaround :D
>
>  >
>  > Do you want bug reports or does it need a bit more work before it can
>  > replace normal init?
>
>  That is a pretty much known problem and if i am not too wrong i even
>  filed it into fedora bugzilla. If you encounter something and dont
>  find a report for it yet please report it as many people have the
>  chance then to attach a fix for it.
>
>  Of course there is still alot of work to do to smooth things out. What
>  should work now is getting the system to boot in any case. There is
>  also lots of things to improve in the base system to make things go
>  smoother. e.g. you will see that NetworkManager will fail upon bootup.
>  That is because dbus daemon needs 5 seconds when it has been started
>  until the service is available. The above numbers i gave for boottime
>  include having a sleep 5 in the NetworkManager startup script (hacky
>  workaround that needs a fix with dbus).
>
>  It is definitely not ready for real end user consumption because
>  things have to be checked and improved all over the place but with
>  more people contributing actually that could get done rather fast in
>  my eyes. It is just alot work if only a few people with not much spare
>  time fix things here and there as time permits, so every small bit of
>  help and patch is a nice thing to have.
>
>  Yes the bootup time is very fast but i think to get broader acceptance
>  more stuff has to be fixed. Actually the new version of it in the pipe
>  is supposed to be able to take dbus events to get things started up
>  and uses posix compliant startup scripts (note that the upcoming
>  scripts are automatically generated from the ifiles it uses now so it
>  makes sense to just fix the current stable release). The svn scripts
>  also allow the addition of new events like beeing able to add status
>  scripts/routines and configcheck etc.
>
>  kind regards,
>  Rudolf Kastl
>
>
>  >
>  > Jonathan
>
>  >
>  > --
>  > fedora-devel-list mailing list
>  > fedora-devel-list(a)redhat.com
>  > https://www.redhat.com/mailman/listinfo/fedora-devel-list
>  >
>  
as for the cpuspeed workaround... you also have to exchange the
service used for it in the runlevel file.
/etc/initng/runlevel/default.runlevel

kind regards,
Rudolf Kastl

[Jon Masters]

Yo,

Just to chime in here...one of the guys tells me he has a patch to
module-init-tools that shaves about a second or so off boot. I'm ok with
taking this kind of stuff, and encourage it! But I don't think modprobe
is really where we're spending all of our time on boot.

Jon.

[Mark]

2007/11/30, Jon Masters <jcm(a)redhat.com&gt;:
>  Yo,
>
>  Just to chime in here...one of the guys tells me he has a patch to
>  module-init-tools that shaves about a second or so off boot. I'm ok with
>  taking this kind of stuff, and encourage it! But I don't think modprobe
>  is really where we're spending all of our time on boot.
>
>  Jon. 
Most time seems to be in kernel booting, udev and x starting (+gdm)

@Adam Jackson
can you make that patched X version available in Fedora 8 as a
unstable package? or just somewhere that it doesn't get in the
official repository? i would like to give it a spin (without
installing rawhide if possible)