On Sun, 23 Jan 2022 12:07:07 +0900 Olaf Meeuwissen via Dng <dng@lists.dyne.org> wrote:
> Hi, > > Florian Zieboll via Dng <dng@lists.dyne.org> writes: > > > On Fri, 21 Jan 2022 10:34:28 -0500 > > tempforever <d...@tempforever.com> 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 _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
