DebianThis forum is for the discussion of Debian Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
you should have no problems at all, there's nothign important or persistent in there, just and underlying filesystem for accessing the data, but as when a system boots it's reinitialised, there's nothing to go wrong.
I understand that RAM content will be on swap when suspended, but why is it a problem? Is the concern that it will not boot into the same OS?
You'd need to do a search, but I've seen posts now and again where someone has tried to resume the wrong OS and wound up with an OS that is marked as suspended and they had to manually change something in order to be able to boot normally (or something like that). Sorry, but I don't have any more info than that. I don't use suspend.
This has to be confirmed but I think that with newer kernels and newer suspend packages, it will refuse to resume a different kernel.
I'll maybe try it... I have to reboot for that
But, what happens after you've booted from the other kernel that wasn't suspended. Does that delete all the info that the first one has been suspended, or does that one get placed in some sort of broken limbo?
But, what happens after you've booted from the other kernel that wasn't suspended. Does that delete all the info that the first one has been suspended, or does that one get placed in some sort of broken limbo?
I guess they have a different signature. (some sort of bytes sequence to differentiate)
Suspending from 2.6.18-4-686, testing branch (for the s2disk and such).
(I use directly the command s2disk from a shell)
Booting the 2.6.21.5. The initrd warns:
Quote:
resume: The system snapshot image could not be read
This might be a result of booting a wrong kernel or typing in a wrong passphrase.
You can continue to boot the system and lose the saved state or reboot and try again.
[Notice that you may not mount any filesystem between now and successful resume. That would badly damage affected filesystems.]
Maybe my suspend has never worked.. As soon as I got the warning it rebooted, I went back on the 2.6.18, typed my passphrase and went to fetch a beer
When I come back, I have the message
All I can say is that I remember a post from someone about this situation and one of their OSes got locked as a result of booting from a non-suspended OS and then trying to boot the "suspended" one. Whether they screwed up or newer kernels addressed it, I can't say. Hell, it's even likely that I just remember this wrong. Not trying to start a controversy.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
