Re: Splash.xpm.gz
by Nick Bargnesi
Same here - on x86_64 its in fedora-logos.
-Nick
On Thu, 2 Dec 2004 19:21:22 -0500, Jeff Spaleta <jspaleta(a)gmail.com> wrote:
> On Thu, 2 Dec 2004 16:39:59 -0600, W. Michael Petullo <mike(a)flyn.org> wrote:
> > Why is boot/grub/splash.xpm.gz included in the kernel RPM? Why is it
> > not in the grub RPM instead? The reason I ask is that, when using
> > Fedora's kernel, splash.xpm.gz is installed on my PowerPC-based system.
> > Yaboot is used instead of grub on PowerPC.
>
> what?
> on my x86 fc3 system splash.xpm.gz is part of fedora-logos package
> in the development i386 tree splash.xpm.gz is part of fedora-logos packages
> in fact the version of fedora-logos is the same in fc3 as in
> development at the moment.
> are you really really sure /boot/grub/splash.xpm.gz on your system is
> part of the kernel rpm?
>
> -jef
>
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list(a)redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
>
--
Nick Bargnesi
http://www.den-4.com
Den 4 Software
pub 1024D/E8BD2FD0 2004-12-02 Nick Bargnesi <nbargnesi(a)gmail.com>
Key fingerprint = 6F9D 9404 63CD 2B04 DE7A 0F9D A1ED C1B0 E8BD 2FD0
sub 2048g/56C5D45B 2004-12-02
19 years, 5 months
Re: Splash.xpm.gz
by Jef Spaleta
On Thu, 2 Dec 2004 16:39:59 -0600, W. Michael Petullo <mike(a)flyn.org> wrote:
> Why is boot/grub/splash.xpm.gz included in the kernel RPM? Why is it
> not in the grub RPM instead? The reason I ask is that, when using
> Fedora's kernel, splash.xpm.gz is installed on my PowerPC-based system.
> Yaboot is used instead of grub on PowerPC.
what?
on my x86 fc3 system splash.xpm.gz is part of fedora-logos package
in the development i386 tree splash.xpm.gz is part of fedora-logos packages
in fact the version of fedora-logos is the same in fc3 as in
development at the moment.
are you really really sure /boot/grub/splash.xpm.gz on your system is
part of the kernel rpm?
-jef
19 years, 5 months
Splash.xpm.gz
by W. Michael Petullo
Why is boot/grub/splash.xpm.gz included in the kernel RPM? Why is it
not in the grub RPM instead? The reason I ask is that, when using
Fedora's kernel, splash.xpm.gz is installed on my PowerPC-based system.
Yaboot is used instead of grub on PowerPC.
--
Mike
:wq
19 years, 5 months
Re: adventures in booting
by David Zeuthen
Hey,
sorry for the lag,
On Wed, 2004-12-01 at 03:59 +0100, Ziga Mahkovec wrote:
> On Sun, 2004-11-28 at 20:49 -0500, David Zeuthen wrote:
> > So, I've looked a bit more into the booting process and how to optimize
> > it.
>
> Great work!
>
Thanks.
> > The results are pretty good I think, here is the general time line made
> > with a wallclock
> >
> > 00: exit grub; start booting the kernel
> > 04: kernel prints audit()
> > 11: initrd is mounted; Red Hat nash visible
> > mount / ro (normal initrd procedure)
> > 13: start bootchart logging; start readahead of approx 193MB files
> > sleep until readahead is complete
> > 24: readahead done; now
> > create /dev and modprobe (in background)
> > mount / rw, enable swap
> > start xfs
> > startx as user davidz in background
> > start messagebus
> > start hald
> > start acpid
> > start NetworkManager
>
> Do you have an idea of how much kudzu, cups and syslogd would add to
> these times? rhgb too probably, or would it make sense to dump it
> completely?
>
I think that cups and syslogd are mostly harmless - for capturing the
readahead files from my modified kernel I had syslogd log dump to /tmp
which I mounted as tmpfs. syslogd should probably start in before gdm,
but cupsd can certainly be started later (ideally it should be started
on demand).
kudzu is a bit more difficult as it brings up dialogs - I think Bill
agrees (see the thread on fedora-desktop-list that I linked to in my
original mail) that hardware configuration should be handled in the
desktop GUI anyway.
> > 7. A number of things was started in parallel - I found that doing
> > readahead while running modprobe wasn't helping anything; in fact
> > it contributed negatively to performance (a bit to my surprise, I
> > guess because the kernel was busy).
>
> You think it might make sense to try running readahead in background,
> but after the modules are loaded? Especially if the readahead list
> could somehow coincide with the order of services started, to further
> reduce seeking.
> Or is readahead best left running alone?
>
Not sure; the big boost really comes from reordering the files on the
filesystem - running readahead (which takes 11 seconds) only gives me a
usable desktop four seconds earlier. I'm pretty sure no other process
should do any disk IO when readahead is running as that will almost
certainly incur seek penalties.
> > So, I think these numbers are good and there's still some room for
> > improvement; e.g. it takes ten seconds from grub to when the initrd is
> > mounted - surely the kernel can boot faster? It's after all 25% of the
> > time spent from grub until I have usable desktop.
>
> I did some experiments with bootchart logging in the initrd phase.
> Packed the initrd image with bash, ps and a bunch of libraries and
> started logging early in the nash script... only to find out that the
> whole phase flies by in less than a second :)
>
Yeah, I found that too.
> I would like to visualize the kernel boot though. But I'd need pointers
> on what kind of data to collect, and how.
>
I think some embedded systems (think DVD players) use patches to boot
the kernel faster - I wonder what the status of adding them to mainline
are?
> > Thanks a lot to Ziga Mahkovec for the bootchart software - it's been
> > very useful.
>
> BTW, I've had loads of fun with SVG lately, so you might want to try
> regenerating these charts. Makes them scalable and about 15x smaller in
> file size. Have a look at the SVG samples (rsvg does a pretty good
> job):
> http://www.klika.si/ziga/bootchart/#Samples
>
Awesome.
Cheers,
David
19 years, 5 months
Re: adventures in booting
by Ziga Mahkovec
On Sun, 2004-11-28 at 20:49 -0500, David Zeuthen wrote:
> So, I've looked a bit more into the booting process and how to optimize
> it.
Great work!
> The results are pretty good I think, here is the general time line made
> with a wallclock
>
> 00: exit grub; start booting the kernel
> 04: kernel prints audit()
> 11: initrd is mounted; Red Hat nash visible
> mount / ro (normal initrd procedure)
> 13: start bootchart logging; start readahead of approx 193MB files
> sleep until readahead is complete
> 24: readahead done; now
> create /dev and modprobe (in background)
> mount / rw, enable swap
> start xfs
> startx as user davidz in background
> start messagebus
> start hald
> start acpid
> start NetworkManager
Do you have an idea of how much kudzu, cups and syslogd would add to
these times? rhgb too probably, or would it make sense to dump it
completely?
> 7. A number of things was started in parallel - I found that doing
> readahead while running modprobe wasn't helping anything; in fact
> it contributed negatively to performance (a bit to my surprise, I
> guess because the kernel was busy).
You think it might make sense to try running readahead in background,
but after the modules are loaded? Especially if the readahead list
could somehow coincide with the order of services started, to further
reduce seeking.
Or is readahead best left running alone?
> So, I think these numbers are good and there's still some room for
> improvement; e.g. it takes ten seconds from grub to when the initrd is
> mounted - surely the kernel can boot faster? It's after all 25% of the
> time spent from grub until I have usable desktop.
I did some experiments with bootchart logging in the initrd phase.
Packed the initrd image with bash, ps and a bunch of libraries and
started logging early in the nash script... only to find out that the
whole phase flies by in less than a second :)
I would like to visualize the kernel boot though. But I'd need pointers
on what kind of data to collect, and how.
> Thanks a lot to Ziga Mahkovec for the bootchart software - it's been
> very useful.
BTW, I've had loads of fun with SVG lately, so you might want to try
regenerating these charts. Makes them scalable and about 15x smaller in
file size. Have a look at the SVG samples (rsvg does a pretty good
job):
http://www.klika.si/ziga/bootchart/#Samples
--
Ziga
19 years, 5 months
Re: adventures in booting
by David Malcolm
On Sun, 2004-11-28 at 20:49 -0500, David Zeuthen wrote:
Awesome! So... is no-one else going to reply to this email?
Various comments inline below...
> Hey,
>
> So, I've looked a bit more into the booting process and how to optimize
> it. Mostly based on the discussion triggered by Owen's boot poster
> challenge, here
>
> http://www.redhat.com/archives/fedora-devel-list/2004-November/msg00447.html
>
> and also some experiments that I did - basically replacing rhgb with gdm
> as described here
>
> http://www.redhat.com/archives/fedora-desktop-list/2004-November/msg00066...
>
> What I've done is a bit crude - I've replaced init(1) with a shell
> script based on /etc/rc.d/rc.sysinit and tried to optimize specifically
> for my system: IBM Thinkpad T41 laptop with a Pentium M processor at
> 1600MHz along with 512MB of RAM.
If I understand, you're also optimising for a specific user of that
system. Is it worth splitting the readahead into a system-wide list of
files (enough to get to the login screen), followed by a per-user list
for logging in as a user? To what extent will the files needed to get
to a usable desktop vary between Alice and Bob?
>
> The results are pretty good I think, here is the general time line made
> with a wallclock
>
> 00: exit grub; start booting the kernel
> 04: kernel prints audit()
> 11: initrd is mounted; Red Hat nash visible
> mount / ro (normal initrd procedure)
> 13: start bootchart logging; start readahead of approx 193MB files
> sleep until readahead is complete
> 24: readahead done; now
> create /dev and modprobe (in background)
> mount / rw, enable swap
> start xfs
> startx as user davidz in background
> start messagebus
> start hald
> start acpid
> start NetworkManager
> 32: X claims the display
> 34: GNOME desktop banner
> 40: GNOME desktop is usable (Nautilus desktop, panel fully populated)
>
> Here is a bootchart made with the bootchart software from Ziga Mahkovec:
>
> http://people.redhat.com/davidz/bootchart.png
> You may notice that I also start firefox after login and it starts very
> very fast - that's because readahead loads all files used by Firefox -
> in earlier experiments I've also added files from OpenOffice.org to
> readahead and that meant I could start up OpenOffice.org Writer in about
> three seconds. More below.
>
> I've made the following observations
>
> 1. The kernel patch, linux-2.6.3-printopen.patch, wasn't really working
> well for me - it reported far to few files - instead I added a
> printk() to fs/namei.c:link_path_walk()
> (disclaimer: I don't know much about the kernel so there may be a
> better solution than this).
>
> 2. The data captured from link_path_walk() was massaged into a list
> of unique files to preload and sorted on sectors.
>
> 3. While capturing the data link_path_walk() and before processing
> I went through all the menus in the GNOME desktop (to make sure
> their icon and desktop files would be added to the list) as well as
> loading Firefox. The list contains 5189 unique files - 231 of these
> from my home directory - 103 of these from gconf in my home
> directory and 302 from gconf in /etc. 2267 were .png files and
> 814 of them were .desktop files. 488 files had ".so" in their name.
> There was a total of 193MB of files (which says something about
> the footprint of the GNOME desktop on Fedora :-/)
>
> 4. Doing the readahead really helped the time from startx till a
> usable desktop - less than 10 seconds!
>
> 5. Doing readahead on the 5189 files took about 45 seconds on my
> system, mostly because the files were scattered around the disk.
> Since I had a spare partition 17GB partition, I did this:
> a. format spare partition as ext3
> b. copy all readahead files to spare partition (193MB)
> c. copy rest of files from main partition to spare partition
> (about 9GB)
> Now the readahead is down to 11 seconds which averages out to
> be 18MB/s. On the other hand, I can still see (using fileblock)
> that the files in the readahead is still scattered out and hdparm
> says I should be able to get 33.87 MB/sec with no seeks.
>
> 6. I made a hack to cache /dev (a dev.tar file) and the list of modules
> to load. This could be used in production if the kernel could give
> us basically a hash value for the kobject hierarchy representing
> the hardware (perhaps even a 'tree /sys |md5sum' would suffice).
> This shaved some seconds of as well.
>
> 7. A number of things was started in parallel - I found that doing
> readahead while running modprobe wasn't helping anything; in fact
> it contributed negatively to performance (a bit to my surprise, I
> guess because the kernel was busy).
>
> 8. readahead on the right files is A Good Thing(tm). Booting my system
> without readahead on the partition with the readahead files scattered
> took 58 seconds (compared to 39 with readahead on the optimized
> partition)
>
> http://people.redhat.com/davidz/bootchart-without-readahead-scattered.png
>
> and without readahead on on the optimized partition it took 43
> seconds
>
> http://people.redhat.com/davidz/bootchart-without-readahead-nonscattered.png
>
> again compared to 39 seconds. As an added bonus, the readahead
> makes sure that e.g Firefox loads fast; all .png and .desktop files
> are in place for when using the menus. As mentioned, one could put
> very big apps like e.g. OO.o in the readahead set.
>
> So, I think these numbers are good and there's still some room for
> improvement; e.g. it takes ten seconds from grub to when the initrd is
> mounted - surely the kernel can boot faster? It's after all 25% of the
> time spent from grub until I have usable desktop.
>
> The bad thing is that this approach is highly specific to my system (and
> thus why I'm not posting an RPM with it :-), however I think it clearly
> shows where improvements should be made; here are some random thoughts
>
> a. We should keep track of files being loaded and maintain the
> readahead fileset as appropriate. printk() doesn't seem like the
> right solution; perhaps a system daemon using inotify or the
> kernel events layer is the road ahead? This would enable us to
> readahead the KDE stuff if the user is e.g. using KDE a lot.
>
> b. ext3 should support operations for moving blocks around; e.g.
> optimize around the readahead fileset - when idle the system should
> rearrange the files to facilitate faster booting
>
> c. the start_udev and kmodule process could be cached as I did above
>
> d. The whole init(1) procedure seems dated; perhaps something more
> modern built on top of D-BUS is the right choice - SystemServices
> by Seth Nickell comes to mind [1]. Ideally services to be started
> would have dependencies such as 1) don't start the gdm service
> before /usr/bin/gdm is available; 2) the SSH service would only
> be active when NetworkManager says there is a network connection;
> /usr from LABEL=/usr would only be mounted when there is a volume
> with that label and so forth. Also, such a system would of course
> have support for LSB init scripts.
> (This is probably a whole project on it's own so I'm omitting
> detailed thinking on it for now)
Hopefully this could also allow us to make system-config-services look a
lot slicker. I've never liked the way it has random text spewage for
each service's status - some kind of widgetry would satisfy my eye-candy
cravings.
>
> Thanks a lot to Ziga Mahkovec for the bootchart software - it's been
> very useful.
>
> Have fun,
> David
>
> [1] : http://www.osnews.com/story.php?news_id=4711
> http://www.gnome.org/~seth/blog/2003/Sep/27
>
19 years, 5 months
Re: Some bugs, where to file them?
by Kyrre Ness Sjobak
man, 29.11.2004 kl. 23.14 skrev Phil Schaffner:
> On Mon, 2004-11-29 at 16:14 -0500, Jeff Spaleta wrote:
> > On Mon, 29 Nov 2004 21:49:27 +0100, Kyrre Ness Sjobak
> > <kyrre(a)solution-forge.net> wrote:
> > > I have had some difficulties with installing a box with a "RIVA128" gfx
> > > card.
> > >
> ... snip ...
> >
> > It's difficult to know if your system really is hanging.. or if there
> > is a small problem with the display drivers that is affecting X
> > startup for rhgb and firstboot.. without some more information. Doing
> > a fresh install and booting without the boot options quiet and rhgb
> > would be interesting... to see if firstboot behaves without running
> > rhgb. Similarly doing an install and preventing firstboot from running
> > to see if X starts up correctly would be useful.
>
> Might try booting to runlevel 3 (type "a" at grub boot screen, backspace
> to delete "rhgb quiet" then "3<Enter>"), log in as root, and do
>
> # system-config-display --reconfig
>
> Check detected hardware carefully to make sure it matches yours.
>
> Phil
>
shall do. Just have to roll fc3 on a buch of put'ers first, and this our
testing box.
Everything else looks really nice, though :)
19 years, 5 months
Re: Some bugs, where to file them?
by Phil Schaffner
On Mon, 2004-11-29 at 16:14 -0500, Jeff Spaleta wrote:
> On Mon, 29 Nov 2004 21:49:27 +0100, Kyrre Ness Sjobak
> <kyrre(a)solution-forge.net> wrote:
> > I have had some difficulties with installing a box with a "RIVA128" gfx
> > card.
> >
... snip ...
>
> It's difficult to know if your system really is hanging.. or if there
> is a small problem with the display drivers that is affecting X
> startup for rhgb and firstboot.. without some more information. Doing
> a fresh install and booting without the boot options quiet and rhgb
> would be interesting... to see if firstboot behaves without running
> rhgb. Similarly doing an install and preventing firstboot from running
> to see if X starts up correctly would be useful.
Might try booting to runlevel 3 (type "a" at grub boot screen, backspace
to delete "rhgb quiet" then "3<Enter>"), log in as root, and do
# system-config-display --reconfig
Check detected hardware carefully to make sure it matches yours.
Phil
19 years, 5 months
adventures in booting
by David Zeuthen
Hey,
So, I've looked a bit more into the booting process and how to optimize
it. Mostly based on the discussion triggered by Owen's boot poster
challenge, here
http://www.redhat.com/archives/fedora-devel-list/2004-November/msg00447.html
and also some experiments that I did - basically replacing rhgb with gdm
as described here
http://www.redhat.com/archives/fedora-desktop-list/2004-November/msg00066...
What I've done is a bit crude - I've replaced init(1) with a shell
script based on /etc/rc.d/rc.sysinit and tried to optimize specifically
for my system: IBM Thinkpad T41 laptop with a Pentium M processor at
1600MHz along with 512MB of RAM.
The results are pretty good I think, here is the general time line made
with a wallclock
00: exit grub; start booting the kernel
04: kernel prints audit()
11: initrd is mounted; Red Hat nash visible
mount / ro (normal initrd procedure)
13: start bootchart logging; start readahead of approx 193MB files
sleep until readahead is complete
24: readahead done; now
create /dev and modprobe (in background)
mount / rw, enable swap
start xfs
startx as user davidz in background
start messagebus
start hald
start acpid
start NetworkManager
32: X claims the display
34: GNOME desktop banner
40: GNOME desktop is usable (Nautilus desktop, panel fully populated)
Here is a bootchart made with the bootchart software from Ziga Mahkovec:
http://people.redhat.com/davidz/bootchart.png
You may notice that I also start firefox after login and it starts very
very fast - that's because readahead loads all files used by Firefox -
in earlier experiments I've also added files from OpenOffice.org to
readahead and that meant I could start up OpenOffice.org Writer in about
three seconds. More below.
I've made the following observations
1. The kernel patch, linux-2.6.3-printopen.patch, wasn't really working
well for me - it reported far to few files - instead I added a
printk() to fs/namei.c:link_path_walk()
(disclaimer: I don't know much about the kernel so there may be a
better solution than this).
2. The data captured from link_path_walk() was massaged into a list
of unique files to preload and sorted on sectors.
3. While capturing the data link_path_walk() and before processing
I went through all the menus in the GNOME desktop (to make sure
their icon and desktop files would be added to the list) as well as
loading Firefox. The list contains 5189 unique files - 231 of these
from my home directory - 103 of these from gconf in my home
directory and 302 from gconf in /etc. 2267 were .png files and
814 of them were .desktop files. 488 files had ".so" in their name.
There was a total of 193MB of files (which says something about
the footprint of the GNOME desktop on Fedora :-/)
4. Doing the readahead really helped the time from startx till a
usable desktop - less than 10 seconds!
5. Doing readahead on the 5189 files took about 45 seconds on my
system, mostly because the files were scattered around the disk.
Since I had a spare partition 17GB partition, I did this:
a. format spare partition as ext3
b. copy all readahead files to spare partition (193MB)
c. copy rest of files from main partition to spare partition
(about 9GB)
Now the readahead is down to 11 seconds which averages out to
be 18MB/s. On the other hand, I can still see (using fileblock)
that the files in the readahead is still scattered out and hdparm
says I should be able to get 33.87 MB/sec with no seeks.
6. I made a hack to cache /dev (a dev.tar file) and the list of modules
to load. This could be used in production if the kernel could give
us basically a hash value for the kobject hierarchy representing
the hardware (perhaps even a 'tree /sys |md5sum' would suffice).
This shaved some seconds of as well.
7. A number of things was started in parallel - I found that doing
readahead while running modprobe wasn't helping anything; in fact
it contributed negatively to performance (a bit to my surprise, I
guess because the kernel was busy).
8. readahead on the right files is A Good Thing(tm). Booting my system
without readahead on the partition with the readahead files scattered
took 58 seconds (compared to 39 with readahead on the optimized
partition)
http://people.redhat.com/davidz/bootchart-without-readahead-scattered.png
and without readahead on on the optimized partition it took 43
seconds
http://people.redhat.com/davidz/bootchart-without-readahead-nonscattered.png
again compared to 39 seconds. As an added bonus, the readahead
makes sure that e.g Firefox loads fast; all .png and .desktop files
are in place for when using the menus. As mentioned, one could put
very big apps like e.g. OO.o in the readahead set.
So, I think these numbers are good and there's still some room for
improvement; e.g. it takes ten seconds from grub to when the initrd is
mounted - surely the kernel can boot faster? It's after all 25% of the
time spent from grub until I have usable desktop.
The bad thing is that this approach is highly specific to my system (and
thus why I'm not posting an RPM with it :-), however I think it clearly
shows where improvements should be made; here are some random thoughts
a. We should keep track of files being loaded and maintain the
readahead fileset as appropriate. printk() doesn't seem like the
right solution; perhaps a system daemon using inotify or the
kernel events layer is the road ahead? This would enable us to
readahead the KDE stuff if the user is e.g. using KDE a lot.
b. ext3 should support operations for moving blocks around; e.g.
optimize around the readahead fileset - when idle the system should
rearrange the files to facilitate faster booting
c. the start_udev and kmodule process could be cached as I did above
d. The whole init(1) procedure seems dated; perhaps something more
modern built on top of D-BUS is the right choice - SystemServices
by Seth Nickell comes to mind [1]. Ideally services to be started
would have dependencies such as 1) don't start the gdm service
before /usr/bin/gdm is available; 2) the SSH service would only
be active when NetworkManager says there is a network connection;
/usr from LABEL=/usr would only be mounted when there is a volume
with that label and so forth. Also, such a system would of course
have support for LSB init scripts.
(This is probably a whole project on it's own so I'm omitting
detailed thinking on it for now)
Thanks a lot to Ziga Mahkovec for the bootchart software - it's been
very useful.
Have fun,
David
[1] : http://www.osnews.com/story.php?news_id=4711
http://www.gnome.org/~seth/blog/2003/Sep/27
19 years, 5 months
stateless linux
by Peter Schobel
i'm still getting this error
Could not determine client snapshot information for reserve boot
partition
it only syncs the root partition and not the boot partition and the disk
labels and grub aren't getting updated
this was working at one point - any ideas what could cause that error?
[root@pinab-devel stateless]# /etc/cron.hourly/stateless-replicator
Device "/dev/hda1" has label "RESERVE_BOOT"
Device "/dev/hda2" has label "/"
Device "/dev/hda1" has label "RESERVE_BOOT"
Device "/dev/hda2" has label "/"
Device "/dev/hda3" has label "RESERVE_ROOT"
Mounting /dev/hda3 at /tmp/tmpWLDLcJ/reserve_root (type ext3)
Device "/dev/hda1" has label "RESERVE_BOOT"
Device "/dev/hda2" has label "/"
Device "/dev/hda3" has label "RESERVE_ROOT"
Device "/dev/hda5" has label "/boot"
Device "/dev/hda1" has label "RESERVE_BOOT"
Mounting /dev/hda1 at /tmp/tmpWLDLcJ/reserve_boot (type ext3)
Could not determine client snapshot information for reserve boot partition
Provisioning data from server:(config "pinab", protocol "None", snapshot "pinab-10")
Getting (config "pinab", protocol "None", snapshot "pinab-10") to device /dev/hda3
rsync url:"rsync://cms.porchlight.ca/stateless/pinab/pinab-10/"
excluding /boot
rsync finished
role finished
Unmounting /tmp/tmpWLDLcJ/reserve_root
Unmounting /tmp/tmpWLDLcJ/reserve_boot
19 years, 5 months
