You might need to install faad2 from rpmfusion and id3v2.

$ python m4aconvert.py *.plist

From the NEWS file:

dracut-005
==========
- add dcb support to dracut's FCoE support
- add readonly overlay support for dmsquash
- add keyboard kernel modules
- dracut.conf: added add_dracutmodules
- add /etc/dracut.conf.d
- add preliminary IPv6 support
- bugfixes

dracut-004
==========
- dracut-lib: read multiple lines from $init/etc/cmdline
- lsinitrd and mkinitrd
- dmsquash: add support for loopmounted *.iso files
- lvm: add rd_LVM_LV and "--poll n"
- user suspend support
- add additional drivers in host-only mode, too
- improved emergency shell
- support for compressed kernel modules
- support for loading Xen modules
- rdloaddriver kernel command line parameter
- man pages for dracut-catimages and dracut-gencmdline
- bugfixes

To test it on Fedora 12 do (it might take some time until the update is pushed and mirrors are synced):

# yum –enablerepo=updates-testing update dracut
# mv /boot/initramfs-$(uname -r).img /boot/initramfs-old-$(uname -r).img
# dracut /boot/initramfs-$(uname -r).img $(uname -r)

Here are the major changes compared to dracut-002:

• debian package modules
• dracut.conf manpage
• module 90multipath
• module 01fips
• crypt: ignore devices in /etc/crypttab (root is not in there) unless rd_NO_CRYPTTAB is specified
• kernel-modules: add scsi_dh scsi_dh_rdac scsi_dh_emc
• multinic support
• s390 zfcp support
• s390 dasd support
• s390 network support
• strip kernel modules which have no x bit set
• redirect stdin, stdout, stderr all RW to /dev/console so the user can use "less" to view /init.log and dmesg
• new device mapper udev rules and dmeventd
• fixed dracut-gencmdline for root=UUID or LABEL
• do not destroy assembled raid arrays if mdadm.conf present
• mount /dev/shm
• let udevd not resolve group and user names
• preserve timestamps of tools on initramfs generation
• generate symlinks for binaries correctly
• moved network from udev to initqueue
• mount nfs3 with nfsvers=3 option and retry with nfsvers=2
• fixed nbd initqueue-finished
• improved debug output: specifying "rdinitdebug" now logs to dmesg, console and /init.log
• strip kernel modules which have no x bit set
• redirect stdin, stdout, stderr all RW to /dev/console so the user can use "less" to view /init.log and dmesg
• make install of new dm/lvm udev rules optionally
• new device mapper udev rules and dmeventd
• Fix LiveCD boot regression
• bail out if selinux policy could not be loaded and selinux=0 not specified on kernel command line
• do not cleanup dmraids
• copy over lvm.conf

 The trick is, to open zenity with an extra file descriptor in "--listen" mode. So you can change the state of the notification dynamically. Here is the simple shell script. Maybe you can tweak it for your needs.

How to get started, if you want to test.

On Fedora 11 or Fedora rawhide (you might have to wait until the mirrors catch up):

# yum install dracut-0.3

or download the tarball: http://harald.fedorapeople.org/downloads/dracut/dracut-0.3.tar.bz2

# tar xzf dracut-0.3.tar.bz2
# cd dracut-0.3
# make install sbindir=/sbin sysconfdir=/etc

To generate a initramfs image, run:

# dracut <imagename> <kernel version>

to overwrite an existing image:

# dracut -f <imagename> <kernel version>

Update:
Ok, it seems the debug dracut module wants to be installed automatically, due to a bug.
You either have all binaries which are needed by the dracut debug module, or create the images with:

# dracut --omit debug <imagename> <kernel version>

Try to boot from that image by modifying /etc/grub.conf. Be sure to have a fallback entry.

If you want to boot from network have a look at the manpage.  Basically everything can be specified on the kernel command line.

Bug reports can be send directly to me (harald@redhat.com) until dracut appears in the bugzilla component list.

Further information about dracut: http://sourceforge.net/apps/trac/dracut/wiki

As Dave Jones started talking about months ago at Kernel Summit and LPC, there's a lot of duplication between distros on the tools used to generate the initramfs as well as the contents and how the initramfs works. Ultimately, there's little reason for this not to be something that is shared and worked on by everyone. Added to this is the fact that everyone's infrastructures for this have grown up over a long-ish period of time without significant amounts of reworking for the way that the kernel and early boot works these days.

Therefore Jeremy Katz started on a project, dracut, to be a new initramfs tool that can be used across various distributions.

End of March I took over the project. To open up the development and keep it distribution neutral, I created a sourceforge project. Somehow interest in dracut faded and development stalled. Though, the current state allows booting from several distributions, there is still a lot to do. Have a look at the trac wiki and the TODO page, if you want to help. Using dracut and obsoleting nash/mkinitrd is a Fedora Feature for F12, so any help is appreciated.

To make this task easier I wrote a small python script. It needs pybluez and bluez.

# yum install pybluez bluez

Then you can start the python script as root:

# python dialup-bluetooth.py

It first searches for all bluetooth devices, which provide the Dialup Service, and displays a list, where you can select your mobile.

Then it calls rfcomm and creates a rfcomm tty, which is bound to the bluetooth channel, and inserts a fake serial modem to hal with hal-device.

This triggers NetworkManager, and after 2 seconds your mobile phone should be displayed in the NetworkManager list as a GSM device, which you can configure and use in NetworkManager.

Maybe someone feels like doing a clean implementation, using the D-BUS interface for bluetooth, hal and NetworkManager.

Have fun!

To extract the information from the bootchart logs and analyze them, I wrote a quick and dirty python script.

The network initscript has a variable duration due to external dependencies, like network card negotiation with the switch or getting the IP from the DHCP server (more than 50 seconds sometimes!!!!). Because of this, I have subtracted the duration of it from the resulting time.

Resulting Tables with png bootcharts:

• QA:Testcase_bootchart_personal
• QA:Testcase_bootchart_desktop (with full desktop)
• QA:Testcase_bootchart_full_desktop
• QA:Testcase_bootchart_server
• QA:Testcase_bootchart_minimal

What we can see from the result, of course disk I/O speed and CPU speed are the major factors, which determine the boot speed.

Other I/O factors include:

• disk fragmentation
• type of filesystem used

But that it is not what we are looking for. We want to eliminate unnecessary bottle necks, where neither CPU or I/O is the limiting factor or where unexpected I/O or CPU activities are happening.

For example, as we can see in https://fedoraproject.org/w/uploads/3/3b/Bootchart-a02fad60-dcf8-48d7-9de0-4d67a050313d-desktop.png restorecon is called in rc.sysinit on /dev , nash-hotplug is running and CPU is 100% for 4 seconds with practically no disk I/O.

Fortunately this is fixed already in latest mkinitrd by http://git.fedorahosted.org/git/?p=mkinitrd;a=commitdiff;h=d539443a6ebe8868a73daffa88adfc408838bc21;hp=9253a1b55376b491bf612f00ec1d3edc66502a3f

This bootchart is especially useful, because the whole boot process is taking so long, because the disk and CPU is so slow.

What we also see, in comparison to other distributions, is the long time spent before rc.sysinit is even started. First there is the kernel loading and initialization and second there is nash with a whole udev implementation and plymouth started. While nash is nice to have, because a lot of variants of root devices are supported, efforts for a unified cross distribution initrd are underway. We will see, if that helps or increases boot time in the future.

For example on my Dell, the time until rc.sysinit is started varies between 5 and 10 seconds. So this fluctuation has to be recognized when comparing bootcharts (even from the same distribution and machine).

Next thing started after nash is rc.sysinit. There have bugzillas filed against some applications, which do not clean up their state directories, resulting in a long "find and remove" action in rc.sysinit (var/run/gdm/auth-for* directories not removed.... slows boot)

The big thing started in rc.sysinit is, of course, start_udev. start_udev first removes all files in /dev, creates all basic nodes, runs restorecon on them and begins replaying all kernel hotplug events. This triggers module loading and the creation of all hardware device nodes for the hardware found on the system. Module loading is taking the most part of I/O and CPU here. If you consider to speedup modprobe, keep in mind that even loading all modules via insmod by hand takes nearly as much time as using modprobe with dependency resolution and database reading. On my systems the difference between using insmod and modprobe was not recognizable at all. So, I would conclude that most of the time is spent reading the module files from disk and most CPU is spent in the kernel with module and hardware initialization.

Of course some points make your system noticeable slower in this part:

• use of /etc/udev/makedev.d/. If there are files in /etc/udev/makedev.d, MAKEDEV is called, which in turn reads a lot of files from /etc/makedev.d, which takes a lot of time on some systems.
• too many scripts in /lib/udev/rules.d or /etc/udev/rules.d. On some systems you do not need all rule files. Some rules are executed on every device added, just to catch a corner case, which might never happen on your system.
• some 3rd party rules are very badly designed and implement a kind of busy polling. Watch out for them and report them to the package owner and/or on bugzilla.
  

In the example bootchart we can also immediately see the effect of some components, which are slow or can be started on demand:

• rpc services (disturbing hacks to start nfs-utils services on demand (not entirely serious))
• cupsd ((RFC, PATCH) start cups on demand, using xinetd)
• fedora-system-keyboard, which starts the whole python interpreter with a lot of I/O happening for that. (https://bugzilla.redhat.com/show_bug.cgi?id=483817)
  
• dellWirelessCtl has a lot of I/O here.
• HAL is growing and growing and takes more and more time to startup.
• NetworkManager starting wpa_supplicant even for static network interfaces which do not require authentication and DHCP. So the service of wpa_supplicant is never used. (https://bugzilla.redhat.com/show_bug.cgi?id=482823)
• Xorg is having a significant time with no I/O and full CPU
• Bluetooth and IRDA being started (start the bluetooth service via udev)
• cpuspeed with no I/O and CPU
• microcode has a sleep (microcode_ctl busy polling microcode_ctl ships a pointless init script)

An Ideal Boot Setup

In an ideally boot setup CPU and I/O is maxed out the whole boot process.

Ways of how to achieve this:

• readahead all files used to fill the memory disk cache in parallel to the normal boot process
  
• avoid sleeps
• run services which do not depend on each other in parallel

An ideal init process would take the premier goal (in the desktop case it would be the login screen), start everything what is needed for it with first priority and start the rest in parallel or delayed with low (I/O and CPU) priority.

What is needed to achieve that:

• Dependencies! This is why I once started the LSB Header bugzilla tracker. https://bugzilla.redhat.com/show_bug.cgi?id=246824
• An init process, which knows about the dependencies and the primary goal and sets up the I/O and CPU priorities.

What you can do now to speed up your boot process

• install and run prelink
• install and run readahead / preload
• maybe defragment a heavy fragmented filesystem?
  

What to keep in mind as a developer

• try to start services on demand (might be hardware dependent, use udev/hal or just look in /sys if the hardware is even there)
  
• do not cause heavy I/O on start up (like reading a whole big databases in memory or reading big log files, or using an interpreter (like fedora-setup-keyboard)), or use a low I/O priority
  
• do not use sleep 1, if you are busy polling, use "sleep 0.2" or find another mechanism

• If your udev rule does not have to be executed at boot time, consider using the ENV{STARTUP}!="1" condition.

What did the test day achieve?

As an immediate outcome of the test day, I modified readahead and released readahead-1.4.8 with the following changes:

• set low I/O priority (no more regression in boot time with readahead)
• moved data files from /etc/readahead.d to /var/lib/readahead
• don't start readahead from readahead.event, if system has less than 384MB

Time taken from entering the encrypted root disk password until the password can be entered (after pressing return in gdm). The 10 second wait in nash is ignored here (which really annoys me and seems to be fixed in newer mkinitrd versions).

Default Live CD Installation:  39s (bootchart)

After installing readahead and running one collection boot process: 36s (bootchart)

At this point, I recognized that all processes (like newaliases), which call a fsync(), let the boot process wait until all data is written to disk. This is the same effect as the firefox sqlite fsync bug.

Mounting the root filessystem with relatime and turning off ordered data writing for the journal with

# tune2fs -o journal_data_writeback /dev/root

improved the situation (even though data might be old on the disk after a crash, but ext3 does not force the disk to empty the write cache anyway).

Turning off setroubleshoot and fixing https://bugzilla.redhat.com/show_bug.cgi?id=476023 and https://bugzilla.redhat.com/show_bug.cgi?id=476028: 32s (bootchart)

Turning off bootchart: 30s

So all in all we have nearly accomplished the 30 Second Startup Feature.

To reach the 20 Second Startup Feature, we really have to tackle setroubleshootd. Also we might start to move basic services to upstart and start them in parallel (bootchart with some services moved). Parallel booting will show no benefits with readahead and a small amount of active services, but the more services are turned on, the more you benefit with a parallel boot setup. Moving more basic modules to be compiled in the kernel also would gain some seconds. Speaking about modules, I ported Jakubs modprobe patch to the recent 3.6pre1 module-init-tools version. Though it nearly halves I/O, it would only safe us a fraction of a second here (not recognizable).

In the end, we also have to extend our view to things that happen after the user logs in (bootchart) and do an extended analysis. Work is also in progress by Gnome developer Behdad Esfahbod.

Follow the discussion on fedora-devel.

To measure IO, I installed a systemtap script to run as soon as rc.sysinit starts.

#! /usr/bin/env stap
# modified traceio.stp
# Copyright (C) 2007 Red Hat, Inc., Eugene Teo <eteo@redhat.com>
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License version 2 as
# published by the Free Software Foundation.
#

global device_of_interest, dev, reads, writes, total_io

probe begin {
  /* Hack! Insert your MAJOR, MINOR of the 
     device you are interested in */
  device_of_interest = MKDEV(253, 1)
}

probe vfs.read.return {
        if (dev == device_of_interest)
        reads[execname()] += $return
}

probe vfs.write.return {
        if (dev == device_of_interest)
        writes[execname()] += $return
}

probe timer.s(1) {
    foreach (p in reads)
        total_io[p] = 0
    foreach (p in writes)
        total_io[p] = 0
    foreach (p in reads)
        total_io[p] += reads[p]
    foreach (p in writes)
        total_io[p] += 5 * writes[p]
    foreach(p in total_io- limit 10)
        printf("%15s r: %8d KiB w: %8d KiB\n",
            p, reads[p]/1024,
            writes[p]/1024)
        printf("\n")
    # Note we don't zero out reads, writes,
    # so the values are cumulative since the script started.
}

Because on a EeePC disk writes are very slow (5 times slower than reading) they are weighted with factor 5.

From rc.sysinit start to the gdm login screen, the top 5 IO tasks are on my Live-CD standard installation:

• modprobe: I wonder what happened to Jakub's modprobe speedup patches.
• setroubleshootd: should really be more lightweight and needs a cleanup.
• gconfd-2, xkbcomp: Behdad has currently been looking at the login process, which hopefully improved the situation a bit.
  
• rpcbind: will have to investigate, why it reads so much.

Now, if you want to improve Fedora's boot speed, here is a starting point.

Monitor Colors

Your monitor colors could be different than the one of your friend. This can be corrected calibrating the monitors with a colorimeter and e.g. Argyll.

Color Profiles

Most photos have a color profile embedded. This color profile defines, where the rgb values are in the colorspace. Some software is aware of it. Some is not.

Check out this color profile browser test  (german only). Especially this picture:

or this one:

Now, here comes the practical part. Nils Philippsen wrote a small python module, which greatly simplifies the use of PolicyKit for python applications. Downloads, git repo and more information, along with simple example code can be found on http://fedorahosted.org/python-slip/

In its current form it uses D-BUS communication to check policykit action_ids, which will change, as soon as the python bindings for PolicyKit will be released (hint, hint!).

If you have questions or patches, just send a mail to me or Nils.