Boot process becomes much longer after upgrading from 4.0.10 to 4.1.0-r2. I suspect that it happens due to unconditional inclusion of eudev (and devicemanager) to cpio archive. genkernel-4.0.10 initramfs: Startup finished in 2.790s (firmware) + 405ms (loader) + 1.960s (kernel) + 1.506s (userspace) = 6.663s. genkernel-4.1.0-r2 initramfs: Startup finished in 2.791s (firmware) + 430ms (loader) + 2.975s (kernel) + 1.587s (userspace) = 7.784s. Kernel boot time is increased by 50%. initramfs became 2.5 times larger: -rwxr-xr-x 1 root root 4585135 Jul 31 12:27 initramfs-5.7.11-gentoo.img -rwxr-xr-x 1 root root 4585151 Aug 1 17:27 initramfs-5.7.12-gentoo.img -rwxr-xr-x 1 root root 4585206 Aug 6 21:25 initramfs-5.7.13-gentoo.img -rwxr-xr-x 1 root root 4585206 Aug 10 11:00 initramfs-5.7.14-gentoo.img -rwxr-xr-x 1 root root 4588854 Aug 14 14:28 initramfs-5.7.15-gentoo.img -rwxr-xr-x 1 root root 11617525 Aug 21 11:56 initramfs-5.7.16-gentoo.img For me it doesn't look like improvement.
Set gk.log.keep=yes command-line argument and reboot. This will create /genkernel-boot.log. Please attach this file to this bug.
Created attachment 655972 [details] genkernel-4.1.0-r2 boot log rootfs location was found on first step. All modprobes and udevd are not required to boot.
Created attachment 655976 [details] genkernel-4.0.10 boot log
I must admit that I am not sure if I can take this bug report seriously. You are complaining about 1 additional second your system now spends in initramfs. Sorry, but I am not going to spend any time on this issue: udevd in general helps systemd users and for everyone else it will help to avoid race conditions. Don't get me wrong here but if you have a specific system which can't have such problems and that second is critical for you, maybe genkernel isn't the tool for you.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/genkernel.git/commit/?id=6bc4264df660ff6f639cdd9625f5f0da20418e25 commit 6bc4264df660ff6f639cdd9625f5f0da20418e25 Author: Thomas Deutschmann <whissi@gentoo.org> AuthorDate: 2020-08-21 18:44:32 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2020-08-21 18:44:32 +0000 defaults/initrd.scripts: log_msg(): Log milliseconds This will allow us to see more in detail where initramfs spent time. Bug: https://bugs.gentoo.org/738378 Signed-off-by: Thomas Deutschmann <whissi@gentoo.org> defaults/initrd.scripts | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
I am curious, maybe you want to test again with the patch from previous post (which can also be applied against genkernel-4.0.10) so we get a little more insight? It's probably the udevd start itself but who knows...
(In reply to Thomas Deutschmann from comment #4) > I must admit that I am not sure if I can take this bug report seriously. You > are complaining about 1 additional second your system now spends in > initramfs. > > Sorry, but I am not going to spend any time on this issue: udevd in general > helps systemd users and for everyone else it will help to avoid race > conditions. Don't get me wrong here but if you have a specific system which > can't have such problems and that second is critical for you, maybe > genkernel isn't the tool for you. My Gentoo installations are based on systemd, but I don't need udev in initramfs. systemd does its job just well, after mounting root FS. genkernel 4.0.10 doesn't add eudev to initramfs and I had no problem with it. I use Gentoo for HTPC, boot time is important. Currently it takes ~ 7 seconds from powering on to Kodi screen. Last kernel optimisation saved 0.4 seconds (2.340 -> 1.960). Additional 50% of kernel boot time is not improvement for me. Mandatory eudev in initramfs doesn't give me any improvement, I just don't need it. Larger initramfs archive is just a waste of my (limited) disk space. I will test with nanoseconds patch.
Created attachment 656414 [details] genkernel-4.0.10 boot log with nanoseconds
Created attachment 656416 [details] genkernel-4.1.0-r2 boot log with nanoseconds
Booting with genkernel 4.0.10 initramfs takes 0.29 second, 4.1.0-r2 initramfs takes 1.18 second. Version 4.1.0 doesn't bring any improvements. udev was optional for 4.0.10. Why not not to make it optional for 4.1.0 as well?
Thank you for the new logs. However, we will not change anything. And you are also mixing genkernel-next with genkernel: We never supported both in genkernel and we won't start doing this. Our maintenance resources are limited -- we cannot double test amount just to support two device managers because of 1s.
(In reply to Thomas Deutschmann from comment #11) > Thank you for the new logs. > > However, we will not change anything. And you are also mixing genkernel-next > with genkernel: We never supported both in genkernel and we won't start > doing this. Our maintenance resources are limited -- we cannot double test > amount just to support two device managers because of 1s. I never tried genkernel-next. I'm referring initramfs generation process. With genkernel-4.0.10: * initramfs: >> Initializing ... * >> Appending devices cpio data ... * >> Appending base_layout cpio data ... * >> Appending auxilary cpio data ... * >> Appending busybox cpio data ... * >> Appending blkid cpio data ... * >> Appending btrfs cpio data ... * >> Appending modprobed cpio data ... * >> Appending modules cpio data ... * >> Appending linker cpio data ... * >> Deduping cpio ... * >> Pre-generating initramfs' /etc/ld.so.cache ... * >> Compressing cpio data (.lz4) ... With genkernel-4.1.0: * initramfs: >> Initializing ... * >> Appending devices cpio data ... * >> Appending base_layout cpio data ... * >> Appending eudev cpio data ... * >> Appending devicemanager cpio data ... * >> Appending auxilary cpio data ... * >> Appending busybox cpio data ... * >> Appending blkid cpio data ... * >> Appending btrfs cpio data ... * >> Appending modprobed cpio data ... * >> Appending modules cpio data ... * >> Appending linker cpio data ... * >> Deduping cpio ... * >> Pre-generating initramfs' /etc/ld.so.cache ... * >> Compressing cpio data (.lz4) ...* Notice "eudev" and "devicemanager" itmes. I had an impression that with genkernel 4.0.10 they were optional, depending on configured modules (llvm etc.)
(In reply to Karlson2k from comment #12) > I had an impression that with genkernel 4.0.10 they were optional, depending > on configured modules (llvm etc.) I mean LVM, mdadm and others.
This is probably just bad naming: I am using "devicemanager" to add dmsetup which is part of LVM. Prior genkernel-4.1, this was really only built and appended to initramfs if you enabled LVM support (--lvm). Because in udev world, dmsetup is used in most udev rules related to block devices based on devicemapper, we are now appending dmsetup stuff in its own function (https://gitweb.gentoo.org/proj/genkernel.git/tree/gen_initramfs.sh?h=v4.1.0#n181). Full LVM support has additional requirements.
