Mailinglist Archive: opensuse-bugs (16652 mails)
| < Previous | Next > |
[Bug 439663] Your default new configuration of hibernating when idle can be dangerous.
- From: bugzilla_noreply@xxxxxxxxxx
- Date: Sat, 1 Nov 2008 21:01:21 -0600 (MDT)
- Message-id: <20081102030121.F2D3ECC7CF@xxxxxxxxxxxxxxxxxxxxxx>
https://bugzilla.novell.com/show_bug.cgi?id=439663
User robin.listas@xxxxxxxxxxxxxx added comment
https://bugzilla.novell.com/show_bug.cgi?id=439663#c2
Carlos Robinson <robin.listas@xxxxxxxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |NEW
Info Provider|robin.listas@xxxxxxxxxxxxxx |
--- Comment #2 from Carlos Robinson <robin.listas@xxxxxxxxxxxxxx> 2008-11-01
21:01:17 MDT ---
(In reply to comment #1 from Holger Macht)
Yes, the OS should deal with it properly, and currently it doesn't. I only
intended to show you one of the many situations where it leads to problems. I
know of more which I doubt if I'll report.
Permit me to be pessimist.
Not really. Vfat has been handled differently from the start of hibernation,
years ago: the system forced umount of vfat partitions, with the idea of
hibernating Linux and awaking windows alternatively. I have tested this in the
past and it works. Now I can't, because grub is overwritten. That's why I
included it on my test, I knew that it would work.
This is simply my old Bug 343874, closed as invalid, and which I'm afraid will
be closed again as such. It is the root cause of problems 2 to 5, and others I
haven't reported. It is a kernel problem, I'm afraid, and that's a fight out of
my scope: I don't know enough to argue it. If you want to solve that, Novell
itself will have to make the push on kernel people - IMO.
Remember that I talk about hibernation, ie, suspend to disk, because for some
reason my machine hibernates instead of suspend 2 ram: the computer powers
itself off, while the HD is still running. When the computer powers on again, I
think it rediscovers all USB connected things and they are reactivated. Mounted
filesystems are severed.
The solution would be some kind of forced umount with structure save with later
restoration, at the kernel level. IMO, it is improper to handle this at the
desktop level only.
I hardly think it can be handled nicely. The underlying structure has changed
from sda to sdc. It is surprising it survives that much: the script must be
really clever.
Ok, I'll try to report, but it is time consuming for me to run this test.
Yes, of course it is the same root cause, device went away. However, the
posture at Novel is that automatically mounted partitions survive. My test
discovered that LUKS encrypted filesystems do not.
However, I'm not personally interested in automatically mounting encrypted
filesystems via desktop. I see the SUSE script much safer in many respects.
Yes, manually mounted via "mount", and done by another user. Notice that the
decision to autosuspend/hibernate from one user's desktop affects other users,
too.
And yes, it is a kernel issue, device change.
My entire point is that autosuspending/hibernating is dangerous, not really
that the filesystem does not survive: I knew it doesn't, and therefore I do not
hibernate manually with external systems connected. It is autosuspend what
breaks it.
However, you can not seriously want that all users use the gnome desktop
facilities, Linux has much more than the desktop. If a system has devices
mounted in some way by a user, and you suspend from another, the issue has to
be considered. It is a multiuser and multisoftware environment.
Of course, and I knew this in advance. I reported the problem a year ago, you
see :-)
Yep :-)
But it did.
Ok, I'll try to report separately those issues, time permitting. But, you see,
I'm only interested on the manual mount issue, which I fear will be dismissed.
Ie, I'm interested in the root cause, the kernel.
And as I believe that the root cause will not be addressed and is outside my
reach, then I'm not really motivated to report them: it would be a waste of my
time. My point was to demonstrate that this autosuspend/hibernate can be
dangerous for data, that it is not well thought of, and this point is
demonstrated already, IMO.
And I know of more situations that break.
Hints:
Modems currently connected: phone will probably stay on.
Scanners on USB: when the system thaws the program using the scanner has to
be restarted.
Scanners: awakening the PC cause scanners on USB to restart (it is the same
as if you plug in the USB), switching on the lamp, which causes less life.
Printers currently printing via cups. Jobs could break or restart, wasting
paper and biasing the whole ecosystem of energy saving off.
Peer to peer networking at homes and offices will break: I mean samba, NFS,
etc, with opened files at the time of hibernation. Energy Star rules prescribe
that some network events should awake the machine, but my guess is that it will
not happen, and certainly not on hibernation.
Just tell people on Novell to test them.
Tell packagers to report what they think their packages will do when
suspended/hibernate, report what problems they have, and incentive the
developers to solve those issues. It is not serious or nice to ask the
community to report problems that the developers should already know about.
If I can guess the problems, so can you (Novell).
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
User robin.listas@xxxxxxxxxxxxxx added comment
https://bugzilla.novell.com/show_bug.cgi?id=439663#c2
Carlos Robinson <robin.listas@xxxxxxxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |NEW
Info Provider|robin.listas@xxxxxxxxxxxxxx |
--- Comment #2 from Carlos Robinson <robin.listas@xxxxxxxxxxxxxx> 2008-11-01
21:01:17 MDT ---
(In reply to comment #1 from Holger Macht)
This bugreport is mixing up a lot of single bugs AFAICS. It's also about
manual
suspend activation and does not necessarily have something to do with
autosuspend. The OS has to properly deal with external media and suspend.
Yes, the OS should deal with it properly, and currently it doesn't. I only
intended to show you one of the many situations where it leads to problems. I
know of more which I doubt if I'll report.
Then I left the machine alone, allowing it to automatically hibernate.
Notice that it auto-hibernated with open files on external media!
This should work, if not, it has to be fixed.
Permit me to be pessimist.
1) usb keychain disk, automatically mounted, vfat: survives. OOo can save
the file.
I guess you would have the same problems as with the external HD if you would
have multiple partitions on this stick.
Not really. Vfat has been handled differently from the start of hibernation,
years ago: the system forced umount of vfat partitions, with the idea of
hibernating Linux and awaking windows alternatively. I have tested this in the
past and it works. Now I can't, because grub is overwritten. That's why I
included it on my test, I knew that it would work.
2..5) External HD, which was /dev/sda, now is /dev/sdc
First bug, and a kernel issue. Can you please create a new one for just this
issue? Something like (shortened): "After suspendm external disk is /dev/sdc
instead of /dev/sda as it was before."
This is simply my old Bug 343874, closed as invalid, and which I'm afraid will
be closed again as such. It is the root cause of problems 2 to 5, and others I
haven't reported. It is a kernel problem, I'm afraid, and that's a fight out of
my scope: I don't know enough to argue it. If you want to solve that, Novell
itself will have to make the push on kernel people - IMO.
Remember that I talk about hibernation, ie, suspend to disk, because for some
reason my machine hibernates instead of suspend 2 ram: the computer powers
itself off, while the HD is still running. When the computer powers on again, I
think it rediscovers all USB connected things and they are reactivated. Mounted
filesystems are severed.
The solution would be some kind of forced umount with structure save with later
restoration, at the kernel level. IMO, it is improper to handle this at the
desktop level only.
2) Encrypted reiser partition, LUKS, mounted via your script
/etc/init.d/boot.crypto and proper /etc/crypttab configuration file.
Partition survives, nautilus can navigate it, CLI ok. However, oowriter can
not write to it:
# ls /mnt//usb/Erelas/cer/
.~lock.4_erelas.odt# 4_erelas.odt
Error saving the document 4_erelas:
Object not accesible
The object cannot be accessed due to insuficient user rights.
Please create another bug for this issue.
I hardly think it can be handled nicely. The underlying structure has changed
from sda to sdc. It is surprising it survives that much: the script must be
really clever.
Ok, I'll try to report, but it is time consuming for me to run this test.
3) Encrypted reiserfs partition, LUKS, automatically mounted via Gnome
desktop. Does not survive, partition does not appear. The device is there:
...and one for this, please... Mabye those actually have the same root cause?
Yes, of course it is the same root cause, device went away. However, the
posture at Novel is that automatically mounted partitions survive. My test
discovered that LUKS encrypted filesystems do not.
However, I'm not personally interested in automatically mounting encrypted
filesystems via desktop. I see the SUSE script much safer in many respects.
4) Manually mounted partition: survives partially. It can be read, but gives
errors:
What does this 'manually' exactly mean? Through the gnome desktop or with some
'mount ... ...'? If it's the latter, I don't think there's a bug. If you have
a gnome desktop running (so suspend can be triggered), you should that's
desktop's infrastructure to mount a device/partition.
Still, it might be a kernel bug/issue.
Yes, manually mounted via "mount", and done by another user. Notice that the
decision to autosuspend/hibernate from one user's desktop affects other users,
too.
And yes, it is a kernel issue, device change.
My entire point is that autosuspending/hibernating is dangerous, not really
that the filesystem does not survive: I knew it doesn't, and therefore I do not
hibernate manually with external systems connected. It is autosuspend what
breaks it.
However, you can not seriously want that all users use the gnome desktop
facilities, Linux has much more than the desktop. If a system has devices
mounted in some way by a user, and you suspend from another, the issue has to
be considered. It is a multiuser and multisoftware environment.
minas-morgul:/etc # l /mnt/Amon_Din/
ls: /mnt/Amon_Din/: Input/output error
ls: /mnt/Amon_Din/.: Input/output error
ls: /mnt/Amon_Din/cer: Input/output error
ls: cannot access /mnt/Amon_Din/casa: Permission denied
ls: /mnt/Amon_Din/Part_1-Amon_Din: Input/output error
total 0
drwxr-xr-x 6 root root 160 Oct 28 16:49 ./
drwxr-xr-x 4 root root 96 Oct 28 16:42 ../
-rw-r--r-- 1 root root 0 Oct 28 16:43 Part_1-Amon_Din
?????????? ? ? ? ? ? casa
drwxr-xr-x 2 cer root 120 Oct 28 16:59 cer/
minas-morgul:/etc #
oowriter can not save:
Error saving the document 1_amon_din:
General Error
General input/output error.
The reason is that the device is still mounted on /dev/sda1, which does not
exist, it is now /dev/sdc1:
Oh, so actually the same root cause as in 2...5).
Of course, and I knew this in advance. I reported the problem a year ago, you
see :-)
5) Automatically mounted reiserfs partition survives. oowriter succeeds
saving.
Well, at least one success ;-)
Yep :-)
I propose that, on openSUSE you:
a) change the default to never hibernate automatically
Just a note: It should. autosuspend, not hibernate.
Another issue, another discussion, see bug 439018.
But it did.
Ok, I'll try to report separately those issues, time permitting. But, you see,
I'm only interested on the manual mount issue, which I fear will be dismissed.
Ie, I'm interested in the root cause, the kernel.
And as I believe that the root cause will not be addressed and is outside my
reach, then I'm not really motivated to report them: it would be a waste of my
time. My point was to demonstrate that this autosuspend/hibernate can be
dangerous for data, that it is not well thought of, and this point is
demonstrated already, IMO.
And I know of more situations that break.
Hints:
Modems currently connected: phone will probably stay on.
Scanners on USB: when the system thaws the program using the scanner has to
be restarted.
Scanners: awakening the PC cause scanners on USB to restart (it is the same
as if you plug in the USB), switching on the lamp, which causes less life.
Printers currently printing via cups. Jobs could break or restart, wasting
paper and biasing the whole ecosystem of energy saving off.
Peer to peer networking at homes and offices will break: I mean samba, NFS,
etc, with opened files at the time of hibernation. Energy Star rules prescribe
that some network events should awake the machine, but my guess is that it will
not happen, and certainly not on hibernation.
Just tell people on Novell to test them.
Tell packagers to report what they think their packages will do when
suspended/hibernate, report what problems they have, and incentive the
developers to solve those issues. It is not serious or nice to ask the
community to report problems that the developers should already know about.
If I can guess the problems, so can you (Novell).
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
| < Previous | Next > |