enter image description hereI want to speed up the boot time, and I followed a tip to:

  1. Edit "/etc/default/grub" and change the line GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" to GRUB_CMDLINE_LINUX_DEFAULT="quiet splash profile";
  2. Run sudo update-grub2 and boot up the machine;
  3. Edit the grub config file again and remove profile from GRUB_CMDLINE_LINUX_DEFAULT;
  4. Update grub again and reboot.

But the result was a increase of a boot time of 10 sec according to dmesg output!

What went wrong? Why this tip doesn't work for me? How to revert this setting? Where this profile file is saved in Xubuntu? Can I delete this new profile with no problems?

  • Are you sure that the"profile" is taken out from grub.cfg? Please check it – meskobalazs Oct 13 '15 at 7:44
  • Which tip did you follow? Afaik the profiling data is by default written to /proc/profile, so it won't persist on reboot. If you removed the option, you're back to normal. Besided, collecting profiling data does nothing to speed up the boot process. It's up to you to analyse the data and make optimizations. – Nephente Oct 13 '15 at 7:56
  • @Nephente Really? I've done a bit of research and found really old (<2010) guides that ask you to do what the OP did, ie just boot once with the profile option and enjoy less bootime. Maybe it's not like that anymore? – daltonfury42 Oct 13 '15 at 8:03
  • @Nephente, This tip is every where when we search google for how to speed up boot time on xubunu(ubuntu), please i didn't understand how to revert that back to normal, and why this tip doesn't work for me? maybe this tip doesn't work anymore. – vladimir pavloski Oct 13 '15 at 13:23
  • 1
    Could you please append this to your question by editing it and not post any output in the comment. Thanks! – Nephente Oct 14 '15 at 9:25

One remark at the beginning: Although you're content with Ubuntu 13.10, I would still highly recommend upgrading to 14.04 LTS. Saucy has reached end-of-life for over a year now, which means you did not receive any updates for it since then - not good security-wise. Also, technically EOL releases are off-topic here.

The kernel boot parameter profile is a trigger for readahead profiling at boot-time. If it is set a readahead daemon will monitor the boot process , look for files that are loaded during boot and write an appropriate list file. This file will be used on the next boot and should cut down boot-time by reducing hard-drive seeks.

There are a few such readahead mechanisms that came and went over the years. Here is my take on them and I hope this to be more or less accurate.

Original readahead (deprecated)

The last version found in the the Ubuntu archives dates back to 2005. You can't install it anymore through the repository. I don't know when it was superseeded, but it must have been sometime before 10.04.

  • profile stored in /etc/readahead/boot.
  • trigger profiling by moving boot and booting with kernel parameter profile, although this bug report suggests its an undocumented and developer-only option.

readahead from Fedora

Originally from Fedora and still used there for systems not booting with systemd.

  • Ubuntu package is readahead-fedora. Available through the repository.
  • superseeds the original readahead
  • profiles stored in /etc/readahead.d/custom.{early,later}
  • profiling triggered by either
    • touch /readahead_collect or
    • setting kernel parameter profile on boot.
  • automatically profiles at least every month
  • Superseeded on Ubuntu by ureadahead

The original readahead and readahead-fedora created a list of files needed at boot time. This list would be read at boot in an order that minimizes hard-drive seeks.


This is the default on Ubuntu since - I think - 10.04.

  • Pre-installed
  • Really creates a page file which is loaded into memory at boot.
  • Stored in /var/lib/ureadahead/pack. To force profiling at next boot, remove this file.
  • Installs dpkg triggers, that fire and update the page file whenever something is installed that relates to init.

Ubuntu >= 15.04

systemd is the default init system since vivid. It brought its own readahead mechanism. ureadahead does not work with systemd. But even systemd-readahead is now unmaintained and deprecated, since apparently everbody owns a SSD these days... ureadahead is used on Vivid when booting with upstart.

As expected your system has ureadahead installed, which doesn't take the profile parameter. Why you would experience prolonged boot time after setting profile is not understandable. If you also applied the second hack in the how-to you followed (CONCURRENCY=...), this might be the culprit. upstart should take care of that on its own.

As said before, to force ureadahead to re-profile, remove the pack file

sudo rm /var/lib/ureadahead/pack

and possibly any other .pack in that directory. Be sure to login quickly after boot, because ureadahead records a bit even after booting has finished. This way it will hopefully also include the unity shell or whatever you're using.

If you want a really good grasp on what is taking how long to start, take a look at bootchart. It generates a graphical representation of the boot process.

| improve this answer | |
  • I will do your recomendations, thanks for the remarks. – vladimir pavloski Oct 15 '15 at 8:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.