Hi,

Florian Zieboll via Dng <dng@???> writes:

> 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

    ^^^^^^

As you've already discovered (based on other mail in this thread), this
should be

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.

AFAIK, the whole point of using UUIDs is to find partitions no matter
what disk they are on, be that /dev/sda, /dev/sdb, /dev/nvme0n1 or what
have you.

Hope this helps,
--
Olaf Meeuwissen                    FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Software                        https://my.fsf.org/donate
 Join the Free Software Foundation              https://my.fsf.org/join