Bug 215262

kded mediamanager now implements the required DCOP function - unmountAllManual(), reassigning to kpowersave

Who know which partitions/volumes are unmounted and which we need to remount? And who handle the remount?  

Lukas, what is the status here?

The status is such as I implemented the part that was demanded by coolo in the respective FATE entry (30647).
As for the remounting: media manager offers a list of devices, and then each device provides a function "bool needMounting()". Just tell me what other  functionality you want me to provide thru DCOP

Sorry, but what mean needMounting()? I need a function which do exact the opposite of unmountAllManual() and remount all before mounted volumes/media. Maybe better a unmountAllSuspend() and remountAllResumed() which umount all related partitions (and remember which this was) and remount them after resumed and KPowersave called remountAllResumed(). Otherwise I need to remount _all_ media also if them wasn't mounted before the suspend.

These two DCOP methods added:

+    /**
+     * Unmount manually all partitions when going to suspend
+     *
+     * @return last error if any
+     */
+       QString unmountAllSuspend();
+
+    /**
+     * Remount previously unmounted partitions in unmountAllSuspend()
+     *
+     * @return last error if any
+     */
+    QString remountAllResume();

I have added umount support for these DCOP calls to KPowersave (currently wait for a mbuild of kdebase3 to test the code ...). 

@Lukas: Go this changes also upstream in KDE? 

Once they get aproved and tested here, I will submit them

Hm ... I can't umount a usbstick inserted in the machine. I get always the following message "Device to unmount is not in /media/.hal-mtab so it is not mounted by HAL"

This message came from HAL, but:
* the effected device is umounted after the call
* if I call unmount(UDI) with the udi of the device the call does not fail.

Because of this I assume the KDE code call a device to umount that not is mounted or it send something wrong to HAL. In my case KDE try also to umount /dev/sda8 which is my root partition.

@lukas: reassign to you to fix KDE code, please reassign to me if there is a new package available.

I have a different problem now: on resume the media are redetected by KDE.

Which means like they show up twice?

no, I get "what do you want to do with the DVD" on resume - which is nothing someone would expect

You should only umount media at external devices as e.g. at USB or firewire hosts (and maybe internal FAT/NTFS partitions if possible ... @seife: is this correct?) but nothing more 

(In reply to comment #18)
> hosts (and maybe internal FAT/NTFS partitions if possible ... @seife: is this
> correct?)

I do not care too much about the internal FAT/NTFS partitions anymore. We do boot directly into Linux without grub, and a user who disables this gets what he deserves. So there is no need to unmount FAT/NTFS partitions.

The problem we are seeing here is probably, that the external devices are "virtually unplugged" during suspend by the USB host controller driver, and "replugged" during resume. So this is probably what triggers the redetection in KDE.

still does not unmount the external ext3 partition. After suspending, pulling the drive and plugging into a different machine:

root@strolchi:~# e2fsck /dev/sdb2
e2fsck 1.39 (29-May-2006)
external (/dev/sdb2): recovering journal

Any news? We need this fixed for a YOU update (see #225212) which depends on this feature!

We need: umount external partitions and don't umount internal partitions KDE did _not_ mount as e.g. '/'

I'll add the functions ASAP

Fixed package submitted 

why is theis set to neednfo from me ? What info do you need ?

Hu? Lukas is infoprovider

Is there any update on this yet, Lukas? The fix for that is a requirement for the kpowersave update.

I'm doing the patch backport to 10.2 now, will submit later today

Fixed package submitted to 10.2

Submitted 2w ago, closing

released

You probably mean different packages. kpowersave is indeed released but there is still /work/src/done/10.2/kdebase3 sitting quietly since Feb 15.

*** Bug 253369 has been marked as a duplicate of this bug. ***

No need to assign to me :-)
I picked the info that this is fixed from the patchinfo file, Danny submitted for the kpowersafe update released last week. If this is not correct other databases will also be not correct. Please clarify.

1) I was not the assigne of the bug ... I reassign back to you
2) what have the KPowersa_v_e patchinfo file to do with the kdebase3 package?
3) I wrote more than one time in this bug and bug #225212 that we need to release KPowersave and kdebase3 at the same time.

Now I'm puzzled as well, what is blocking the release of the update? (comment #33 indicates I did my part of job)

*** Bug 254751 has been marked as a duplicate of this bug. ***

So who knows why kde3base is not released? Anja?
Have a look at the last duplicate ...

DISTRIBUTION: 10.2-i386,10.2-ppc,10.2-x86_64
PACKAGE: kdebase3
PACKAGER: ltinkl@suse.cz
BUGZILLA: 215262
SWAMPID: 8468
CATEGORY: recommended
SUMMARY: DCOP interface update for KPowersave
DESCRIPTION:
This update provides necessary DCOP functions for KPowersave to
properly (un)mount drives when going into sleep mode.

Package still not released, how to proceed now?

where have you submitted the patchinfo to?

To the usual place but it seems it disappeared :/ However, see comment #50 for the contents

I'm a little worried about this.

I currently have a problem where when I suspend and resume, on resume, I get a dialog saying that the suspend failed (false) because of some kind of media issue.  It has continue or cancel buttons.  If I continue, it suspends again (just after I resumed).  So needless to say I cancel.

I just tried 10.3 alpha 2, and on that platform, my laptop just suspends twice, always.  That is, I suspend and resume, and during resume, it suspends again.  On the second resume, it actually resumes.

I'm worried that if this is deployed, I'll get that behavior under 10.2, which is definitely not what I want.  I'd rather have the stupid dialog where I can at least hit cancel to prevent the second suspend.

Maybe this is groundless, but it would be great if someone could reassure me before posting this update.  Thanks.

My last comment notwithstanding, how come this hasn't been fixed?

Here's the behavior I now have:
 * When I suspend, about 95% of the time, it suspends immediately.  Sometimes I see a dialog pop up saying that the suspend failed before it succeeds, other times not.  But the dialog is always there on resume, saying that something went wrong and do I want to continue to suspend or cancel.  I have to click cancel or it will suspend again just after I resumed.
 * The other 5% of the time, that dialog comes up and the suspend attempt does not proceed.  In this case, I have to click the continue button to get the suspend to happen at all.

Presently, I've started recommending that everyone in our company avoid openSUSE 10.2.  The reason is that we all use laptops, and pretty much without exception, have them configured to suspend when the lid is closed.  The problem is that people close their laptop and stuff it in their bag.  The "other 5%" behavior means that a non-trivial amount of times, you close the lid but the suspend didn't execute (and won't until you re-open the machine and interact with the dialog box).  Then if you stuff it in your bag either the machine shuts down due to overheating, or it shuts down because the battery died because it can't suspend.

In other words, this issue is an operating system dealbreaker.  I don't understand why there's been no progress for over a month.

Or if you're not going to fix this, just roll back the KPowersave update that caused the problem I'm describing.  Before that update, there was no problematic dialog and therefore no issue.  It wasn't that onerous to edit a config file to set the properties that are now in the KPowersve dialog.  Certainly not compared to suspend being broken.

There's hope, I just checked in the patchinfo...

released

Unfortunately, my fears from comment 54 were realized.  Now every suspend happens twice.  While this isn't as severe as the suspend not happening at all, it is pretty annoying.  I'll file a separate report for it.

(In reply to comment #59)
> Unfortunately, my fears from comment 54 were realized.  Now every suspend
> happens twice.  While this isn't as severe as the suspend not happening at all,
> it is pretty annoying.  I'll file a separate report for it.

You should have done this from the beginning. Mixing up bugreports is almost always a bad idea (unless you do not want the bug fixed).

*** Bug 257363 has been marked as a duplicate of this bug. ***