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.