[Bug 439663] New: Your default new configuration of hibernating when idle can be dangerous.
https://bugzilla.novell.com/show_bug.cgi?id=439663 Summary: Your default new configuration of hibernating when idle can be dangerous. Product: openSUSE 11.1 Version: Beta 3 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: GNOME AssignedTo: bnc-team-gnome@forge.provo.novell.com ReportedBy: robin.listas@telefonica.net QAContact: qa@suse.de Found By: --- openSUSE 11.1 Beta 3 Note: It has taken me almost five hours to test and write up this report, so please give it due consideration. My point is that having a default configuration of hibernating openSUSE machines (not SLES/SLED, thus not certified bundles) can be dangerous and cause loss of data. If the machine is not certified and the user instructed, it must be left to the administrator the decision of what will be the default configuration: hibernate or not. Notice that this default configuration can not be modified by us (Bug 439075). Notice that users have no easy access to change their own configuration, as the power manager applet doesn't start (Bug 439647). Finally notice that I know that the test I did is dangerous for data. The problem is that the danger is caused by the automated decision of the system to hibernate, not by the user deciding to hibernate or knowingly place his system on a dangerous situation. I connected an external disk via USB with 4 reiserfs partitions, two normal, two encrypted (created with yast in 11.0). Of each partition type one is manually mounted, the other automatically. I also connected a usb keychain flash disk, vfat, automounted. I then created with OOwriter a file on each. I also left a thunderbird session connected to two remote imap servers, open. Then I left the machine alone, allowing it to automatically hibernate. Notice that it auto-hibernated with open files on external media! 1) usb keychain disk, automatically mounted, vfat: survives. OOo can save the file. 2..5) External HD, which was /dev/sda, now is /dev/sdc 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. 3) Encrypted reiserfs partition, LUKS, automatically mounted via Gnome desktop. Does not survive, partition does not appear. The device is there: minas-morgul:/other/main/etc # dmsetup ls luks_crypto_042a7ba2-8908-4255-be33-a9cb51580de4 (253, 0) mcr_mm_erelas (253, 1) but it is not mounted. The mountpoint /media/disk where it was, has dissapeared. An attempt to manually mount it fails: mount: /dev/mapper/luks_crypto_042a7ba2-8908-4255-be33-a9cb51580de4 already mounted or /mnt/usb/Nardol busy And it is not possible for dmsetup to remove it: minas-morgul:/other/main/etc # dmsetup remove luks_crypto_042a7ba2-8908-4255-be33-a9cb51580de4 device-mapper: remove ioctl failed: Device or resource busy Command failed oowriter fails when saving the file, obviously, the mount point has disappeared. Even "save as" gives an error: because the current dir has disappeared under its feet. I must congratulate the team that wrote the /etc/init.d/boot.crypto script, because their system survived hibernation - although oowriter did not (lockfile?). However, the automatically mounted encrypted partition is not that robust. 4) Manually mounted partition: survives partially. It can be read, but gives errors: 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: minas-morgul:/etc # mount | grep Amon /dev/sda1 on /mnt/Amon_Din type reiserfs (rw,noexec,nosuid,nodev,noatime,acl,user_xattr) Even umounting and mounting gives problems to oowriter, there is a lockfile. minas-morgul:/etc # ls /mnt/Amon_Din/cer/ ~lock.1_amon_din.odt# 1_amon_din.odt 5) Automatically mounted reiserfs partition survives. oowriter succeeds saving. I propose that, on openSUSE you: a) change the default to never hibernate automatically b) pop up a dialog when the user activates autohibernation warning him of the dangers and the precautions he must have with things like external media, opened sessions to/from other machines, etc. -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=439663
User hmacht@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=439663#c1
Holger Macht
I connected an external disk via USB with 4 reiserfs partitions, two normal, two encrypted (created with yast in 11.0). Of each partition type one is manually mounted, the other automatically. I also connected a usb keychain flash disk, vfat, automounted.
I then created with OOwriter a file on each.
I also left a thunderbird session connected to two remote imap servers, open.
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.
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.
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."
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.
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?
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.
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).
5) Automatically mounted reiserfs partition survives. oowriter succeeds saving.
Well, at least one success ;-)
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. -- 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.
https://bugzilla.novell.com/show_bug.cgi?id=439663
User robin.listas@telefonica.net added comment
https://bugzilla.novell.com/show_bug.cgi?id=439663#c2
Carlos Robinson
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.
https://bugzilla.novell.com/show_bug.cgi?id=439663
User hmacht@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=439663#c3
Holger Macht
(In reply to comment #1 from Holger Macht) 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.
Very different issue, and a very good idea to _not_ boot into another operating system. This is far more dangerous that anything else. Kiss _all_ your data good by.
This is simply my old Bug 343874, closed as invalid, and which I'm afraid will
I reopened that one.
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
This will be fixed before 11.1 release.
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.
Right, kernel issue. It has all the information it needs to do it properly.
2) Encrypted reiser partition, LUKS, mounted via your script 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.
It must not change from sda to sdc!
Ok, I'll try to report, but it is time consuming for me to run this test.
Maybe that's already covered by the plain issue that the device comes up differently than it has been before.
hibernate manually with external systems connected. It is autosuspend what breaks it.
Please also not, this all might work a lot better with suspend instead of hibernation. You didn't try that. I doubt devices will change a lot.
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.
Not all use cases can be considered. That's just not possible. But for a default installation, we can try our best. If you're using some old fashioned desktop, you're on your own, sorry.
And I know of more situations that break.
Hints: [some good reasons] 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.
Most won't care until it bites them, really. And you actually see that enabling this by default made people (you and others) report the issues which in a lot of cases did not came up before. And that's one big aim. Ok, thanks for this report, but because it also handles non technical issues (discussions) and has different problems in there, I'm going to close it. I reopened the old bug to care about the one main issue in this report. *** This bug has been marked as a duplicate of bug 343874 *** https://bugzilla.novell.com/show_bug.cgi?id=343874 -- 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.
participants (1)
-
bugzilla_noreply＠novell.com