On Wed 29. Oct - 13:52:48, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Content-ID: <alpine.LSU.2.00.0810291343550.4858@nimrodel.valinor>
On Wednesday, 2008-10-29 at 13:27 +0100, Holger Macht wrote:
On Tue 28. Oct - 12:22:13, Carlos E. R. wrote:
On Tuesday, 2008-10-28 at 00:57 -0300, Cristian Rodríguez wrote:
if this mis^W^Wbehaviuor is intented, must be documented in big letters how to disable it in the release notes.
Absolutely!
You (Novell) should remember that a system must be tested before been allowed to hibernate. And for compliance, certified, too: openSUSE can not be certified.
Default configuration should be to _suspend_ (the fast one), not to hibernate. And we have a whitelist for all working machines which are able to _suspend_. For desktops, I guess these are still quite a few.
Suspend to memory in my desktop is broken, the cpu fans stops and the cpu reaches very high temperatures. Known bios bug, not your problem: nevertheless, dangerous if 'you' decide to suspend my machine.
Please post the output of 's2ram -n'. If it's not known to be working, it won't suspend.
You should not neither suspend or hibernate a machine by default, this must be the owner decision. This is openSUSE, not sles/sled.
_It is_ a user decision, the user can easily change the default.
Question: What will happen if the user has opened files on external USB media, he leaves for a long coffe, and on return the machine is hibernated?
I have a Bugzilla about that since ages: in this case the usb storage system crashes. The mount is there, but the disk is not accesible. Opened files woud be damaged.
Different problem, however a problem ;-)
Has Novell tested, solved, and certified that this works correctly now?
Do you have the bug id?
Yes, 439663.
Isn't this actually a dup of 439018? Anyway I'll look into this story ;-) Regards, Holger
And it took me an entire afternoon to prepare the test, run it, and report it. I'd expect it not to be dismissed after a perfunctory read.
The old bug was 343874, which was closed as INVALID because that disk was mounted via fstab (!). The current one I tested with:
- a reiser partition mounted via fstab - a reiser partition mounted automatically by gnome desktop - an encrypted (LUKS) reiser partition mounted via /etc/crypttab, /etc/fstab/, via the script /etc/init.d/boot.crypto - an encrypted (LUKS) reiser partition mounted automatically via the desktop - a flash type usb keychain with vfat mounted automatically.
The main problem is that a mounted external filesystem changes device when thawed, from /dev/sda to /dev/sdc, for example. It does not survive.
- -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkkIXKMACgkQtTMYHG2NR9U+CACfeNhIJYLnGS4bw5FQmS2rLrNc 12gAoJNmtXIIktH4j5An7NRc2jbcu/ry =W83g -----END PGP SIGNATURE-----
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org