|
|
Home | Switchboard | Unix Administration | Red Hat | TCP/IP Networks | Neoliberalism | Toxic Managers |
| (slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix | |||||||
| News | Recommended Links | Installation of Red Hat from a USB drive | SuSE install from USB drive | ||
| udev | Admin Horror Stories | Humor | Etc |
|
|
 |
 |
 |
December 2006 | LG #133
USB generally tends to be a trouble-free area of Linux: most modern distros handle it very well, and the degree to which it's become automated is very impressive (kudos to all the people involved - especially from those of us who remember the early days!) However, when it does break, troubleshooting can be rather difficult: there are a number of pieces that all have to work together. Even more problematic, which pieces have to work in what situation varies... and not all of these have 'usb' in the name.
With that in mind, let's take a look at what happens in some USB-related situations - including how the individual pieces break, and what can be done about them in the rare case when they do.
Inserting a USB pen-drive
So, what actually happens when we grab one of those ubiquitous pen-drive gadgets and insert it into a USB port? Let's watch the log (by running 'tail -f /var/log/messages') as we plug in and find out.
Sep 17 19:58:47 Fenrir kernel: usb 4-1: new high speed USB device using ehci_hcd and address 3 Sep 17 19:58:47 Fenrir kernel: usb 4-1: Product: Geek Squad Sep 17 19:58:47 Fenrir kernel: usb 4-1: Manufacturer: SanDisk Corporation Sep 17 19:58:47 Fenrir kernel: usb 4-1: SerialNumber: SNDK14050503CBF08502 Sep 17 19:58:47 Fenrir kernel: usb 4-1: configuration #1 chosen from 1 choice Sep 17 19:58:47 Fenrir kernel: scsi1 : SCSI emulation for USB Mass Storage devices Sep 17 19:58:47 Fenrir usb.agent[4021]: usb-storage: already loaded Sep 17 19:58:52 Fenrir kernel: Vendor: Model: Geek Squad Rev: 0.2 Sep 17 19:58:52 Fenrir kernel: Type: Direct-Access ANSI SCSI revision: 02 Sep 17 19:58:52 Fenrir kernel: SCSI device sda: 2001888 512-byte hdwr sectors (1025 MB) Sep 17 19:58:52 Fenrir kernel: sda: Write Protect is off Sep 17 19:58:52 Fenrir kernel: SCSI device sda: 2001888 512-byte hdwr sectors (1025 MB) Sep 17 19:58:52 Fenrir kernel: sda: Write Protect is off Sep 17 19:58:52 Fenrir kernel: sda:<7>usb-storage: queuecommand called Sep 17 19:58:52 Fenrir kernel: sda1 Sep 17 19:58:52 Fenrir kernel: sd 1:0:0:0: Attached scsi removable disk sda Sep 17 19:58:53 Fenrir scsi.agent[4058]: sd_mod: loaded successfully (for disk)That's a lot of info... fortunately, it's mostly self-explanatory.
The fact may not be all that clearly visible here, since it's all lumped under "kernel:" messages, but - the 'hotplug' system detected a change on one of the ports that it was watching. After the initial handshake, which gave it a bunch of data, it assigned address '3' to the device (these device numbers are sequential: the last USB device I used, which just happened to be the same pen-drive, got a '2'.) It then logged a bunch of human-readable data telling me what the device reported itself to be, loaded any required modules that had not yet been loaded, and attached the device via the appropriate driver (i.e., created an access point for it in the file system) to a "special" file in the "/dev" directory, at "/dev/sda1". This, in turn, allows us to mount the device on a directory in our file system in the usual way.
Famous Last Words ("What Could Possibly Go Wrong?")
If the "hotplug" system doesn't work, the game is over before it even starts: no detection means no device identification means no module loading means no driver installation means no mounting. End of game, thank you for playing. So, what can we do if there are no messages whatsoever in the log no matter how frantically we fiddle and frob the USB dongle?
First, check to see that "hotplug" is installed on your system. In Debian, for example, the package system is easily queried:
ben@Fenrir:~$ dpkg -l hotplug Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-==========================-==========================-===================== ii hotplug 0.0.20040329-25 Linux Hotplug ScriptsIn this case, "hotplug" is fully installed. The next question is, has hotplug support been compiled into the kernel?
ben@Fenrir:~$ ls -l /proc/sys/kernel/hotplug -rw-r--r-- 1 root root 0 2006-09-17 20:32 /proc/sys/kernel/hotplugYep, the entry for it exists in "/proc". Next, is it running? Well... the problem is that 'hotplug' doesn't really have a daemon in the classic sense - it's integrated into the driver core in the kernel - so there's nothing to check for in the process table. What to do, what to do... oh, it's simple - we'll just start the system manually, no harm in that.
ben@Fenrir:~$ su -c '/etc/init.d/hotplug start' Password: Starting hotplug subsystem: pci intel-agp: already loaded uhci-hcd: loaded successfully uhci-hcd: already loaded uhci-hcd: already loaded ehci-hcd: loaded successfully snd-intel8x0: already loaded ignoring pci display device 01:00.0 b44: already loaded ipw2200: already loaded yenta_socket: already loaded ohci-hcd: loaded successfully ohci-hcd: already loaded pci [success] usb usb-storage: already loaded cdc-acm: already loaded usb [success] isapnp isapnp [success] ide ide [success] input input [success] scsi sd_mod: loaded successfully (for disk) scsi [success] done.Your list of modules will almost certainly be different; the important thing is that you see a list of modules loading under the 'pci', 'usb', and [possibly, depending on what you've compiled in your kernel] 'scsi' subheadings.
At this point, your basic hotplug system should be OK.
USBFS
Something that comes in very useful when troubleshooting USB is the 'usbfs' virtual file system. To get access to it, compile this option into the kernel (CONFIG_USB_DEVICEFS=y) and list it in '/etc/fstab' (the relevant line reads "none /proc/bus/usb usbfs noauto 0 0", and it is loaded by the kernel when the USB subsystem is detected.) The result is a series of entries (directories) in "/proc/bus/usb", one for each detected device plus a "devices" file containing human-readable descriptions. With this, it's very easy to tell if your system recognizes a given USB device or not - and if you end up with some truly strange USB device that isn't listed in the hotplug system's device database, you can even create your own usermap for it in "/etc/hotplug/usb/" (the necessary 'match_flags', 'idVendor', and 'idProduct' information is shown in the "devices" file.) What more could you possibly want?
Modules
So, we've detected the device and identified it... but let's say that there's still no joy in Mudville. In the most common scenario, the log would look something like this:
Sep 17 19:43:08 Fenrir kernel: usb 4-1: new high speed USB device using ehci_hcd and address 2 Sep 17 19:43:08 Fenrir kernel: usb 4-1: Product: Geek Squad Sep 17 19:43:08 Fenrir kernel: usb 4-1: Manufacturer: SanDisk Corporation Sep 17 19:43:08 Fenrir kernel: usb 4-1: SerialNumber: SNDK14050503CBF08502 Sep 17 19:43:08 Fenrir kernel: usb 4-1: configuration #1 chosen from 1 choice Sep 17 19:43:08 Fenrir kernel: scsi0 : SCSI emulation for USB Mass Storage devices Sep 17 19:43:09 Fenrir usb.agent[3687]: usb-storage: already loaded Sep 17 19:43:13 Fenrir kernel: Vendor: Model: Geek Squad Rev: 0.2 Sep 17 19:43:13 Fenrir kernel: Type: Direct-Access ANSI SCSI revision: 02 Sep 17 19:43:13 Fenrir scsi.agent[3730]: sd_mod: can't be loaded (for disk)Whoops! What do you mean, "can't be loaded"? Oh, right, right... there's still the small matter of having the appropriate module. USB is only the interface method; at the end of all that connecting, the important bit is what device we're connecting TO. In the case of the pen-drive, it's fairly common to have it show up as "/dev/sda1" or "/dev/sdb1" (or, less commonly, "/dev/sda") - in any case, it looks like a SCSI device, which means that we need to have SCSI support (and specifically SCSI disk support) in the kernel. It's preferable to have the latter compiled as a module, so the relevant kernel options look like this:
# SCSI device support # CONFIG_SCSI=y ... # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=mThe above is, of course, highly variable and dependent on the device you're inserting.
And Then What?
Assuming that you have your "/etc/fstab" properly configured - i.e., you have entries that look something like this:
ben@Fenrir:~$ grep sd /etc/fstab /dev/sda /mnt/sda vfat user,noauto,gid=103,rw,fmask=113 0 0 /dev/sda1 /mnt/sda1 vfat user,noauto,gid=103,rw,fmask=113 0 0 /dev/sdb /mnt/sdb vfat user,noauto,gid=103,rw,fmask=113 0 0 /dev/sdb1 /mnt/sdb1 vfat user,noauto,gid=103,rw,fmask=113 0 0 /dev/sdc /mnt/sdc vfat user,noauto,gid=103,rw,fmask=113 0 0- the rest is very simple:
ben@Fenrir:~$ mount /mnt/sda1 ben@Fenrir:~$ mount|grep sda1 /dev/sda1 on /mnt/sda1 type vfat (rw,noexec,nosuid,nodev,gid=103,fmask=113,user=ben)Wrap-up
As I mentioned originally, the USB subsystem in Linux is well-configured and as automatic as anything related to computers can hope to be; usually, it's no trouble at all. However, for those few times when it doesn't behave quite right, I hope I've given you some good tools for getting it back in shape. Good luck!
--
* Ben Okopnik * Editor-in-Chief, Linux Gazette * http://LinuxGazette.NET *
[Kapil Hari Paranjape] Hello,
On Sun, 17 Sep 2006, Benjamin A. Okopnik wrote: > > The Monthly Troubleshooter: The USB SubsystemIn this context you might find the following post interesting.
http://www.infodrom.org/~joey/log/?200609102259
The rest is out-of-band for the USB subsystem.Of course, the question does arise: How will people learn about GNU and Linux once everything starts working smoothly? I can certainly vouch for the fact that many of the things I learnt about computers, I learnt because the computer was not doing things the way I wanted it to.
From Personal Experience: There are two types of mathematics books. There are those where the author has taken great pains to construct the most illuminating exercises for the student to solve at the end of each chapter. ... And then there are the books where there are mistakes in the text.[Thomas Adam]
Kapil Hari Paranjape <kapil at imsc.res.in> wrote: > > Of course, the question does arise: How will people learn about > GNU and Linux once everything starts working smoothly? I can > certainly vouch for the fact that many of the things I learnt about > computers, I learnt because the computer was not doing things the > way I wanted it to.They don't need to worry about that anymore. With the use of GNOME and KDE, all of those worries are hidden behind flashy buttons and dialogue windows.
[Ben Okopnik]
Kapil Hari Paranjape wrote: > > Of course, the question does arise: How will people learn about > GNU and Linux once everything starts working smoothly?Well... as reliable and tough as Linux software tends to be (after it's had all the bugs beaten out of it by insane^Whyper-focused^Wdetermined users, it doesn't dare do anything else), there are still hardware failures, new or odd peripherals [1], strange USB configurations, and experimentation. The thing that I appreciate about the 'hotplug' system in this regard is how open (whodathunk it?) the system is to hacking in new bits - that's a good piece of design, especially considering how byzantine the ins and outs of that system used to be. A kernel-based driver with a shell-script "interface" is a very cool idea.
[1] The first portable MP3 player I had was a Samsung Yepp - an odd gadget that looked like a flattened egg and could store something like 32MB. Someone had written a piece of software that would perform the necessary functions for it, but getting it connected to my machine so that the software could read it was quite the fraught process. I ended up studying the 'hotplug' system (mostly by reading the scripts in '/etc/hotplug'), and writing a usermap and a connector script for it, both of which went into '/etc/hotplug/usb':
(yepp.usermap)
# usb module match_flags idVendor idProduct bcdDevice_lo bcdDevice_hi bDeviceClass bDeviceSubClass bDeviceProtocol bInterfaceClass bInterfaceSubClass bInterfaceProtocol driver_info yepp 0x0003 0x04e8 0x5a03 0x0000 0x0000 0x00 0x00 0x00 0x00 0x00 0x00 0x00000000(yepp)
#!/bin/sh . /etc/hotplug/hotplug.functions mesg setting permissions of $DEVICE chgrp staff $DEVICE chmod g+w $DEVICEThe info for the usermap came from the USBFS device descriptions, as I mentioned in the article. From then on, all I ever had to do was plug the Yepp's cable into a USB port and fire up the software.
> I can > certainly vouch for the fact that many of the things I learnt about > computers, I learnt because the computer was not doing things the > way I wanted it to.[nod] That's exactly what I'm trying to replicate in the Monthly Troubleshooter series - the (fortunately) rare bits of experience that I hope our readers will never run into, but will now have some clues on handling if they ever do.
I'm also hoping that our readers who have successfully dealt with problems in the various Linux subsystems, especially if it's happened more than once (I am, of course, including everyone on this list) will write us at [email protected] and tell us about their solutions - preferably including the words "Monthly Troubleshooter:" in the subject. I really liked the discussion that happened around the printer topic because other people had included their experiences; as a result, I think that a lot of people will benefit from that one.
> From Personal Experience: > > There are two types of mathematics books. > > There are those where the author has taken great pains to > construct the most illuminating exercises for the student > to solve at the end of each chapter. > > ... And then there are the books where there are mistakes > in the text.
[chuckle] Both types can be very educational, although in somewhat different ways; the second type may require a brick wall and a strong forehead. On the other hand, it does have the benefit (which the first type lacks) of instilling the idea of checking everything - and that even the reference material could be wrong, which is a lesson that can come at a high cost if not learned early on.
http://www.readbookonline.net/readOnLine/2437/[Martin Hooper]
On 20/09/2006 Benjamin A. Okopnik wrote: > > http://www.readbookonline.net/readOnLine/2437/I don't know if anyone else is using Firefox to view that page but it doesn't work.
I'm guessing that if I use IE then it would...
[Ben Okopnik]
Martin Hooper wrote: > On 20/09/2006 Benjamin A. Okopnik wrote: > > > http://www.readbookonline.net/readOnLine/2437/ > > I don't know if anyone else is using Firefox to view that page > but it doesn't work.Works fine in Mozilla, Firefox, dillo, w3m, and Lynx.
ben@Fenrir:~$ mozilla-suite -v Mozilla 1.7.13, Copyright (c) 2003-2004 mozilla.org, build 2006080919 ben@Fenrir:~$ firefox -v Mozilla Firefox 1.5.0.6, Copyright (c) 1998 - 2006 mozilla.org ben@Fenrir:~$ dillo -v Dillo 0.8.5-i18n-misc> I'm guessing that if I use IE then it would...Have you tried scrolling down? The text doesn't start until well down the page.
[Martin Hooper]
Benjamin A. Okopnik wrote: > Have you tried scrolling down? The text doesn't start until well down > the page.Ah yes - Got there now!! Just that there's a lot of white space between the top of the page and the content.. ;)
[Ben Okopnik]
On Wed, Sep 20, 2006 at 01:41:27PM +0100, Thomas Adam wrote: > Kapil Hari Paranjape <kapil at imsc.res.in> wrote: > > > > Of course, the question does arise: How will people learn about > > GNU and Linux once everything starts working smoothly? I can > > certainly vouch for the fact that many of the things I learnt about > > computers, I learnt because the computer was not doing things the > > way I wanted it to. > > They don't need to worry about that anymore. With the use of GNOME and > KDE, all of those worries are hidden behind flashy buttons and dialogue > windows.Wind0ws? Did somebody just mention Wind0ws?
In my opinion, KDE and Gnome are very nice tools... but the intended use for those tools has nothing to do with administering or maintaining Linux. It has to do with easing people from the Wind0ws world past the oh-so-terrifying idea that another OS will slit their throats, rape their Chihuahuas, and run away to Monaco with their money - and into using the same applications in pretty much the same way as they always have, marketing hype to the contrary notwithstanding.
It's possible to debate the long-term usefulness of this approach. I, for example, have strong reservations about it maintaining the irresponsible mindset that is trained into many Wind0ws users by the shiny, glitzy interface ("just put gas into it, and leave Complicated Stuff like checking the oil to the professional mechanics!") - this is what allows viruses, etc. to propagate - but there are many people whose only reason for switching to Linux was the ability to "keep doing the same thing as before". Perhaps the question is, would it be better to have a huge slew of ignorant users on vulnerability-riddled platforms, or to have them using an OS which is well-designed and stable? The concerns and the answers regarding the uses of KDE, etc. are not mutually exclusive, but rather orthogonal.
[Thomas Adam]
"Benjamin A. Okopnik" <ben at linuxgazette.net> wrote: > In my opinion, KDE and Gnome are very nice tools... but the intended > use for those tools has nothing to do with administering or > maintaining Linux. It has to do with easing people from the Wind0ws > world past the oh-so-terrifying idea that another OS will slit their > throats, rape their Chihuahuas, and run away to Monaco with their > money - and into using the same applications in pretty much the same > way as they always have, marketing hype to the contrary > notwithstanding.That is as maybe -- and whether or not KDE and GNOME are out on a mission to wean people using Windows to Linux, the fact remains that with GNOME (especially in Ubuntu, for example), the de facto functionality is to automount and run Nautilus for any device that you can shove into one of the many orifices your computer comes with nowadays; USB included. :P
Whilst that could be deemed appropriate for someone new to Linux, it could also be considered one of convenience for the more experienced user. Of course, what it doesn't do is allow you to easily see what is happening behind the scenes. Maybe in some instances this is a good thing; I am not sure whether it is or not at the moment.
But the whole USB subsystem is getting much better than it used to be. By that, I really mean hotplug. It used to be an abomination a few years ago; using some form of black magic (tm) to somehow select the devices, etc. But it is by no means perfect. I think one of the biggest issues that throws people is the lack of consistency between the device mappings between unplugging and replugging the devices -- especially if it is a mass-storage device (c.f. /dev/sda1, /dev/sda2, etc.) This gets slightly better if you're one of these people who subscribes to the whole "udev" experience. But as I am known for making my views all too clear about why I hate udev, I do not use it. :P
> It's possible to debate the long-term usefulness of this approach. I, > for example, have strong reservations about it maintaining the > irresponsible mindset that is trained into many Wind0ws users by the > shiny, glitzy interface ("just put gas into it, and leave Complicated > Stuff like checking the oil to the professional mechanics!") - this is > what allows viruses, etc. to propagate - but there are many people > whose only reason for switching to Linux was the ability to "keep > doing the same thing as before". Perhaps the question is, would it beI'm not going to rehash this one -- around issue #96 onwards I published several exchanges like the one here for 'Windows Defectors'. So I'll point any readers to those. Plus it saves me typing.
[Pedro Fraile Pérez] I am running Ubuntu Dapper here, and the USB subsystem works as is to be expected, only the package 'hotplug' does not exist any more. In fact, it is not to be found among the repositories. I remember I was confused for quite some time when I upgraded from Breezy, and found out that most of my /etc/hotplug* was gone, there was no /sbin/hotplug, and some things were not working any more ... until I (correctly) installed udev. Your message has finally impulsed me to try to find out for sure what happened, and the answer seems to lie withing these threads (please correct me if I am wrong)
http://lists.debian.org/debian-devel/2005/08/msg01454.html
http://lists.debian.org/debian-devel/2005/09/msg00732.htmlOne thing I am still missing is the knowledge on how to troubleshoot the combination udev / hal / sysfs (Does hal has something to do with the other two?). I have minor glitches with a couple of things: an USB stick that is automounted on a back slot of a Dell box, but not on a front one - and no hardware problem here, for sure -, or a DVD writer that takes all the /dev/{cdr*,dvd*} symlinks, instead of leaving the /dev/cdrom to the other CD reader. In the all days, I would have modified some script under /etc/hotplug.d/ to log some information on a temporary file, but I do not know of a similar strategy with udev. I have to admit that I have not invested tons of time on it though ...
> Something that comes in very useful when troubleshooting USB is the > 'usbfs' virtual file system. To get access to it, compile this option > into the kernel (CONFIG_USB_DEVICEFS=y) and list it in > '/etc/fstab' (the relevant line reads "none /proc/bus/usb usbfs > noauto 0 0", and it is loaded by the kernel when the USB subsystem is > detected.)No usbfs entry in my /etc/fstab either, but procbususb gets mounted on /proc/bus/usb at boot anyway ...
> Assuming that you have your "/etc/fstab" properly configured - i.e., > you have entries that look something like this: > > `` > ben@Fenrir:~$ grep sd /etc/fstab > /dev/sda /mnt/sda vfat user,noauto,gid=103,rw,fmask=113 0 0 > /dev/sda1 /mnt/sda1 vfat user,noauto,gid=103,rw,fmask=113 0 0 > /dev/sdb /mnt/sdb vfat user,noauto,gid=103,rw,fmask=113 0 0 > /dev/sdb1 /mnt/sdb1 vfat user,noauto,gid=103,rw,fmask=113 0 0 > /dev/sdc /mnt/sdc vfat user,noauto,gid=103,rw,fmask=113 0 0Another difference here is the use of 'pmount'. From 'aptitude show pmount':
Description: mount removable devices as normal userThe net result being that (under gnome, at least) any removable media gets mounted on an ad-hoc created /media/whatever with the right user permissions, without any entry in fstab. Cannot say I dislike it ...
[Ben Okopnik]
On Thu, Sep 21, 2006 at 08:58:33AM +0100, Thomas Adam wrote: > "Benjamin A. Okopnik" <ben at linuxgazette.net> wrote: > > In my opinion, KDE and Gnome are very nice tools... but the intended > > use for those tools has nothing to do with administering or > > maintaining Linux. It has to do with easing people from the Wind0ws > > world past the oh-so-terrifying idea that another OS will slit their > > throats, rape their Chihuahuas, and run away to Monaco with their > > money - and into using the same applications in pretty much the same > > way as they always have, marketing hype to the contrary > > notwithstanding. > > That is as maybe -- and whether or not KDE and GNOME are out on a > mission to wean people using Windows to Linux, the fact remains that > with GNOME (especially in Ubuntu, for example), the de facto > functionality is to automount and run Nautilus for any device that > you can shove into one of the many orifices your computer comes with > nowadays; USB included. :PI'll have to install Gnome and try shoving a screwdriver into the fan vent. The mounting procedure ought to be interesting, to say the least.
> I think one of the > biggest issues that throws people is the lack of consistency between > the device mappings between unplugging and replugging the devices -- > especially if it is a mass-storage device (c.f. /dev/sda1, /dev/sda2, > etc.)Really? I actually have symlinks in my '/mnt' that are hard-wired to specific devices:
r!ls -FAlS /mnt total 36 drwxrwxr-x 2 root staff 4096 2005-11-22 16:19 hda1/ drwxr-xr-x 2 root root 4096 2005-11-22 16:09 hdc/ drwxr-xr-x 2 root root 4096 2005-11-22 16:09 sda/ drwxr-xr-x 2 root root 4096 2005-11-22 16:09 sda1/ drwxr-xr-x 2 root root 4096 2005-11-22 16:09 sdb/ drwxr-xr-x 2 root root 4096 2005-11-22 16:09 sdb1/ drwxr-xr-x 2 root root 4096 2006-04-26 13:28 sdc/ drwxr-xr-x 2 root root 4096 2005-11-22 16:09 sr0/ drwxr-xr-x 2 root root 4096 2004-05-10 20:26 test/ lrwxrwxrwx 1 root root 4 2005-11-22 16:10 olympus -> sda1/ lrwxrwxrwx 1 root root 4 2005-11-22 16:19 puppy -> hda1/ lrwxrwxrwx 1 root root 4 2005-11-22 16:12 sdcard -> sdb1/ lrwxr-xr-x 1 root root 3 2005-12-08 12:31 dvd -> sr0/ lrwxrwxrwx 1 root root 3 2005-11-22 16:11 dvd-scsi -> sr0/ lrwxrwxrwx 1 root root 3 2005-11-22 16:11 flash -> sdb/'olympus' (my digital camera), 'sdcard' (the SD card from my Palm Pilot), and 'flash' (my USB thumb drive) are absolutely consistent in the device names that they get assigned to.
> This gets slightly better if you're one of these people who > subscribes to the whole "udev" experience. But as I am known for > making my views all too clear about why I hate udev, I do not use > it. :PI've tried 'udev' at one point, and gave up on it - I don't recall why. Perhaps I caught something from you via email.
[Kapil Hari Paranjape]
On Thu, 21 Sep 2006, Pedro Fraile Pérez wrote: > El Sun, 17 Sep 2006 21:47:54 -0400 > "Benjamin A. Okopnik" <ben at linuxgazette.net> wrote: > > > > The Monthly Troubleshooter: The USB Subsystem > > ============================================= > > > ... until I (correctly) > installed udev. Your message has finally impulsed me to try to find out > for sure what happened, and the answer seems to lie withing these > threads (please correct me if I am wrong) > > http://lists.debian.org/debian-devel/2005/08/msg01454.html > http://lists.debian.org/debian-devel/2005/09/msg00732.htmlIndeed. This is a problem for all those udev-haters out there
> One thing I am still missing is the knowledge on how to troubleshoot > the combination udev / hal / sysfs (Does hal has something to do with > the other two?).Absolutely. HAL is the AI in the system
Q: Can I use udev to automount a USB device when I connect it? A: Technically, yes, but udev is not intended for this. All major distributions use HAL (http://freedesktop.org/wiki/Software_2fhal) for this, which also watches devices with removable media and integrates the Desktop environment.Alternatively, it is easy to add the following to fstab:
/dev/disk/by-label/PENDRIVE /media/PENDRIVE vfat user,noauto 0 0This means that users can access the device with:
$mount /media/PENDRIVE
and doen't have to be root, but will get full permissions on the device. Using the persistent disk links (label, uuid) will always catch the same device regardless of the actual kernel name.> I have minor glitches with a couple of things: an USB > stick that is automounted on a back slot of a Dell box, but not on a > front one - and no hardware problem here, for sure -,Actually this is probably a hardware problem as I discovered.
The problem is that there are two types of USB ports. Those that supply suficient power and those that do not. If you have a device which requires power to be supplied through the USB socket and you connect to a USB port that does not supply power (or does not supply enough of it) then the device will not work.
I found this out when I was trying to connect an external USB disk to a Mac PowerBook (inappropriately named!). It turns out that the PowerBook only has low/no power USB sockets and so the disk needs external power in order to work (the disk happily had a socket for such an adapter). In the process I also discovered why this disk had ben behaving exactly as you described with another Intel-based machine that had Front and Back USB ports.
> In the all days, I would have > modified some script under /etc/hotplug.d/ to log some information on a > temporary file, but I do not know of a similar strategy with udev. I > have to admit that I have not invested tons of time on it though ...Again quoting from the udev NEWS.Debian:
Scripts in /etc/dev.d/ and /etc/hotplug.d/ are not supported anymore unless the hotplugd.rules rules file is manually enabled. -- Marco d'Itri <md at linux.it> Thu, 17 Aug 2006 14:40:34 +0200So if you have a recent sid/etch then you can enable the scripts but its going to take some work.
> The net result being that (under gnome, at least) any removable media > gets mounted on an ad-hoc created /media/whatever with the right > user permissions, without any entry in fstab. Cannot say I dislike > it ...I think the problem is what-if. What if there is a device that I do not want automounted? There is perhaps not an easy way to prevent that from happening.
[Rick Moen]
Quoting Kapil Hari Paranjape (kapil at imsc.res.in): > Absolutely. HAL is the AI in the systemUgh. That's repulsive -- if only because of the dependency on glib (about which it's said "this dep will be dropped soon"). Something with the smell of GNOME about it has no business getting anywhere near my kernels.
[Kapil Hari Paranjape]
On Thu, 21 Sep 2006, Rick Moen wrote: > > Ugh. That's repulsive -- if only because of the dependency on glib > (about which it's said "this dep will be dropped soon"). Something with > the smell of GNOME about it has no business getting anywhere near my > kernels.
One alternative is "usbmount" which specifically indicates:
USBmount is intended as a lightweight solution which is independent of a desktop environment. Users which would like an icon to appear when an USB device is plugged in should use the pmount and hal packages instead.There is also the more general purpose "am-utils" but using this when one only wants to mounts USB sticks is perhaps excessive.
[Pedro Fraile Pérez]
Kapil Hari Paranjape <kapil at imsc.res.in> escribi?: > > On Thu, 21 Sep 2006, Pedro Fraile P?rez wrote: > > > I have minor glitches with a couple of things: an USB > > stick that is automounted on a back slot of a Dell box, but not on a > > front one - and no hardware problem here, for sure -, > > Actually this is probably a hardware problem as I discovered. > > The problem is that there are two types of USB ports. Those that > supply suficient power and those that do not. If you have a device > which requires power to be supplied through the USB socket and you > connect to a USB port that does not supply power (or does not supply > enough of it) then the device will not work.Hello Kapil,
That's a good piece of info, but I am afraid it is not my case. Under several versions of Windows, the memory stick is mounted both in the front and back slots, so there must be some kind of driver issue here.
> > The net result being that (under gnome, at least) any removable > > media gets mounted on an ad-hoc created /media/whatever with the > > right user permissions, without any entry in fstab. Cannot say I > > dislike it ... > > I think the problem is what-if. What if there is a device that I do > not want automounted? There is perhaps not an easy way to prevent > that from happening.Yes, I agree. You can disable the automounting process for all removable devices, but I have not yet found out how you can do it on a per-device basis.
[Kapil Hari Paranjape]
On Fri, 22 Sep 2006, Kapil Hari Paranjape wrote: (quoting from the udev FAQ) > Alternatively, it is easy to add the following to fstab: > /dev/disk/by-label/PENDRIVE /media/PENDRIVE vfat user,noauto 0 0 > > This means that users can access the device with: > $mount /media/PENDRIVE > and doen't have to be root, but will get full permissions on the device. > Using the persistent disk links (label, uuid) will always catch the > same device regardless of the actual kernel name.These instructions seem to work ... but you don't need udev to make this work!
When you make the file system give it a "label". Most filesystem types (even DOS and Windows types like FAT and VFAT) allow you to set a label. You can then mount the system by
mount -L <your label> <mount point>Alternatively your fstab could contain entries like:
LABEL=DOST /media/DOST vfat rw,user,noauto 0 0 LABEL=LEAN /media/LEAN ext2 rw,user,noauto 0 0You can then mount the disks (as a user) with a command like:
mount /media/DOSTThis doesn't work for those cameras that appear as USB memory devices to your computer unless the manufacturer is kind enough to give the device a label when it is formatted.
[Martin Hooper]
On 29/09/2006 Kapil Hari Paranjape wrote: > mount -L <your label> <mount point> > > Alternatively your fstab could contain entries like: > LABEL=DOST /media/DOST vfat rw,user,noauto 0 0 > LABEL=LEAN /media/LEAN ext2 rw,user,noauto 0 0How do you create labels then?? I guess its an option to mkfs...
[Ben Okopnik]
On Thu, Sep 21, 2006 at 09:16:57PM +0200, Pedro Fraile P?rez wrote: > > One thing I am still missing is the knowledge on how to troubleshoot > the combination udev / hal / sysfs (Does hal has something to do with > the other two?).Hmmm, you've got me; I'm still using hotplug. Anybody else care to comment?
> > Something that comes in very useful when troubleshooting USB is the > > 'usbfs' virtual file system. To get access to it, compile this option > > into the kernel (CONFIG_USB_DEVICEFS=y) and list it in > > '/etc/fstab' (the relevant line reads "none /proc/bus/usb usbfs > > noauto 0 0", and it is loaded by the kernel when the USB subsystem is > > detected.) > > No usbfs entry in my /etc/fstab either, but procbususb > gets mounted on /proc/bus/usb at boot anyway ...Actually, given that the entry in my '/etc/fstab' says "noauto", I was wondering about that. I used to mount it manually, but looking at it now, it's clearly being mounted by the kernel - perhaps when USB support gets loaded? It would have made sense to automate it, since it's such a useful gadget. Looking at 'dmesg' output, there's nothing noting it... I suspect that '/etc/fstab' line is no longer necessary.
[Thomas Adam]
Benjamin A. Okopnik <ben at linuxgazette.net> wrote: > On Thu, Sep 21, 2006 at 09:16:57PM +0200, Pedro Fraile P?rez wrote: > > > > One thing I am still missing is the knowledge on how to troubleshoot > > the combination udev / hal / sysfs (Does hal has something to do > > with the other two?). > > Hmmm, you've got me; I'm still using hotplug. Anybody else care to > comment?HAL works by abstraction. Essentially by the time HAL kicks in, it will have already realised what the interface is that $DEVICE is using. So of course before that can happen, hotplug must have been working to recognise the device. It has to load the driver, manage what's in /dev, and provide some mechanism of accessing it.
It's mounted, which of course means that applications such as GNOME can then shunt a nice icon on its desktop for users to use.
[Kapil Hari Paranjape]
On Fri, 29 Sep 2006, Martin Hooper wrote: > On Fri, 29 Sep 2006, Kapil Hari Paranjape wrote: > > When you make the file system give it a "label". Most filesystem > > types (even DOS and Windows types like FAT and VFAT) allow you to > > set a label. > How do you create labels then?? I guess its an option to mkfs...
To make this more clear:
mkdosfs -n <your label> <other options> mke2fs -L <your label> <other options>Perhaps those who use other file systems can pitch in with what is required for xfs, jfs, reiserfs, ...
[John Karns]
On Sat, 30 Sep 2006, Kapil Hari Paranjape wrote: > On Fri, 29 Sep 2006, Kapil Hari Paranjape wrote: >> When you make the file system give it a "label". Most filesystem >> types (even DOS and Windows types like FAT and VFAT) allow you to >> set a label. > > To make this more clear: > mkdosfs -n <your label> <other options> > mke2fs -L <your label> <other options> > Perhaps those who use other file systems can pitch in with > what is required for xfs, jfs, reiserfs, ...A quick check of the man pages for the filesystems mentioned above shows that the convention is mkfs.<type> "-L <label>" (for xfs, jfs and reiserfs4). The older reiserfs (pre-version 4) is an exception and calls for the flag as lowercase "-l <label>".
|
|
|
In addition to managing drivers and handlers, the input core also exports a useful /proc filesystem interface, which can be used to see what devices and handlers are currently active. Here is a typical example from /proc/bus/input/devices showing a USB mouse:I: Bus=0003 Vendor=046d Product=c002 Version=0120 N: Name="Logitech USB-PS/2 Mouse M-BA47" P: Phys=usb-00:01.2-2.2/input0 H: Handlers=mouse0 event2 B: EV=7 B: KEY=f0000 0 0 0 0 0 0 0 0 B: REL=103The I: line is the identity information-showing bus type 3 (which is USB) and the vendor, product and version information from the USB descriptors in the mouse. The N: line shows the name, which in this case is a string provided by the USB descriptors. The P: line shows the physical device information; here, it's structure information comprised of the PCI address for the USB controller, the USB tree and the input interface. The input0 part indicates this is the first logical input device for the physical device. Some devices, such as multimedia keyboards, can map part of the physical device to one logical input device and map another part to a second logical input device. The H: line shows the handler drivers associated with this device; we'll discuss this in more detail later in the article. The various B: lines show the bitfields that identify the devices' capabilities, in this case some keys for the buttons and relative axes for the ball and the scroll wheel.
Handlers
Getting to User Space In the previous section, we saw that the device drivers basically sat between the hardware and the input core, translating hardware events, usually interrupts, into input events. To make use of those input events, we use handlers, which provide a user-space interface.
The input subsystem includes most of the handlers you'll likely need: a keyboard handler to provide a console, a mouse handler for applications like the X Window System, a joystick handler for games and also a touchscreen handler. There is also a general-purpose handler called the event handler, which basically provides input events to user space. This means you almost never need to write a handler in the kernel, because you can do the same thing with the event handler and equivalent code in user space. This API discussion is covered in the second part of this article.
Google matched content |
Society
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
Quotes
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Bulletin:
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
History:
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
Classic books:
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|
|
You can use PayPal to to buy a cup of coffee for authors of this site |
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.
Last modified: March, 12, 2019
