spir posted on Thu, 19 Nov 2009 13:49:30 +0100 as excerpted:
> Seems to half-work now!
>
> After having run "hald --verbose=yes" while answering first response to
> my initial post, for any reason I tried again "solid-hardware list"
> which now runs. "lshal" runs, too. (But I can hardly imagine how to find
> proper info in such massive outputs.)
OK, hald is a system service. You evidently have it installed, but it
wasn't running (as a system service) until you started it. Once you
started it, it's now running... until reboot or you shut it down, anyway,
so you temporarily have that part taken care of.
Why it wasn't running as a system service, I don't know. Maybe it was a
fluke. Maybe it ran, but crashed for some reason and didn't auto-
restart, so nothing depending on it worked until you restarted it. Maybe
it's a system configuration issue.
In any case, what I'd do, now that you know how to start it, is reboot,
and see if it runs on its own now. If it does, that part of the problem
is hopefully solved. If it doesn't, and you don't know how setup system
services to run at boot or need to troubleshoot further, the *buntu
forums are the place to go for that as it would appear to be a
distribution specific issue, not kde related (kde just uses it... if
configured to do so but *buntu obviously is configured to do so).
> Cds and sub sticks now more or less (see below) are caught by the GUI,
> notified in the device notifier and show in Dolphin. Fine!
> But there are still a few remaining issues.
>
> .0. Why?
> Why does it work now, not before my last manips, not yesterday when I
> did exactly the same things? What has changed, precisely? As long as we
> cannot answer this, issues can come back seemingly randomly.
This one should be addressed above. For some reason, the system service
wasn't running. In your testing, you started it and it indeed ran and
kde can use it, so now, at that level, it's a matter of seeing whether it
runs by default and that was just a fluke, or if you need to configure
system services, which would be a topic for your distribution lists.
> .1. External cdrom (via usb) is mounted as /media/floppy1 ???
I've little idea there, as I've never used a USB connected CD/DVD
device. The general guess would be that again, it's a hal system config
issue, which would in turn trace back to the configuration your
distribution ships, which makes it a matter for the *buntu lists since
that's your distribution.
But as long as it works, you may be better off leaving it as-is. But see
below.
> .2. Cdrom content randomly shown or not The same issue as before
> upgrading to kde 4.3.2: in dolphin I need to change folder several times
> before cd content is shown. If not enough, need to take off and put back
> the cd physically.
Is this the same USB CD device as in #1? If so, the issues might be
related (thus the note on it to see below... here).
If it's an internal device or otherwise not now showing as floppy1... I
don't know. The instinct would be again to blame it on hal and the
distribution's hal config, especially since none of the rest of us have
seen that sort of works-sometimes-fails-sometimes behavior, but it's
conceivable you're running into some obscure kde bug, instead, tho it's
hard for me to groke what it might be. Really, I hate to be always
pointing the finger elsewhere, but this /does/ seem to be most likely a
hal bug and/or distribution config bug, which again places it elsewhere
than kde. But it's decidedly less certain on this one than on numbers 0
and 1.
> .3. Music cd content not shown at all Why?
Now this one CAN be considered a kde issue. Well, sort-of/maybe. The CD
is showing up in device notifier, right? (Here it shows up as the
generic "Volume", no name.) But clicking on the entry there produces...
what?
Normally there will be a popup window with various possible actions
available, depending on what apps you have installed.
If you have k3b installed (the kde4 version, 1.68.0_alphaX, where X is 3,
is what I have installed here, the kde3 version doesn't count), there
should be two actions associated with it, extract digital audio with k3b,
and copy with k3b. (FWIW, k3b isn't a kde-core app, but rather a very
well reviewed kde app that ships separately, so it will be a separate
package on most distributions, especially since the kde4 version is only
alpha, at present, but still quite usable.)
If you have KsCD (part of the kdemultimedia tarball as shipped by kde,
some distributions install it all as a single package, some split it down
into individual packages) installed, the popup should include an option
to "play audio cd with kscd" as well. However, if you have multiple CD
devices as I do, while the option will show up with all of them, kscd is
apparently only setup to deal with the first one, and choosing that
option with the CD in a different device starts kscd, but it then
protests that the cd device is empty (or not an audio CD, or it plays the
wrong one, depending on what's in the device it's looking at) because
it's looking in the wrong device!
It's possible other apps install choices as well, but those are the ones
I have.
What's notably missing from this list is an option to open the audio-cd
with dolphin/konqueror/$FM_OF_CHOICE. However, that's because CDAudio
isn't a proper filesystem at all, and therefore doesn't contain files, as
such, to be browsed.
If you look in "the application formerly known as kcontrol" (aka the
rather more generic "system settings", its modules are still called
kcm_*, an abbreviation for kcontrol-module-*), under advanced user
settings, device actions, you'll see the whole list of actions available
to kde, with various ones triggered according to the properties hal
passes on to kde. Don't try to change entries here -- it's unlikely to
work because the existing entries are system entries and you're running
as a normal user, and you don't want to risk messing the system entries
up anyway -- but if you want, you can create NEW entries, based on the
system entries already present. These will be user entries you can
change and delete at will, unlike the system entries.
In this kcm, you should see an option Open with File Manager. That's the
one that should popup with data devices -- those containing real
filesystems. If you open that action, you can verify that one of the
conditions is that it be a proper filesystem. (Actually making sense of
the action's decision tree can be a bit difficult if you're not familiar
with boolean decision trees, but once you understand them, it does make
sense, and you should be able to read them and create new ones of your
own using the provided wizard.) As I said, CDAudio isn't a real
filesystem, which is why it doesn't show up to be browsed in dolphin, etc.
I actually tried an experiment the last time someone brought this up, and
created a new action that didn't have the filesystem condition, that
would try opening the CDAudio anyway. Unsurprisingly, it didn't work,
because CDAudio isn't a filesystem, so there's no files to browse.
Now, kde has this real neat technology called kioslaves. These are
various plugins that among other things can use the available data to
provide a fake or virtual filesystem, and there is indeed a kioslave for
CDAudio, called audiocd: . IIRC, this was setup in kde3 such that you
could open an AudioCD, and browse it like a filesystem -- but remember
that was all an artificially created "virtual" filesystem, CDAudio format
does not contain a "real" filesystem, in the normal sense of the term.
The audiocd: kioslave presents the CD as a number of (virtual)
directories, wav, mp3 (tho some distributions won't include the mp3
choice due to patent issues... which are thankfully about to expire =:^),
ogv (ogg/vorbis), etc. In those directories are (virtual) files, one for
each track on the CD. But they're all virtual. If you attempt to copy
the files, "ripping" them to disk, as it's called, the kioslave does the
conversion on-the-fly, based on the default or user preset quality
settings for lossy formats such as mp3 and ogv.
kde4 still has the audiocd: kioslave, installed here as part of the
kdemultimedia-kioslaves package, I believe, probably with kdemultimedia
itself on those distributions that don't split it up. In dolphin (and
probably krusader if you use it), you can still enter audiocd:/ and
browse the CD (tho I don't use that often and just trying it, got a
permission problem, maybe because it's trying to open the empty one again
instead of the one I have the audio CD in, maybe because I don't use it
often enough to know the correct path to type in to get the second one
instead of the first). But the default device actions don't yet include
an action that activates the audiocd kioslave and opens the results in
your configured kioslave-compatible file manager. Arguably, that's a
deficiency that will likely be corrected at some point, but at least you
should be able to understand why audioCDs don't popup the choice to open
in the filemanager yet -- they don't contain a real filesystem so won't
work that way, and the kioslave presentation hasn't been made a default
action, yet.
Now someone technical who uses the audicd: kioslave enough to be familiar
with how it works could probably add an action to do it, but while I'm
sufficiently technical, I don't use that kioslave enough to be familiar
with it, and don't care enough about the issue to learn enough about it
to try it. I just use k3b if I need to.
Of course, if you're not getting the "Volume" showing up in the device
notifier to click on, that again is probably a hal/distribution config
issue. And if you are, but clicking on it doesn't produce the popup
window with any choices, perhaps you don't have the necessary apps
installed to /have/ any choices. Or if they ARE installed, it's probably
a distribution issue -- they probably didn't hookup the configuration for
it properly.
> .4. Not all memory sticks work fine
> I have 2 sticks, one (with important data) does not work at all.
>
> I suspect the source is that the one that is recognised had been once
> virus-infected when used by a friend, so that I formatted it (ext3). But
> the not-working one is probably in fat32 (as they are often so formatted
> by default). So, if I'm right, hal (or any other component in the chain
> between dmesg and gui) is unable to handle "alien" filesystems.
You could be be onto something with that! Can you mount the stick
manually? (Probably as root, using the command line interface and the
mount command.) You don't happen to have an entry for it in your fstab,
right? Because hal ignores stuff it sees in fstab, leaving it for the
traditional Unix file management stuff to deal with.
Does /proc/filesystems list fat/fat32/whatever as as a filesystem type?
If it's not there, the kernel itself doesn't understand the filesystem.
If you've configured and compiled your own kernel, you'd need to include
that. If not, it's probably a distribution issue.
[dmesg below reformatted]
> The one that works not is still seen by dmesg:
>
> [21101.204045] usb 1-6: new high speed USB device
> using ehci_hcd and address 13
> [21101.338734] usb 1-6: configuration #1 chosen from 1 choice
> [21101.339105] scsi17 : SCSI emulation for USB Mass Storage devices
> [21101.339314] usb-storage: device found at 13
> [21101.339318] usb-storage: waiting for device to settle
> before scanning
> [21106.336304] usb-storage: device scan complete
> [21106.337020] scsi 17:0:0:0: Direct-Access JetFlash
> Transcend 4GB 8.07 PQ: 0 ANSI: 2
> [21106.337810] sd 17:0:0:0: Attached scsi generic sg3 type 0
> [21106.370686] sd 17:0:0:0: [sdb] 7843840 512-byte logical blocks:
> (4.01 GB/3.74 GiB)
> [21106.372316] sd 17:0:0:0: [sdb] Write Protect is off
> [21106.372322] sd 17:0:0:0: [sdb] Mode Sense: 03 00 00 00
> [21106.372325] sd 17:0:0:0: [sdb] Assuming drive cache: write through
> [21106.394619] sd 17:0:0:0: [sdb] Assuming drive cache: write through
> [21106.394627] sdb: unknown partition table
> [21106.947324] sd 17:0:0:0: [sdb] Assuming drive cache: write through
> [21106.947337] sd 17:0:0:0: [sdb] Attached SCSI removable disk
>
> The line saying "unknown partition table" may be a key hint. But why did
> it work before updating?
If the device is formatted as a single filesystem, as most USB sticks
are, AFAIK, it won't have a partition table. Thus, that's an expected
line (unless you know it IS formatted with multiple partitions) and
doesn't mean anything in terms of the problem we're looking at.
At this point, it looks like your kernel isn't recognizing fat32. As I
said, check /proc/filesystems. If it's not listed there, that is indeed
your problem. Either reconfigure your kernel and recompile/reinstall, or
if you use a distribution kernel, check for a kernel modules package
including fat32, or otherwise take it up with your distribution.
If it's listed there, then the problem is elsewhere. Assuming a
distribution kernel and that it ships fat32 (aka vfat) as a module, see
if it's listed in lsmod. If lsmod doesn't list it, it's not loaded, and
apparently not setup for autoload. You may have to manually modprobe
it. Once it shows up in lsmod, try plugging your USB stick again, and
see if the result is different. If it's still not showing up in the
device notifier, then the problem is higher in the stack, either hal
(possible, given the other issues you seem to have with it), or in kde.
But first thing is to see if it's listed in /proc/filesystems, and if the
module is loaded (using lsmod), assuming it's not a kernel builtin, which
is unlikely unless you build your own kernel.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
