On Tue, Feb 20, 2018, at 16:12, Hans wrote: > Hi folks, > I am working on a little problem. Just let me shortly describe: > > When I am running suspend-to-disk, I can see, that the RAM is saved to > the partition (in my case I defined the swap partition).
Is your swap partition large enough to hold the contents of your RAM? It doesn't need to match (or exceed) the system memory capacity, but it should be reasonably large. Suspend-to-disk won't work if it is too small, but I'm not sure whether it would fail in the way that you have described. It might be valuable to check the health of your swap space. If there are problems, then invalid data might be read back into RAM. A good place to start is the S.M.A.R.T. report for the hard drive or SSD, which can be retrieved with smartctl(8) from the smartmontools package: smartctl -a /dev/sda (if we assume that your swap partition is on sda) You can also test the swap partition directly using badblocks(8): swapoff /dev/sda2 (assuming that swap is on sda2, for example) badblocks -vw /dev/sda2 On Tue, Feb 20, 2018, at 16:12, Hans wrote: > Everything is working fine, after that writing to disk, the computer > is shutting down. So far, so well. > > But when I wake it up, I can see, the computer is starting from BIOS, > and the data is rewritten from the partition into ram. > > But then - the computer shuts down, and is starting from BIOS again. Analogous to the last check, it might be good to check the health of RAM, in case there are errors occurring while data is being read back. You can install the memtest86+ package and then boot from the "Memory test" option in GRUB. On Tue, Feb 20, 2018, at 16:12, Hans wrote: > Now my problem: Is there a way, to see, what happens, when the > computer writes its data from swap into memory and then crashes? I > found no log entries, which showed me, why the computer resets after > refilling the ram. Kernel logs are overwritten at next boot, and > tricks, like cutting of power before the second boot, and then > examining the log files with a second operating system like a livefile > system gave me no further information, too. I'd recommend testing the disk and system memory first, as described above, but there are ways to retrieve kernel messages and so forth from a crashed system. The traditional method is by string a null-modem serial cable between this computer and another one, and then passing a kernel parameter to enable writing kernel messages to the serial console. You might also have some luck with the kdump-tools package, which uses the kdump and kexec kernel features to immediately transition from the crashed kernel instance to a sane kernel instance, which then safely collects and saves information about the crash (including kernel logs). This resembles the approach which you attempted with the second OS but is less likely to fail -- the second OS approach depended on the crashed kernel having successfully written its kernel ring buffer out to disk before dying, which often does not happen. - Louis
