# slow start time when rootfs/initramfs

## malcolmmaya

Hej all,

My gentoo machine is a bit slow at starting. It mainly wait at a line that says:

```

trying to unpack rootfs as initramfs

```

If I remember it correctly. I tried searching about this topic but could not find much information as to why it is slow. I read the initramfs article but that did not help me clarify why that would be slow. Any tips about this ?

Ok some update here is the incriminating part of the log file of the boot:

```

[    0.275611] NET: Registered protocol family 2

[    0.275839] TCP established hash table entries: 65536 (order: 7, 524288 bytes)

[    0.276037] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)

[    0.276238] TCP: Hash tables configured (established 65536 bind 65536)

[    0.276353] UDP hash table entries: 4096 (order: 5, 131072 bytes)

[    0.276455] UDP-Lite hash table entries: 4096 (order: 5, 131072 bytes)

[    0.276597] NET: Registered protocol family 1

[    0.276691] pci 0000:00:02.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff]

[    0.277288] PCI: CLS 64 bytes, default 64

[    0.277324] Trying to unpack rootfs image as initramfs...

[    5.396096] Freeing initrd memory: 38272K

[    5.396183] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)

[    5.396270] software IO TLB [mem 0xba0af000-0xbe0af000] (64MB) mapped at [ffff918efa0af000$

[    5.396465] RAPL PMU: API unit is 2^-32 Joules, 4 fixed counters, 655360 ms ovfl timer

[    5.396587] RAPL PMU: hw unit of domain pp0-core 2^-14 Joules

[    5.396670] RAPL PMU: hw unit of domain package 2^-14 Joules

[    5.396752] RAPL PMU: hw unit of domain dram 2^-14 Joules

[    5.396835] RAPL PMU: hw unit of domain pp1-gpu 2^-14 Joules

```

----------

## dib.gentoo

Hi, I have the exact same issue. I tried different compression methods, but the speed does not change significantly.

----------

## NeddySeagoon

malcolmmaya,

```
[    0.277324] Trying to unpack rootfs image as initramfs...

[    5.396096] Freeing initrd memory: 38272K 
```

That's the initrd being decompressed. Doing its thing, whatever that is, then being thrown away.

You don't get any messages while the initrd does its thing, probably because the init script in the initrd does't generate any.

How did you make your kernel and initrd?

Most users don't actually need an initrd at all but that requires that the kernel be configured to suit the hardware it will run on, rather than a generic run anywhere kernel and initrd set.

There are two approaches. Build your own kernel that does not need an initrd, if that's possible for your use case.

Unpack the initrd, add some echo statements to the initrd init script, so you can see what its doing and repack the initrd to test.

The initrd is a compressed cpio archive of other cpio archives. 

If you must have an initrd, there is some middle ground too. Make a kernel that only needs an initrd for the user space programs required to mount root, then make your own initrd.

I'm in that group. I have root in lvm2 on raid5, so my initrd has to assemble the raid set and start LVM before root is even visible to the kernel.

----------

## Goverp

malcomlmaya

It's taking a bit over 5 seconds to process the initramfs.  That looks to me like a 5 second wait for something to come ready, and .1 sec for the actual work.  What sort of device are you booting from, and is your initramfs built into the kernel or a separate file, oh, and what method (grub, lilo, rEFInd, ...) of booting are you using?

FWIW, on the boxes I've compared, lzop is the fastest compression/decompression, much faster than gzip (the default), but I doubt either would take as much as 1 sec for any initramfs except something huge (such as the all-modules-included emergency ones used by Arch and other distros where you normally don't roll your own kernel).

----------

## NeddySeagoon

My initrd boot sequence is a bit scary ...

```
[    1.738030] Trying to unpack rootfs image as initramfs...

[    1.744900] Freeing initrd memory: 8524K
```

because its still running fsck later.

```
[    4.617351] EXT4-fs (dm-10): mounted filesystem with ordered data mode. Opts: (null)

[    6.922710] EXT4-fs (dm-11): mounted filesystem with ordered data mode. Opts: discard,user_xattr

[    7.429237] EXT4-fs (dm-12): mounted filesystem with ordered data mode. Opts: discard
```

That's root, /usr and /var being mounted in the initrd. 

Its difficult to pick that out of dmesg as its embedded in all the other kernel startup messages.

My initrd is user space tools only, no module loading. Its not changed since April 2009.

Maybe that 8524K is the compressed image space being freed, not the actual running decompressed initrd.

----------

## dib.gentoo

After your questions I tried different things.

I am using genkernel and played around with the configuration possibilities.

First result was: The initramfs was suddenly a lot smaller, but my wireless adapter (intel) did not work anymore - obviously a firmware problem. But: Startup time was so fast that I could not see the anymore wether the initramfs was loaded at all   :Very Happy: 

One of the things was removing the command line parameters of genkernel, and using the /etc/genkernel.conf for configuration. During this process I also removed the --firmware parameter.

Next thing I tried was setting the firmware options in the .conf: I tried different settings

Firmware_Install = yes: Did not work, no wlan

With firmware=yes and sys-kernel/linux-firmware installed, wlan works again - but the initramfs is nearly as big as my /boot-partition (which is 256M). AND: Boot is slow again, but there is something different.

Now, directly on startup (I tried refind on one system and directly with grub on another system), the initramfs is loaded right in the beginning (so, it is the second line on the boot screen after the kernel version), and takes 10+ seconds.

compression algorithm is "fastest", which results in LZ4, but unpacking the initramfs not during boot, but unpacking it with lz4 by hand in my bash takes less than 1sec

Sidenote: I also upgraded the kernel from 4.18.x to 4.19.1

----------

