On Sun, 23 Jan 2022 20:23:51 +0100
tito via Dng <dng@???> wrote:

> On Fri, 21 Jan 2022 15:45:46 +0100
> Florian Zieboll via Dng <dng@???> wrote:
>
> >
> > Hallo list,
> >
> > after the latest kernel-update (chimaera, from 5.10.0-10-amd64 to
> > 5.10.0-11-amd64), my desktop's initramfs no longer finds the swap
> > (suspend/resume) partition.
> >
> > Running 'update-initramfs -u' returns the correct UUID "to resume
> > from", and also adding the line
> >

> >     resume=UUID=<correct UUID here>

> >
> > to '/etc/initramfs-tools/conf.d/resume' does not solve the issue:
> > Booting stalls for half a minute and then continues with the
> > information that it "gave up waiting for suspend/resume device".
> >
> > On examining this I noticed, that my block devices are no longer
> > named persistently: Sometimes the disk comes up as 'sda' and
> > sometimes as 'sdb', although both internal disks are connected to
> > the same onboard SATA controller. I am not yet absolutely sure, if
> > the name swap happens always or randomly - but as I suspect it to
> > be the reason for the failing swap discovery, which occurs reliably
> > every time I (re)boot, I assume that it happens with _every_ boot
> > cycle.
>
> Hi,
> out of personal experience I would check the PSU as I had
> similar problems in a box with several raid arrays not coming
> up correctly or with disks missing that drove me mad
> at changing disks and raid cards until I changed the PSU.
>
> > NB: Some days before, I had to replace the system's other hard disk
> > -
>
> Are you sure that the disk was defective and not just undepowered
> as they draw max current at boot when the disks spin up
> at the same time?
>
> > but I am quite (grrrr: very!) sure that the phenomenon occurred
> > only and directly after the latest kernel update mentioned above,
> > as the boot delay is hard to miss.
> >
> > Any hints are very welcome!
> >
> > Libre Grüße,
> > Florian
>
> Just my 2 cents
>
> Ciao,
> Tito


Hallo Tito,

a good hint I didn't think of at all, but the disk was definitely gone
and had to be ddrescue'd. I was lucky enough to get 98% of my usually
'ro' mounted media archive restored and to have the missing bits still
in my homedir.

I found out in the meantime that the problem had existed even longer
than the disk replacment - and thanks to Aitor, that the reason was my
misspelled (lowercase) 'RESUME' variable.

As my disks do not spin down over a reboot, I assume that the energy
consumption peak you suggest should only occur at a cold boot.

Thank you and libre Grüße,
Florian