It goes to "Sleep" but won't wake. Desktop PC using Daedalus, image 6.1.0-27-amd64,  on a ASUS M5A97 R2.0 Mobo, with AMI BIOS 2603, XFX Radeon RX 480 graphics, PS/2 keyboard.

From the web, this seems a common problem across many distros, with numerous "solutions" which work for some but not others. "Solutions" have included increasing the swap file size, keeping USB ports open to signals, and waggling the mouse around. Frustratingly, the problem is often declared "Solved" and a thread closed when it is only solved for the one OP user, or when someone points to a "solution" given years ago.

When I try to wake by pressing a key or the power button, the system unit fans restart but the monitor screen stays black and its indicating lights show no signal being received. As an experiment I have sent it to sleep with a terminal session open, "woken" it by pressing a key, and then blindly typed in a command to make an audible beep - and get no beep. I can only do a full power off and restart.

Maybe related, when I go to a full screen text session (Ctrl-Alt-F1) and then return to GUI session (Ctrl-Alt-F7), I am placed at the GUI log-in screen and find nothing has been saved.

Things that don't work for me, some being those suggested solutions :

• Trying to wake by pressing a key, waggling the mouse, pressing the power button, or pressing the reboot button

  Trying to wake after sending to sleep by the menu in the GUI

  Trying to wake after installing pm-utils and sending to sleep with "pm-suspend" from a su command line

  Ensuring swap partition/file is larger than RAM (surely this would only affect Hybernate and not Sleep?)

  Not sharing the swap partition/file with another distro

  Ensuring  swap partition in fstab has same UUID as in cfdisk as "Filesystem UUID"

  Ensuring /etc/initramfs-tools/conf.d/resume file points to same UUID as swap in fsstab
    .. followed by update-initramfs -u and reboot

  Fresh install of Daedalus on a dedicated drive with three partitions - root, home and unshared swap. (My data is on another drive)

There have been suggestions that it is a kernel bug, also a plot between Microsoft and the BIOS makers. My money is on the kernel bug, or some oversight in the installation scripting.

Anyway, I 'm not prepared to work without the sleep mode so I wiped that Daedalus drive and intalled Chimaera, image 5.10.0-9-amd64, in the same way, adding pm-utils. Sleep from "pm-suspend" and waking with the power button works in Chimaera.

Any better ideas, or future bug fix, would be welcome.

During Daedalus installation (and previous Devuan versions) from an ISO image there is a point at which I am asked to choose between :

linux-image-6.1.0-27-amd64
linux-image-amd64

(There is also an option of no kernel).  What is the difference and which should you choose?  AFAIR the latter was already highlighted as the default. This might not be the latest kernel version as I downloaded this image a while ago, but the question stands.

I updated Chimaera to Daedalus with the "apt-get upgrade" and "apt-get dist-upgrade" commands. I also have an Ascii installation on a different partition on the same HDD, and Windows and DOS on two further different HDDs. With Chimera I had the ability to boot into all those and I want to keep that ability.

For safety during the Daedalus upgrade I unmounted the Ascii partition, my data partitions, and physically disconnected the Windows HDD. I left the DOS HDD connected because it was too hard to reach.

As expected after the installation the Grub menu did not show Ascii or Windows, nor (surprisingly) DOS. So after reconnecting everything and mounting the Ascii partition I tried to run "update-grub" and it said "Command not found". So I tried "apt-get install update-grub" and it said "Unable to locate package update-grub". I'm using root of course. I then tried "grub-mkconfig" with the same result. Yet I can see the man pages of these commands. My sources.list is as recommended by Devuan's upgrade-to-daedalus page.

So is "update-grub" no longer avaiable and if so is there a replacement? According to aptitude I have grub-common, grub-pc, grub-pc-bin and grub2-common installed.  How do I get out of this fix other than wiping the Daedalus partition and doing a fresh installation of it?

I have four HDDs, one of which is dedicated to Windows and has four primary MBR type partitions.  Windows works fine, but although Linux sees the drive as sdb, it does not see the partitions. I first noticed this because trying to mount the Windows partitions under Devuan failed.

[root@mesh-devuan:~] # cat /proc/partitions 
major minor  #blocks  name

   8        0  244198584 sda
   8        1   51761398 sda1
   8        2   51761430 sda2
   8        3   51761430 sda3
   8        4   88911742 sda4
   8       32  976762584 sdc
   8       33  156250112 sdc1
   8       34  156250112 sdc2
   8       35  156250112 sdc3
   8       36  156250112 sdc4
   8       37    8388608 sdc5
   8       38   25165824 sdc6
   8       39  318206663 sdc7
   8       16   78150744 sdb
   8       48    4202415 sdd
   8       49     262206 sdd1
   8       50     999810 sdd2
   8       51    2940367 sdd3
  11        0    1048575 sr0

Yet cfdisk does see them :-

                                   Disk: /dev/sdb
                Size: 74.5 GiB, 80026361856 bytes, 156301488 sectors
                         Label: dos, identifier: 0x2de32de2

    Device       Boot         Start        End   Sectors   Size  Id Type
    /dev/sdb1                  2048     206847    204800   100M   7 HPFS/NTFS/exFAT 
    /dev/sdb2                208845   31423139  31214295  14.9G   7 HPFS/NTFS/exFAT
    /dev/sdb3              31423140  110157704  78734565  37.6G   7 HPFS/NTFS/exFAT
    /dev/sdb4             110157705  156296384  46138680    22G   7 HPFS/NTFS/exFAT
    Free space            156297216  156301487      4272   2.1M

What is going on here? AFAIR I created the sdb partitions under Windows, because in my experience Windows does not see partitions as the correct size if installed into partitions created earlier under Linux.

BTW, the 100Mb sdb1 was created by Windows 7 for some purpose.