]> Slow boot after moving swap partition 🌐:aligrant.com

Slow boot after moving swap partition

Alastair Grant | Monday 14 June 2021

I went to upgrade an openSUSE 15.2 to 15.3 virtual machine and hit the age-old problem of not enough disk space.  Not a problem, it's virtual, I'll just grow the disk.  But in my haste, it seems I let the initial installer put the swap partition on the end of the disk.  Which means I can't easily grow the primary partition as there is another partition in the way.

Simple solution, being virtual, move the swap to a standalone disk.  Easy enough, I added a new 4GB virtual disk to the guest and booted it up.  I set the whole disk to being swap, unmounted the old swap partition, mounted the new one, and grew the primary partition over the old swap.  With a healthy number of reboots inbetween for care.  Sorted.  Right?

Well no.  Booting now took a long time.  Hitting escape to view the boot progress, I saw that the boot process was hanging on:

A start job is running for dev-disk-by\x2dpath-pci\x2d0000:00:10.0\x2dscsi\x2d0:0:0:0\x2dpart3.device

Handy.

I went ahead and upgraded anyway, figuring it might solve the problem.  And promptly bricked the guest.  Fortunately, this not being my first rodeo, I have a snapshot to roll back to.   But I needed to figure out this problem.

The path described in the start job was pointing to the iscsi device and partition number for the now defunct and deleted partition.  Checking /etc/fstab for old mounts was a no show.  Another useful command when dealing with swaps is to look at how systemd is activating them:

systemctl  --type swap --all

This will give you a list of swap configurations.  I thought this would be the clear culprit, with an old entry sitting here, but again, no show.

Finally I moved onto the boot loader, and bingo.  There in my kernel options was the parameter, which no longer exists as a valid disk path:

resume=/dev/disk/by-path/pci-0000:00:10.0-scsi-0:0:0:0-part3

TL;DR:

I changed this over to point to my new swap location, and whilst I was at it, I switched to using a /dev/disk/by-uuid/etc instead (not sure if this is best practice for kernel options, but it seems more robust, and appears to work).

Rebooting after this and the delay has now gone and I'm free to update my guest.

Breaking from the voyeuristic norms of the Internet, any comments can be made in private by contacting me.