device issues with 'hald'

[Duncan]

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.