Boot improvements

· by Raghu Rajagopalan · Read in about 3 min · (448 words) ·

So the long standing issue with mouse becoming janky in parallel login sessions drove me to desperation. Having posted online on kreddit, askubuntu and and getting zilch, I finally decided to install another distribution in parallel and see if the issue persists. Decided to give PopOS (ubuntu derivative by System76 folks) a shot but the installation didn’t go too well. To boot, I also managed to screw up my current installation by picking the same /boot while trying to install Pop OS. That adventure ended happily once I chrooted, fixed up boot and got back to kde neon and noticed a sluggish mouse on the first session itself. This was new and interesting and dmesg was being spammed with nvidia driver mismatch errors (I was using a kernel installed by Pop with KDE neon). That indicated a nvidia issue and sure enough, here was the issue that had troubled me no end!

Once that got sorted out I was on a high and decided to clean up a bit and also fix boot animation that got screwed. In roughly sequential order

  1. Clean up residual config

    dpkg -l |grep ^rc| awk '{print $2}'| sudo xargs dpkg --purge

    Resulted in some errors (I still have mintsystem) which will not go - but overall just housecleaning

  2. Set boot splash theme in KDE Settings Manager

  3. Now I shouldn’t need the above if I have KMS (which I should have) - but nevertheless, here’s what I did for KMS

    • Grub config

      # /etc/default/grub
      GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nvidia-drm.modeset=1"
      > sudo update-grub2
    • Initramfs

      # /etc/initramfs-tools/modules
      nvidia nvidia-drm modeset=1 NVreg_RegisterForACPIEvents=1 NVReg_EnableMSI=1 NVreg_RegistryDwords=RMUseSwI2c=0x01;RMI2cSpeed=100
      > sudo update-initramfs -u -k `uname -r`
      # confirm if modules are included
      > lsinitramfs /boot/initrd.img-4.18.0-22-generic |less
  4. Now from eye-candy to boot performance. I was thinking that I’d have to profile with bootchart etc that I’d come across but never used…​ Turns out that systemd has a few tricks up it’s hand

    # boot time summary
    # longest pole on critical path ordered by time
    systemd-analyze blame
    # Similar - but in a chain form
    systemd-analyze critical-chain

    So my boot was taking upwards of 40s to 1min and that shouldn’t be with an SSD.

    • Culprits

      • docker.service - 15s - replace with docker.socket

      • snapd - 8s - I wasn’t using any snap packages, so - sudo apt autoremove --purge snapd

      • systemd-journal-flush - 5s - vacuum as advised

I think that’s about it - but now here’s what systemd-analyze now says:

raghu@home-desktop  ~/blog   master  systemd-analyze
Startup finished in 5.315s (kernel) + 10.297s (userspace) = 15.612s reached after 10.287s in userspace