Home / ubuntu / Questions / 684877
Accepted
vladimir pavloski
Asked: 2015-10-13 23:35:37 +0800 CST

Why using "profile" in grub to optimize boot time doesn't work for me? How do I revert the effect?

  • 772

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?

boot

1 Answers

  1. Best Answer

    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.

    ureadahead

    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.

    • 8