[SOLVED] Boot lag after editing partitions

[KHZenbook]

First, a disclamer. I don't know if this is where this post should go, or not. It does have to do with boot up so... Here goes.

Doing some partition work on drive with Gparted. Created new swap partition on SATA changed the swap partition around (swapoff/swapon) and deleted old swap partition. Did some other minor poking around and edited the fstab file in /ect to recognize the uuid of the new swap partition on boot. Reboot and...

Now I've got some strange stuff slowing the boot sequence down.

Of course the ever present:

modprobe: module dm-raid145 not found in modules.dep

Pops up first. Any way to get rid of that? Why's it there? Anyway, then comes the fun bit. Blinking cursor for about 60s. Then:

Gave up waiting for suspend/resume device

What??? I'm not terribly knowledgeable in this area (read like: I'm stabbing around in the dark hoping I don't break something critical).
What is this referring to, and how do I get it to go away? After this everything is normal uninterrupted boot sequence.

Of course all of the above is normally hidden by the mint logo boot screen.

Hardware is a standard Asus ux305fa
Intel core M processor
Intel wireless
8g ram
Samsung 256g SD drive
Can get you more specs if needed.

Thanks already.

[deepakdeshp]

When the login screen comes up hit ESC key and you will know what commands are being run and where it is waiting.

[KHZenbook]

I must not have made myself clear in the above. Sorry.

When the linux boot screen first appears after grub, you press esc and the following appears:

modprobe: module dm-raid145 not found in modules.dep

Blinking cursor for about 60s. Then:

Gave up waiting for suspend/resume device

The rest that follows is the traditional uninterrupted boot sequence (ie. sata6 found as / finding, checking and starting everything for system, takes about 2sec.).

[KHZenbook]

Did some more searching on my own. Pretty sure it has nothing to do with the partition editing. Still no closer to a solution.

[jwiz]

Try again running ' systemd-analyze blame'

[axisofevil]

Your " suspend/resume device" is your swap partition - you need to regenerate your kernel...
See (for example) http://forums.debian.net/viewtopic.php?t=133253

[KHZenbook]

Updated the whole system (hadn't updated for over a month). I had a kernel update happen. Rebooted and no issues now.

Should I still be worried about it or not?

[axisofevil]

No - if you should need to go back to a previous kernel for any reason, its only going to be a slight irritation.

[KHZenbook]

So just a fact post for those with the same problem who dig up this post in the future.
When you change the location of your swap partition you need to edit the /ect/fstab file to reflect the UUID of the new partition. You also need to edit the UUID in '/ect/initramfs-tools/initramfs.config' file and also any configuration files in '/ect/initramfs-tools/conf.d/' and or '/ect/initramfs-tools/resume/' then run '#initramfs-update -u -k all' ...
As of initramfs(8) no UUID's are contained in the initramfs configuration files (which is why an update took care of it for me) instead initramfs is directed to the fstab file for that info (lessens redundancies).

Case solved for me; hope the above helps posterity.

[rdb_1212]

I had read through this entire thread because I was having the same problem. I ended up running the command "sudo update-initramfs -u -k all" and that fixed it. It was looking for a deleted swap which never actually belonged to LMDE. The swap belonged to MX Linux, which I replaced with Siduction. I never told LMDE to use a swap in the first place. Sneaky little thing.