Long (40s+) kernel boot time (probably swap mount issue?)

Question

I have messed with swap and now i think i have a mount timeout during boot, but I can't find the reason. What I did was to switch to a swapfile, but i decided to move back to separate partition for swap. I have restored /etc/fstab entry for partition swap, with UUID of the new swap partition, and it mounts correctly, but still i have 40s+ time of kernel boot, that wasn't there before i messed with the swap. 30s timeout for mount seems about right but i have no idea where it could come from.

$ sudo systemd-analyze 
Startup finished in 12.396s (firmware) + 3.520s (loader) + 41.762s (kernel) + 4.206s (userspace) = 1min 1.885s 
graphical.target reached after 4.199s in userspace

$ dmesg
[   10.013926] amdgpu 0000:09:00.0: [drm] fb0: amdgpudrmfb frame buffer device
[   41.452204] fbcon: Taking over console

$ swapon -s
Filename                Type        Size        Used        Priority
/dev/nvme0n1p6          partition   4354044     0           -2

Current /etc/fstab entries:

UUID=1b29a039-fc6e-4605-ab3b-8c2c7fef5b12 /               ext4    errors=remount-ro 0       1
UUID=900D-3933  /boot/efi       vfat    umask=0077      0       1
UUID=89e04806-5af3-4a54-9039-01880ace0f2e none            swap    sw              0       0

Seem to match the entries from blkid

/dev/nvme0n1p5: UUID="1b29a039-fc6e-4605-ab3b-8c2c7fef5b12" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="de718315-ddc0-49fe-9ceb-76bc07e17d71"
/dev/nvme0n1p3: LABEL="SYSTEM" BLOCK_SIZE="512" UUID="626E216A6E213865" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="68a15aa7-d352-4a82-ba52-dd1dbf9711fb"
/dev/nvme0n1p1: UUID="900D-3933" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="b1c50a15-3d4a-4869-8213-85a4bdd1dd76"
/dev/nvme0n1p6: LABEL="swap" UUID="89e04806-5af3-4a54-9039-01880ace0f2e" TYPE="swap" PARTLABEL="swap" PARTUUID="dd2bfed7-249a-4b2b-b69b-6bba52e0846c"
/dev/nvme0n1p4: BLOCK_SIZE="512" UUID="1C1C38DD1C38B41C" TYPE="ntfs" PARTUUID="259c58e4-26d7-4ee1-937d-43b116110ea6"

I am at a loss. I tried finding anything more, but dmesg just has this big gap, and other systemd-analyze commands give nothing of use:

$   systemd-analyze critical-chain 
graphical.target @4.199s
    └─multi-user.target @4.199s
      └─kerneloops.service @4.187s +11ms
        └─network-online.target @4.153s
          └─NetworkManager-wait-online.service @797ms +3.356s
            └─NetworkManager.service @749ms +45ms
              └─dbus.service @747ms
                └─basic.target @738ms
                  └─sockets.target @738ms
                    └─snapd.socket @737ms +743us
                      └─sysinit.target @733ms
                        └─snapd.apparmor.service @561ms +164ms
                          └─apparmor.service @496ms +52ms
                            └─local-fs.target @494ms
                              └─run-snapd-ns-snapd\x2ddesktop\x2dintegration.mnt.mount @2.224s
                                └─run-snapd-ns.mount @1.955s
                                  └─swap.target @458ms
                                    └─dev-disk-by\x2duuid-89e04806\x2d5af3\x2d4a54\x2d9039\x2d01880ace0f2e.swap @431ms +12ms

$ systemd-analyze blame
3.356s NetworkManager-wait-online.service
2.707s plymouth-quit-wait.service
1.091s snapd.service
 326ms snapd.seeded.service
 280ms dev-loop5.device
 279ms dev-loop6.device
 276ms dev-loop7.device
 253ms dev-loop1.device
 253ms dev-loop2.device
 252ms dev-loop3.device
 251ms dev-loop4.device
 244ms dev-loop0.device
 228ms dev-nvme0n1p5.device
 195ms systemd-resolved.service
 164ms snapd.apparmor.service
 157ms [email protected]
 155ms cups.service
 150ms systemd-oomd.service
 147ms plymouth-start.service
 146ms systemd-timesyncd.service
 144ms networkd-dispatcher.service

Answer 1

For anyone with same problem, try following:

For some reason running

sudo update-initramfs -u -k all

solved the issue:

[   10.056435] amdgpu 0000:09:00.0: [drm] fb0: amdgpudrmfb frame buffer device
[   10.147211] fbcon: Taking over console

$ sudo systemd-analyze time
Startup finished in 11.307s (firmware) + 2.523s (loader) + 10.458s (kernel) + 6.233s (userspace) = 30.523s 
graphical.target reached after 6.224s in userspace

I am out of my league to tell why, but i saw that it it mentions the UUID of the new swap partition (i think setting it to be the place from which systems resumes when hibernating?) so my guess is that whatever that commands does exactly, it updated some leftover settings pointing to old UUID of old swap partition, which lead to a 30s timeout. However, the fact that NONE of the logs in the /var/log don't even mention that something failed after 30s timeout is just... astonishing. Meanwhile system logs are filled with garbage messages from gnome geolocation malware, but god forbid if failing to read from partition is logged. Oh no sir. . Truly, Ubuntu has reached the era of modern desktop OS, where important stuff is not logged, and what is logged is useless (looking at you Windows system log).