On CentOS/RHEL, it is sometimes complex to determine which portion of the boot sequence takes a long time. There are several different events happening during the boot sequence, and sometimes default level of logs are not sufficient to determine the component causing the issue. In that case, the steps described in this post can be used to gather more data about a possible root cause of the slow booting sequence.
1. Edit the kernel line of the matching grub menu entry in /etc/grub.conf. For example:
[...] root (hd0,0) kernel /vmlinuz-3.8.13-68.3.4.el6uek.x86_64 ro root=/dev/mapper/vg_ol67-lv_root rd_NO_LUKS LANG=en_US.UTF-8 rd_LVM_LV=vg_ol67/lv_swap rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto rd_LVM_LV=vg_ol67/lv_root KEYBOARDTYPE=pc KEYTABLE=be-latin1 rd_NO_DM rhgb quiet [...]
And append the following parameter to it:
initcall_debug
For examples, a resulting kernel boot argument is shown below:
[...]
root (hd0,0)
kernel /vmlinuz-3.8.13-68.3.4.el6uek.x86_64 ro root=/dev/mapper/vg_ol67-lv_root rd_NO_LUKS LANG=en_US.UTF-8 rd_LVM_LV=vg_ol67/lv_swap rd_NO_MD
SYSFONT=latarcyrheb-sun16 crashkernel=auto rd_LVM_LV=vg_ol67/lv_root KEYBOARDTYPE=pc KEYTABLE=be-latin1 rd_NO_DM rhgb quiet initcall_debug
[...]
And reboot the system, using this menu entry in the grub menu when booting.
2. After appending this parameter, both the serial console and the dmesg command output will also print the time needed for an init call to complete. For example:
calling init_autofs4_fs+0x0/0x2a [autofs4] @ 1581 initcall init_autofs4_fs+0x0/0x2a [autofs4] returned 0 after 7463 usecs