On Sun, 23 Jan 2022 12:07:07 +0900
Olaf Meeuwissen via Dng <dng@???> wrote:

> Hi,
>
> Florian Zieboll via Dng <dng@???> writes:
>
> > On Fri, 21 Jan 2022 10:34:28 -0500
> > tempforever <dev1@???> wrote:
> >
> >> Something to check/verify:
> >> If swap is listed in /etc/fstab, then make sure it is listed by
> >> UUID rather than block-id.
> >> I mention this, since I have a (commented out) swap line in
> >> /etc/fstab
> >
> > Yes, in the fstab, the swap partition is active and defined by (the
> > correct) UUID.
>
> Just to make absolutely sure, you're saying that the output of
>
> blkid -t TYPE=swap -s UUID -o value
>
> matches what's in your /etc/fstab and
> /etc/initramfs-tools/conf.d/resume and you have run `update-initramfs
> -u` after confirming that?
>
> I've been seeing these boot delays as well (on a Debian machine where
> systemd "helpfully" waits for swap to become available and eventually
> continues without when that times out after 90 seconds!) after I
> recreated swap (moved the partition and ran mkswap on it).
>
> Updating /etc/fstab and /etc/initramfs-tools/conf.d/resume to match
> the changed UUID and running `update-initramfs -u` made it go away.
>
> Hope this helps,


No systemd here, but sysv init -_- and the system stalls for exactly
30". And yes, I had checked the UUIDs thoroughly several times and now
once again:

root@nulldevice:~# blkid -t TYPE=swap -s UUID -o value
a743df91-ac0a-419b-95e7-5c266447e543

root@nulldevice:~# cat /etc/fstab | grep swap
UUID=a743df91-ac0a-419b-95e7-5c266447e543 none swap sw 0 0

root@nulldevice:~# cat /etc/initramfs-tools/conf.d/resume
resume=UUID=a743df91-ac0a-419b-95e7-5c266447e543

root@nulldevice:~# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-5.10.0-11-amd64
I: The initramfs will attempt to resume from /dev/sda1
I: (UUID=a743df91-ac0a-419b-95e7-5c266447e543)
I: Set the RESUME variable to override this.

  root@nulldevice:~# cat /proc/swaps  # (some whitespace removed:)
  Filename        Type            Size          Used       Priority
  /dev/sda1       partition       25165820      0          -2

But my theory of not-persistent naming of the disks being the reason for
the issue has not proven true: Interestingly, the device names
(sda/sdb) do not (no longer?) interchange with every reboot, but the
swap partition is _always_ not found. In fact, over all five test
reboots today, the naming has been persistent - while on Friday, it
seemed to change reliably - at least when I checked.

Still no change after re-creating the swap partition and rebooting:

root@nulldevice:~# swapoff /dev/sda1

root@nulldevice:~# mkswap -U a743df91-ac0a-419b-95e7-5c266447e543 -c \
-L SWAP /dev/sda1

root@nulldevice:~# swapon /dev/sda1

  root@nulldevice:~# cat /proc/swaps  # (some whitespace removed:)
  Filename        Type            Size          Used       Priority
  /dev/sda1       partition       25165820      0          -2

root@nulldevice:~# blkid -t TYPE=swap -s UUID -o value
a743df91-ac0a-419b-95e7-5c266447e543

root@nulldevice:~# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-5.10.0-11-amd64
I: The initramfs will attempt to resume from /dev/sda1
I: (UUID=a743df91-ac0a-419b-95e7-5c266447e543)
I: Set the RESUME variable to override this.

root@nulldevice:~# reboot