KDE-new & recent devices-widget-bad behavior after optical PATA-SATA swap.

openSUSE 11.3, 2.6.34.7-0.7-desktop, KDE 4.4.x, 3.0-P4, 2.5g mem.

I replaced PATA-OEM optical drive with SATA-OEM works fine with all apps outside of and except with this widget. No problems until the swap. I have performed some updates and I have not put the PATA drive back in to see if the behavior changed because it was failing. It could be an update but the optical drive swap is my first suspect. This now. If I hover cursor over notifier widget icon “last plugged in device” will pop up with accurate last device until a click on the widget icon and selection of action for the recently plugged in device. Selected actions work fine … once. Then it no longer updates the new or retains the previous DVD/CD (or any USB external drive when connected) entry. Closing after viewing but with out selecting an action results in an empty list also. The menu remains empty there after and only removal of the widget and reinstall makes the devices appear again … once. Then the behavior repeats if the widget is removed and reinstalled. I was wondering if this is likely to be a udev/rules.d problem related to the swap of the optical drives?

The 70-persistant-cd.rules file shows two cd’s after the swap:

# This file was automatically generated by the /lib/udev/write_cd_rules
# program, run by the cd-aliases-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and set the $GENERATED variable.

# CD_DVDW_SH-S182D (pci-0000:00:1f.2-scsi-1:0:0:0)
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-1:0:0:0", SYMLINK+="cdrom", ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-1:0:0:0", SYMLINK+="cdrw", ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-1:0:0:0", SYMLINK+="dvd", ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-1:0:0:0", SYMLINK+="dvdrw", ENV{GENERATED}="1"

# CDDVDW_SH-S223C (pci-0000:00:1f.2-scsi-0:0:0:0)
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-0:0:0:0", SYMLINK+="cdrom1", ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-0:0:0:0", SYMLINK+="cdrw1", ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-0:0:0:0", SYMLINK+="dvd1", ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-0:0:0:0", SYMLINK+="dvdrw1", ENV{GENERATED}="1"

If I delete or rename the 70-persistant-cd.rules file in udev/rules.d will it truly be recreated at boot and might it this fix the issue? Should I look elsewhere first at some var logs for errors? Reinstall 11.3 and let auto detect and config sort it out is also and option but I’d rather not, heh.

Not udev rules related. Renamed file, reboot and file auto created w/single drive. Behavior still same.

Resolved. Sheesh! Toddling linux newb. I’m not crawling exactlly, but not ready to walk fast or run yet. Learned a lot about dev, udev, hal and more. Having a lot of fun though! Don’t know why MY notifier jumped track but the ultimate fix was easy. Note to self: Creating a new user as suggested many times here to verify if the problem is related to user settings or to be found elsewhere is always a great first idea. Found please-try-agains’ suggestion to rename this file which will retain kde4 stuff like kmail etc. and provide a clean start of a borked kde desktop config. I didn’t delete the file (which would also work) but renamed it for backup. A new file with the same name will be recreated but with KDE defaults.

Several ways to rename this file but in terminal I did:

su -
cd /home/username
mv .kde4/share/config/plasma-desktop-appletsrc .kde4/share/config/plasma-desktop-appletsrc.bak
reboot