I’m exploring ways to shave a few seconds off of my boot time, and I came across a post that stated, “my initrd is pretty small–doesn’t really load much–and Arch also defaults to using zstd which is also faster to decompress versus gzip.”

What compression does Pop! use for initrd and the kernel? When I run ls -al /boot, I see files such as 14M vmlinuz-6.4.6-76060406-generic and 119M initrd.img-6.4.6-76060406-generic. Are these compressed?

Lastly, is there a way to choose the compression of these boot files without a custom kernel build? Or is what I’m trying to do “off the beaten path” and going to lead to “you have to compile your own kernel from here on out”?

  • TOR-anon1@lemmy.world
    link
    fedilink
    English
    arrow-up
    6
    ·
    9 months ago

    Go to /etc/initramfs-tools/initramfs.conf and change:

    compress=gzip
    

    to

    compress=ztsd
    

    and run:

    sudo update-initramfs -u -k all
    
        • canadaduaneOP
          link
          fedilink
          English
          arrow-up
          1
          ·
          9 months ago

          How would I check? Like this?

          $ zstd -l vmlinuz-6.4.6-76060406-generic 
          Frames  Skips  Compressed  Uncompressed  Ratio  Check  Filename
          File "vmlinuz-6.4.6-76060406-generic" not compressed by zstd 
          
            • canadaduaneOP
              link
              fedilink
              English
              arrow-up
              1
              ·
              9 months ago

              Wow, this told me much more than I expected; however, I’m still not sure if it’s zstd:

              /boot/vmlinuz-6.4.6-76060406-generic: Linux kernel x86 boot executable bzImage, version 6.4.6-76060406-generic ([email protected]) #202307241739~1694621917~22.04~ac5e1a8 SMP PREEMPT_DYNAMIC Wed S, RO-rootFS, swap_dev 0XD, Normal VGA
              

              bzImage sounds like…bzip2, maybe?

              • TOR-anon1@lemmy.world
                link
                fedilink
                English
                arrow-up
                1
                ·
                9 months ago

                No. BZ stands for Big zImange. The kernel is compressed.

                To see what compression was used:

                zgrep CONFIG_KERNEL_ /proc/config.gz
                

                Try file on the initrd instead.

                • canadaduaneOP
                  link
                  fedilink
                  English
                  arrow-up
                  1
                  ·
                  9 months ago

                  Ah, thanks! Slightly different location, but basically the same. Here we go:

                  $ grep CONFIG_KERNEL_ /boot/config-6.4.6-76060406-generic
                  # CONFIG_KERNEL_GZIP is not set
                  # CONFIG_KERNEL_BZIP2 is not set
                  # CONFIG_KERNEL_LZMA is not set
                  # CONFIG_KERNEL_XZ is not set
                  # CONFIG_KERNEL_LZO is not set
                  # CONFIG_KERNEL_LZ4 is not set
                  CONFIG_KERNEL_ZSTD=y
                  

                  So the kernel is “zstd” compressed.

                  OTOH, I’m not sure if this means anything about initrd (ASCII cpio archive??)

                  $ file /boot/initrd.img-6.4.6-76060406-generic 
                  /boot/initrd.img-6.4.6-76060406-generic: ASCII cpio archive (SVR4 with no CRC)
                  
    • canadaduaneOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      9 months ago

      When I check this file, it is already set at COMPRESS=zstd. However, I’m not sure if it’s working as I think, because the vmlinuz-6.4* kernel file is not a zstd file? Maybe it uses zstd for just a portion of the binary…

  • CameronDev@programming.dev
    link
    fedilink
    English
    arrow-up
    3
    ·
    9 months ago

    I’d be curious to know how uncompressed fairs if you test it. But i think you’re really getting into minimal gains territory…

  • surewhynotlem@lemmy.world
    link
    fedilink
    English
    arrow-up
    2
    ·
    9 months ago

    I wouldn’t focus on faster decompression.

    Disk read speed is almost always the bottleneck. I think you’ll find that smaller file sizes, even if the decompress takes slightly longer, are faster overall because they save disk I/O.

    YMMV based on your hardware, of course.