device issues with 'hald'

[spir]

Duncan <1i5t5.duncan at cox.net> wrote:

> 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).

Fortunately now we have wiktionary, for even my dictionary didn't know "fluke" ;-)
Now, when I start it as user "spir", is it supposed to do the job as well for other progs that need it (eg device notifier), or will it be useful only when started as system service (under fake user "haldaemon")? Note that yesterday I started it as well, and it didn't solve the issue. If needed, how can I run it as system service?

Hald is not listed at all as system service in the service manager list (neither as load on demand, nore as startup service). I was amazed of the few entries there. There is no way there to add a new service.

> > 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.

Well, I can see it in system monitor, so i'll know this as soon as I restart.
I noticed that even if _I_ started it as user "spir" it under under identity "haldaemon". Also, there hald-addon-acpi process under the same user name.

> > .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.

That's what I'll do.

> > .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).

No, the same with both drives (the other one internal).

<snip>

> > .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.
> 
<snip>
Thanks for all the precisions, I learn so much on this list :-)
(& hope other are interested, too)

> 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.

<snip>

I have this action popping up in device notifier (and also ripping by k3b since I did it once, and now ripping with audex newly magically added). When I use it, Dolphin opens in this folder, it even shows "audiocd:" above the folder content frame, but the view is just empty. So, there is an additional issue.

> > .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.)

Well, I would do it if I knew what (path) to mount. When I plug the one that works, it is mounted as /media/name_of_the_volume, but this does not tell me the original pathname. The whole stuff in dmesg does not tell me that, neither.

> 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.
 
Yo, /proc/filesystems knows about vfat :-)

> [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.

Right -- for sure there is no partitioning.

> 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.

Fortunately I don't need to recompile the kernel!

> 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.

It's listed in lsmod, too. woof!
dmesg still sees it and says it attached as "SCSI removable disk", but that's all what happens.

> 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.
> 

Thank for your help.

Denis


___________________________________________________
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.