initramfs/mkinitramfs errors after updates when generating kernels

[slaytanicprion]

content of '/etc/fstab/'

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sdb1 during installation
UUID=5de63a03-0b43-4705-8e28-ba7596f30082 /               ext4    errors=remount-ro 0       1
# swap was on /dev/sda5 during installation
UUID=9c3dc736-72b8-42ba-a452-6adeb1996a31 none            swap    sw              0       0

I don't know about the error regarding the installation drive, it is still on sdb1. I got the swap's UUID.

Looks like I should be inserting it in the resume or resume.save file instead of resume=NONE from what I was able to find out, but it's still unclear, cos I'm getting help topics 8-10 years old for ubuntu 14.04 and other debian distros back 5-10 years ago.

You guys helped out enough to get me to finish line. We've identified the problem, the system can't find the swap partition at boot, because it's not even in those initramfs/conf.d resume files. Don't let me down here! We're almost there!

[slaytanicprion]

is it possible to grab with print screen key the message I get in black and white (a single line going on about initramfs-update/conf.d/resume and resume.save). I know it won't work the way I'm trying it.

Strangely, btw, Ubuntu MATE is now on sdc, the system decided an external drive was now sdb. I think those issues are linked. I have a problem in that whenever the desktop is not restarted properly (fully), going to POST before grub, like right now I'm in the middle of renovating my bathroom and I forgot to turn off my desktops in the house before I am so swamped with work and i had to cut the power. There's also been a lot of power losses lasting 30 seconds to 2 minutes for absolutely no explainable reasons where I live, last week it happened when there wasn't a single cloud in the sky. I hope my power variation secured power bars haven't degraded too much. But anyway, I was saying this because somehow the drive with Ubuntu MATE on it doesn't stay first HDD in boot (after DVD/CD/BD and USB boot) order, it always falls back to sda, the drive with min 17.3 and that swap on sda5. I'm about to just format that drive (sda). I always have to go in the BIOS/UEFI and put back that drive first. Well, I do whenever the desktop wasn't restarted purposefully, like say after an update and I want to get in the new kernel, it will work just fine, but unwanted power offs always cause that to happen, this particular drive does though, not the first time I see it drift from sdb1 to sdc or sde and external drives taking its place at sdb.

If I'm to do that, I will have to create a swap file, not an issue, the drive with UM has nothing important on it, I already mentioned how all of this could be because it is quite a strange acting drive (you should see those logs), and it has many bad blocks (that I have isolated using great software, if you want to know what, I'll say). I'll eventually replace it when not all of my extra money is going into the bathroom renovations...that I would have left the way it was if it wasn't for my s/o 🙄

Meanwhile my previous post is pending an answer. My /etc/fstab/ file shows clearly how things were at install, but things aren't working like they should. I need to know if people here with swaps have the UUID for their swap partition is inserted in that resume file. Lower than it should be performance, the way it is happening right now is very reminiscent of an OS (namely windows) where if there's an issue with the windows swap file, it'll show.