Okay... so I did something which I was probably not supposed to do. I have a 256 GB SSD. GParted from a live Kubuntu CD showed that I have 16gb of unallocated space. I wanted to add it to the root partition. However, there were swap and boot partitions between the unallocated space and the root partition, so I first added the space to boot partition, then shrunk the boot partition from left, then repeated the same with swap, and finally added it to root partition. To be safe, I reinstalled grub. Now, my Windows continues taking around 10s to boot, while Kubuntu takes more than a couple of minutes. Why is this so? If I did break something, why does it boot at all? Thanks a lot!

  • Did you recreate the swap partition? I've had a similar issue when I've messed with the swap partition. – Oskar Skog Jun 14 '20 at 8:50
  • @Oskar Skog Yes I did. But how to know that my system uses it, or does it do by default on detecting a swap partition? – Akshat Vats Jun 14 '20 at 9:27
  • Ok swap wasn't activated. Activated it. Will try rebooting. – Akshat Vats Jun 14 '20 at 9:38

Ok, I think I figured out your problem; the system looks for the resume partition, which is the swap actually and was changed.

When you boot do you see a graphic screen? Press something to view messages. The delay is usually presented (waiting... something like that)

Try this: disable resume partition

Unless you need hibernation; in that case you need to find the new uuid of swap partition and correct /etc/initramfs-tools/conf.d/resume file.

Also check the /etc/fstab file. You should correct this one too, in order to have swap available to the system.

  • My /etc/initramfs-tools/conf.d/ is empty – Akshat Vats Jun 14 '20 at 9:44
  • ok. Check /etc/fstab. There must be a line mentioning 'swap'. Is it using UUID or label or device to mount? – Krackout Jun 14 '20 at 9:45
  • # swap was on /dev/nvme0n1p6 during installation UUID=3e406cde-3fb9-4a61-8f9b-94dbabf496a6 none swap sw 0 0 – Akshat Vats Jun 14 '20 at 9:47
  • blkid says UUID is this: c990c576-f89b-4b9b-8101-7eda135e2503 and PARTUUID: 0fe287ae-6eab-4320-9d92-5fe5cd291678 – Akshat Vats Jun 14 '20 at 9:48
  • 1
    Because you've just located the problem! Use the UUID of blkid, correct the one in fstab. – Krackout Jun 14 '20 at 9:52

This should be a comment but I don't have enough points.

Try systemd-analyze and systemd-analyze blame. The 1st one shows the time it took to boot, the 2nd shows how much time each service takes to start. It'll help you find where the delay occurs.

  • The firmware took 2.731s, loader 4.365, kernel 33.455s, userspace 1min 39.228s. That means kernel and userspace are taking abnormal time. Solution? – Akshat Vats Jun 14 '20 at 9:29
  • systemd-analyze blame results? – Krackout Jun 14 '20 at 9:29
  • It is rather long, how do I tell you? – Akshat Vats Jun 14 '20 at 9:31
  • free -m says 0 swap size – Akshat Vats Jun 14 '20 at 9:31
  • Check the time for each service, they are sorted. Locate the one or ones that delay. – Krackout Jun 14 '20 at 9:32

Found the solution!! My swap space was in /dev/nvme0n1p6, so I ran: sudo swapoff -a sudo mkswap -L swap /dev/nvme0n1p6 and sudo swapon -a. Then I disabled some startup services, and finally commented out the swap line from /etc/fstab. Don't know whether sudo sysctl vm.swappiness=10 helped or not, but after rebooting, systemd-analyze showed 14.385s, as compared to around 2min 25s before.

  • @Krackout Thank you! – Akshat Vats Jun 14 '20 at 16:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.