As in thread title. I know that Archlinux have such hook, and then it split “kernel” into “kernel” and “initramfs”.
That is quite usefull, since it can show if initrd is bootleneck in our system.
Update:
Is it possible to compres initrd in opensuse? Or to change compression method/options?
# file initrd-3.7.6-1.2-desktop
initrd-3.7.6-1.2-desktop: gzip compressed data, from Unix, last modified: Fri Feb 22 09:24:01 2013, max compression
It seems to already be compressed.
Add necessary scripts to /lib/mkinitrd/scripts.
I guess it is wrong forum for this question, Programming/Scripting would be more appropriate.
Unless there is already such script… Or config variable in some file.
There is not.
Found code repsonsible for compression of initrd
/lib/mkinitrd/setup/93-done.sh
COMPRESSION=“gzip -9”
Now how can I check if OpenSuSE kernel (*-desktop) support LZMA loading? Where do I find configs used for building that kernel?
CONFIG_RD_LZMA=y
/proc/config.gz
LZMA compression do not help start up time. Its even a bit longer.
Dracut have option rd.timestamp that may be attached to kernel options. But that seam to not work with systemd-analyze.
(Shame as dracut can build a bit smaller initrd’s)
I’m curious how you might think that adding a timestamp to something related to initrd might be helpful (if it’s even possible). Someone may correct me, but it seems to me that the initrd has to be uncompressed before the boot can progress to the point where something like systemd-analyze might be able to do its thing.
In fact, this archlinux forum thread seems to support my suspicions
https://bbs.archlinux.org/viewtopic.php?pid=1220448
Towards the end of the thread, it’s suggesting that the timestamp hook and/or binary isn’t needed for whatever you’re trying to analyze, and it’s problematic the value of whatever you may be trying to analyze.
Am also curious if you suspect an issue or if this is mainly an academic exercise (eg curiousity).
TSU
Timestamp should be appended as first thing intird do.
Than systemd-analyze report initrd as separate entity.d
That way you can see how much time did you gained by various optimizations. (Removing unneeded modules, changing compression, pushing mounting to initrd instead of systemd, whatever).
Sure kernel do spent some time on setting up initrd but AFTER THAT initrd perform its tasks.
Seeing split also may help me understand why cutting my initrd by 2/3 only resulted in 1 second gain (maybe its that initrd is already fast? and then I should go hunt and blacklist any/all unneeded kernel modules?)
Anyway for this feature to work you just need “RD_TIMESTAMP” enviroment variable to be filled with timestamp of certain kind.