You won't find such an utility...
There are three steps in booting the current Linux systems.
1) grub selects kernel + initrd.
This system runs from a filesystem in the initrd. There are no disks involved other than the copy of the kernel into memory, and the copy of the initrd into memory. Then the system decompresses the cpio file (the initrd) into a ramdisk; mounts it as root and starts running the startup from there The memory used for the initrd file is released.
2) the initrd disk has a startup procedure that scans the system and initializes/loads any drivers needed to access the local disks. This includes any raid disks, logical volumes (LVM), encrypted filesystems... Once it has identified the appropriate root filesystem it mounts it on /mnt (remember that it is still running from a ramdisk). It then uses a "pivot_root" procedure to exchange the mounted root (the ramdisk) with the mounted root (on /mnt).
3) Once step 2 is completed, the /mnt is dismounted (the ramdisk is released and returned to general memory) and then proceeds to execute the init program from the now mounted root.
Until step 3 is completed, no logs are really available, and the log you see from dmesg is all you will get.
The dmesg log time stamp is in seconds.nanoseconds (http://linuxaria.com/article/how-to-...adable?lang=en
), so that is possibly the information you want. It doesn't include the time needed to load the kernel+initrd and decompress the initrd into the ramdisk.
The dmesg log is created in memory during the startup phase. It is copied to disk as one of the first things done to start (or append to) a /var/log/messages file.
The data in memory is in a ring buffer - and that means that it can wraparound (when the buffer is filled, it starts overwriting data at the beginning). For small systems with few devices, this shouldn't be a problem. Large systems with lots of disk drives/peripherals may generate enough log to cause a loss of data.
This is the default. There have been some hacking around done to bypass the initrd entirely. This depends on the kernel itself to have the appropriate drivers (and a filesystem) built into the kernel so that they don't need to be loaded. This can speed booting by eliminating the initrd load, decompression into a ramdisk, and the associated memory allocation/deallocation time (it may actually knock off about 3-5 seconds total, but I don't have any actual times).