Discussion:
Bootup speed for F8
(too old to reply)
Dimi Paun
2007-11-29 22:34:59 UTC
Permalink
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 at lattica.com>
Lattica, Inc.
Adam Jackson
2007-11-29 23:09:40 UTC
Permalink
Post by Dimi Paun
Hi folks,
I've currently upgraded to F8, congrats!
Just thought of sharing a data-point for startup speed
* 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
Gary Thomas
2007-11-29 22:40:23 UTC
Permalink
Post by Dimi Paun
Hi folks,
I've currently upgraded to F8, congrats!
Just thought of sharing a data-point for startup speed
* 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
2007-11-29 22:44:16 UTC
Permalink
Post by Dimi Paun
Hi folks,
I've currently upgraded to F8, congrats!
Just thought of sharing a data-point for startup speed
* 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
2007-11-29 23:04:38 UTC
Permalink
Post by Dimi Paun
Hi folks,
I've currently upgraded to F8, congrats!
Just thought of sharing a data-point for startup speed
* 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
2007-11-30 08:58:29 UTC
Permalink
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)
Post by Kulbir Saini
Post by Dimi Paun
Hi folks,
I've currently upgraded to F8, congrats!
Just thought of sharing a data-point for startup speed
* 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 at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Mark
2007-11-30 09:00:00 UTC
Permalink
Post by Mark
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] Loading Image...
Bill Nottingham
2007-11-30 16:18:46 UTC
Permalink
Post by 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
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
2007-11-30 17:57:45 UTC
Permalink
Post by Bill Nottingham
Post by 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
50 sec - 7 (pure nothing) = 43 seconds.
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
Bernardo Innocenti
2007-12-01 00:02:15 UTC
Permalink
Post by Adam Jackson
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
2007-12-03 17:29:15 UTC
Permalink
Post by Bernardo Innocenti
Post by Adam Jackson
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=f01e149d1af14ef9ee0e8a6743ab6a08f3bb677c
http://cgit.freedesktop.org/xorg/xserver/commit/?id=22f0e3a8b04e574047a51c8f928a007787303294
http://cgit.freedesktop.org/xorg/xserver/commit/?id=cecac794451b793871f297b91a11d3b52eeb6d1b
http://cgit.freedesktop.org/xorg/driver/xf86-input-keyboard/commit/?id=b139da4553e71896689e8f522e5cff58f5bb7674
http://cgit.freedesktop.org/xorg/driver/xf86-input-mouse/commit/?id=76a2231f87551f7c1943df18bc537b9b15987562

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

- ajax
Bernardo Innocenti
2007-12-03 18:02:05 UTC
Permalink
Post by Adam Jackson
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/
Bernardo Innocenti
2007-12-01 00:02:15 UTC
Permalink
Post by Adam Jackson
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
2007-11-30 17:57:45 UTC
Permalink
Post by Bill Nottingham
Post by 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
50 sec - 7 (pure nothing) = 43 seconds.
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
Dimi Paun
2007-12-01 02:06:40 UTC
Permalink
Post by Bill Nottingham
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:
Loading Image...

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 at lattica.com>
Lattica, Inc.
Jesse Barnes
2007-12-01 05:50:15 UTC
Permalink
Post by Dimi Paun
Post by Bill Nottingham
1) bootchart weirdness (as it's from when bootchart starts)
2) hotplug issues with a driver in the initrd not initializing right
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
2007-12-01 06:23:09 UTC
Permalink
Post by Jesse Barnes
Post by Dimi Paun
Post by Bill Nottingham
1) bootchart weirdness (as it's from when bootchart starts)
2) hotplug issues with a driver in the initrd not initializing right
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
2007-12-01 13:02:14 UTC
Permalink
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] Loading Image...
[2] http://img530.imageshack.us/img530/6483/bootchartsw0.png
[3] http://www.mail-archive.com/unattended-info at lists.sourceforge.net/msg04445.html
Post by David Zeuthen
Post by Jesse Barnes
Post by Dimi Paun
Post by Bill Nottingham
1) bootchart weirdness (as it's from when bootchart starts)
2) hotplug issues with a driver in the initrd not initializing right
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 at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Mark
2007-12-01 13:56:33 UTC
Permalink
Post by Mark
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] Loading Image...
(20 seconds)
Jesse Barnes
2007-12-01 16:46:54 UTC
Permalink
Post by 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?
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-01 18:06:58 UTC
Permalink
Post by Jesse Barnes
Post by 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?
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...
Mark
2007-12-01 18:06:58 UTC
Permalink
Post by Jesse Barnes
Post by 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?
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...
Mark
2007-12-01 13:56:33 UTC
Permalink
Post by Mark
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
2007-12-01 16:46:54 UTC
Permalink
Post by 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?
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
Dave Jones
2007-12-02 02:52:15 UTC
Permalink
Post by David Zeuthen
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
2007-12-02 11:31:00 UTC
Permalink
Post by Dave Jones
Post by David Zeuthen
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.
Post by Dave Jones
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
Thorsten Leemhuis
2007-12-02 17:09:58 UTC
Permalink
Post by David Zeuthen
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
Leszek Matok
2007-12-02 18:16:49 UTC
Permalink
Dnia 2007-12-02, o godz. 18:09:58 Thorsten Leemhuis <fedora at leemhuis.info>
Post by Thorsten Leemhuis
* 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20071202/b059be34/attachment.bin
Thorsten Leemhuis
2007-12-02 18:50:36 UTC
Permalink
Post by Leszek Matok
Dnia 2007-12-02, o godz. 18:09:58 Thorsten Leemhuis <fedora at leemhuis.info>
Post by Thorsten Leemhuis
* 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.
Post by Leszek Matok
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?
Post by Leszek Matok
[...]
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?
Post by Leszek Matok
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
dragoran
2007-12-02 19:03:20 UTC
Permalink
[..]
Post by Thorsten Leemhuis
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.
Jonathan Dieter
2007-12-02 19:24:31 UTC
Permalink
Post by dragoran
[..]
Post by Thorsten Leemhuis
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20071202/e39bbcbe/attachment.bin
Callum Lerwick
2007-12-03 01:10:40 UTC
Permalink
Post by dragoran
[..]
Post by Thorsten Leemhuis
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20071202/2feb60e1/attachment.bin
Thorsten Leemhuis
2007-12-03 08:43:30 UTC
Permalink
Post by Callum Lerwick
Post by dragoran
[..]
Post by Thorsten Leemhuis
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
Post by Callum Lerwick
Well, except for X. Stupid X.
Which is getting fixed afaik, so it should "just work" in the future as
well.
Post by Callum Lerwick
[...]
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
Thorsten Leemhuis
2007-12-03 08:43:30 UTC
Permalink
Post by Callum Lerwick
Post by dragoran
[..]
Post by Thorsten Leemhuis
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
Post by Callum Lerwick
Well, except for X. Stupid X.
Which is getting fixed afaik, so it should "just work" in the future as
well.
Post by Callum Lerwick
[...]
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
Warren Togami
2007-12-03 02:01:30 UTC
Permalink
Post by dragoran
[..]
Post by Thorsten Leemhuis
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 at redhat.com
Thorsten Leemhuis
2007-12-03 08:56:29 UTC
Permalink
Post by Warren Togami
Post by dragoran
[..]
Post by Thorsten Leemhuis
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?
Post by Warren Togami
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
David Zeuthen
2007-12-03 15:34:43 UTC
Permalink
Post by Warren Togami
Post by dragoran
[..]
Post by Thorsten Leemhuis
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.
Post by Warren Togami
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
Les Mikesell
2007-12-03 16:23:26 UTC
Permalink
Post by David Zeuthen
?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
[...]
Post by David Zeuthen
?[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 at gmail.com
David Zeuthen
2007-12-03 16:27:46 UTC
Permalink
Post by Les Mikesell
Post by David Zeuthen
?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
[...]
Post by David Zeuthen
?[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
David Zeuthen
2007-12-03 16:27:46 UTC
Permalink
Post by Les Mikesell
Post by David Zeuthen
?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
[...]
Post by David Zeuthen
?[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

Bill Nottingham
2007-12-03 17:08:03 UTC
Permalink
Post by David Zeuthen
[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
David Zeuthen
2007-12-03 17:38:03 UTC
Permalink
Post by Bill Nottingham
Post by David Zeuthen
[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.
Post by Bill Nottingham
(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.
David Zeuthen
2007-12-03 17:38:03 UTC
Permalink
Post by Bill Nottingham
Post by David Zeuthen
[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.
Post by Bill Nottingham
(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.
Les Mikesell
2007-12-03 16:23:26 UTC
Permalink
Post by David Zeuthen
?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
[...]
Post by David Zeuthen
?[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 at gmail.com
Thorsten Leemhuis
2007-12-03 08:56:29 UTC
Permalink
Post by Warren Togami
Post by dragoran
[..]
Post by Thorsten Leemhuis
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?
Post by Warren Togami
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
David Zeuthen
2007-12-03 15:34:43 UTC
Permalink
Post by Warren Togami
Post by dragoran
[..]
Post by Thorsten Leemhuis
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.
Post by Warren Togami
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
Jonathan Dieter
2007-12-02 19:24:31 UTC
Permalink
Post by dragoran
[..]
Post by Thorsten Leemhuis
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20071202/e39bbcbe/attachment-0002.bin
Callum Lerwick
2007-12-03 01:10:40 UTC
Permalink
Post by dragoran
[..]
Post by Thorsten Leemhuis
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20071202/2feb60e1/attachment-0002.bin
Warren Togami
2007-12-03 02:01:30 UTC
Permalink
Post by dragoran
[..]
Post by Thorsten Leemhuis
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 at redhat.com
Ian Chapman
2007-12-02 19:17:39 UTC
Permalink
Post by Thorsten Leemhuis
Post by Leszek Matok
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.
Manuel Wolfshant
2007-12-04 13:10:17 UTC
Permalink
Post by Thorsten Leemhuis
Post by Leszek Matok
Dnia 2007-12-02, o godz. 18:09:58 Thorsten Leemhuis <fedora at leemhuis.info>
Post by Thorsten Leemhuis
* 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.
Post by Leszek Matok
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.
dragoran
2007-12-02 19:03:20 UTC
Permalink
[..]
Post by Thorsten Leemhuis
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.
Ian Chapman
2007-12-02 19:17:39 UTC
Permalink
Post by Thorsten Leemhuis
Post by Leszek Matok
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.
Thorsten Leemhuis
2007-12-02 18:50:36 UTC
Permalink
Post by Leszek Matok
Dnia 2007-12-02, o godz. 18:09:58 Thorsten Leemhuis <fedora at leemhuis.info>
Post by Thorsten Leemhuis
* 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.
Post by Leszek Matok
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?
Post by Leszek Matok
[...]
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?
Post by Leszek Matok
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
Leszek Matok
2007-12-02 18:16:49 UTC
Permalink
Dnia 2007-12-02, o godz. 18:09:58 Thorsten Leemhuis <fedora at leemhuis.info>
Post by Thorsten Leemhuis
* 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20071202/b059be34/attachment-0002.bin
Thorsten Leemhuis
2007-12-02 17:09:58 UTC
Permalink
Post by David Zeuthen
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
David Zeuthen
2007-12-02 11:31:00 UTC
Permalink
Post by Dave Jones
Post by David Zeuthen
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.
Post by Dave Jones
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
Mark
2007-12-01 13:02:14 UTC
Permalink
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/unattended-info at lists.sourceforge.net/msg04445.html
Post by David Zeuthen
Post by Jesse Barnes
Post by Dimi Paun
Post by Bill Nottingham
1) bootchart weirdness (as it's from when bootchart starts)
2) hotplug issues with a driver in the initrd not initializing right
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 at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Dave Jones
2007-12-02 02:52:15 UTC
Permalink
Post by David Zeuthen
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
2007-12-01 06:23:09 UTC
Permalink
Post by Jesse Barnes
Post by Dimi Paun
Post by Bill Nottingham
1) bootchart weirdness (as it's from when bootchart starts)
2) hotplug issues with a driver in the initrd not initializing right
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
Stewart Adam
2007-12-01 15:32:13 UTC
Permalink
Post by Dimi Paun
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.
* 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
2007-12-01 22:40:04 UTC
Permalink
Post by Stewart Adam
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
2007-12-02 00:50:18 UTC
Permalink
Post by Linus Walleij
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
2007-12-03 06:58:01 UTC
Permalink
Post by Stewart Adam
Post by Linus Walleij
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 at gmail.com> <ajfarris at gmail.com>
gpg 0xC99B1DF3 at pgp.mit.edu

No one now has, and no one will ever again get, the big picture. - Daniel Geer
---- ----
nodata
2007-12-03 21:08:25 UTC
Permalink
Post by Andrew Farris
Post by Stewart Adam
Post by Linus Walleij
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?
Post by Andrew Farris
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!
Post by Andrew Farris
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.
Post by Andrew Farris
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.
Post by Andrew Farris
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.
Post by Andrew Farris
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 at gmail.com> <ajfarris at gmail.com>
gpg 0xC99B1DF3 at pgp.mit.edu
No one now has, and no one will ever again get, the big picture. - Daniel Geer
---- ----
Stewart Adam
2007-12-03 22:22:59 UTC
Permalink
-
Stewart Adam
Diffingo Solutions Inc.
Tel: 450.447.2758 Web: www.diffingo.com
Post by Andrew Farris
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
Andrew Farris
2007-12-03 06:58:01 UTC
Permalink
Post by Stewart Adam
Post by Linus Walleij
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 at gmail.com> <ajfarris at gmail.com>
gpg 0xC99B1DF3 at pgp.mit.edu

No one now has, and no one will ever again get, the big picture. - Daniel Geer
---- ----
Stewart Adam
2007-12-02 00:50:18 UTC
Permalink
Post by Linus Walleij
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
Linus Walleij
2007-12-01 22:40:04 UTC
Permalink
Post by Stewart Adam
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
Jesse Barnes
2007-12-01 05:50:15 UTC
Permalink
Post by Dimi Paun
Post by Bill Nottingham
1) bootchart weirdness (as it's from when bootchart starts)
2) hotplug issues with a driver in the initrd not initializing right
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
Stewart Adam
2007-12-01 15:32:13 UTC
Permalink
Post by Dimi Paun
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.
* 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
Dimi Paun
2007-12-01 02:06:40 UTC
Permalink
Post by Bill Nottingham
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 at lattica.com>
Lattica, Inc.
Mark
2007-11-30 09:00:00 UTC
Permalink
Post by Mark
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
2007-11-30 16:18:46 UTC
Permalink
Post by 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
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
Mark
2007-11-30 08:58:29 UTC
Permalink
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)
Post by Kulbir Saini
Post by Dimi Paun
Hi folks,
I've currently upgraded to F8, congrats!
Just thought of sharing a data-point for startup speed
* 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 at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Kulbir Saini
2007-11-29 23:04:38 UTC
Permalink
Post by Dimi Paun
Hi folks,
I've currently upgraded to F8, congrats!
Just thought of sharing a data-point for startup speed
* 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/
-------------------------------------------------------
Lubomir Kundrak
2007-11-29 22:47:03 UTC
Permalink
Post by Dimi Paun
Hi folks,
I've currently upgraded to F8, congrats!
Just thought of sharing a data-point for startup speed
* 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)
Rudolf Kastl
2007-11-30 09:30:31 UTC
Permalink
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
Post by Dimi Paun
Hi folks,
I've currently upgraded to F8, congrats!
Just thought of sharing a data-point for startup speed
* 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 at lattica.com>
Lattica, Inc.
--
fedora-devel-list mailing list
fedora-devel-list at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Mark
2007-11-30 09:48:01 UTC
Permalink
Post by 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.
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
2007-11-30 11:54:46 UTC
Permalink
Post by Mark
Post by 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.
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
Post by Mark
--
fedora-devel-list mailing list
fedora-devel-list at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Rudolf Kastl
2007-11-30 11:54:46 UTC
Permalink
Post by Mark
Post by 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.
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
Post by Mark
--
fedora-devel-list mailing list
fedora-devel-list at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Jonathan Dieter
2007-11-30 12:09:02 UTC
Permalink
Post by 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.
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20071130/dc12cfa9/attachment.bin
Rudolf Kastl
2007-11-30 12:32:09 UTC
Permalink
Post by Jonathan Dieter
Post by 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.
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
Post by Jonathan Dieter
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
Post by Jonathan Dieter
Jonathan
--
fedora-devel-list mailing list
fedora-devel-list at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Rudolf Kastl
2007-11-30 14:08:01 UTC
Permalink
Post by Rudolf Kastl
Post by Jonathan Dieter
Post by 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.
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
#!/sbin/itype
# This is a i file, used by initng parsed by install_service
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;
}
/etc/initng/service/cpuspeed.i
of course that is just a workaround :D
Post by Jonathan Dieter
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
Post by Jonathan Dieter
Jonathan
--
fedora-devel-list mailing list
fedora-devel-list at 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
Rudolf Kastl
2007-11-30 14:08:01 UTC
Permalink
Post by Rudolf Kastl
Post by Jonathan Dieter
Post by 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.
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
#!/sbin/itype
# This is a i file, used by initng parsed by install_service
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;
}
/etc/initng/service/cpuspeed.i
of course that is just a workaround :D
Post by Jonathan Dieter
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
Post by Jonathan Dieter
Jonathan
--
fedora-devel-list mailing list
fedora-devel-list at 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
Rudolf Kastl
2007-11-30 12:32:09 UTC
Permalink
Post by Jonathan Dieter
Post by 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.
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
Post by Jonathan Dieter
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
Post by Jonathan Dieter
Jonathan
--
fedora-devel-list mailing list
fedora-devel-list at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Mark
2007-11-30 09:48:01 UTC
Permalink
Post by 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.
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.
Jonathan Dieter
2007-11-30 12:09:02 UTC
Permalink
Post by 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.
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20071130/dc12cfa9/attachment-0002.bin
Rudolf Kastl
2007-11-30 09:30:31 UTC
Permalink
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
Post by Dimi Paun
Hi folks,
I've currently upgraded to F8, congrats!
Just thought of sharing a data-point for startup speed
* 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 at lattica.com>
Lattica, Inc.
--
fedora-devel-list mailing list
fedora-devel-list at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Jon Masters
2007-11-30 20:36:14 UTC
Permalink
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 20:57:52 UTC
Permalink
Post by 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.
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)
Mark
2007-11-30 20:57:52 UTC
Permalink
Post by 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.
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)
Dimi Paun
2007-11-29 22:34:59 UTC
Permalink
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 at lattica.com>
Lattica, Inc.
Adam Jackson
2007-11-29 23:09:40 UTC
Permalink
Post by Dimi Paun
Hi folks,
I've currently upgraded to F8, congrats!
Just thought of sharing a data-point for startup speed
* 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
Gary Thomas
2007-11-29 22:40:23 UTC
Permalink
Post by Dimi Paun
Hi folks,
I've currently upgraded to F8, congrats!
Just thought of sharing a data-point for startup speed
* 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
2007-11-29 22:44:16 UTC
Permalink
Post by Dimi Paun
Hi folks,
I've currently upgraded to F8, congrats!
Just thought of sharing a data-point for startup speed
* 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
Lubomir Kundrak
2007-11-29 22:47:03 UTC
Permalink
Post by Dimi Paun
Hi folks,
I've currently upgraded to F8, congrats!
Just thought of sharing a data-point for startup speed
* 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)
Rudolf Kastl
2007-11-30 09:30:31 UTC
Permalink
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
Post by Dimi Paun
Hi folks,
I've currently upgraded to F8, congrats!
Just thought of sharing a data-point for startup speed
* 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 at lattica.com>
Lattica, Inc.
--
fedora-devel-list mailing list
fedora-devel-list at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Rudolf Kastl
2007-11-30 09:30:31 UTC
Permalink
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
Post by Dimi Paun
Hi folks,
I've currently upgraded to F8, congrats!
Just thought of sharing a data-point for startup speed
* 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 at lattica.com>
Lattica, Inc.
--
fedora-devel-list mailing list
fedora-devel-list at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Jon Masters
2007-11-30 20:36:14 UTC
Permalink
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.
Continue reading on narkive:
Loading...