Monthly Archives: June 2009

RTL8185L

If you have a PCI wireless card based on the RTL8185L chipset, and are using Linux, bear this in mind: it works! You may have to fiddle around a bit, but in the end you’ll have reason of the beast. First, use the last kernel (the kernel of the day is 2.6.30): I have to say I’ve tried 2.6.27 and it seems not to work, so use a newer one. Then try and configure your Linux distribution as you see fit (I won’t go into details here as there are many different way to do this).

If it still doesn’t work, try

    # iwconfig wlan0 essid your_essid

… and then restart the scripts/programs that your distro uses to bring the wireless interface up. I know it might be stupid, but it made my A02-PCI-W54 (an Atlantis Land Net Fly PCI 54, with RTL8185L chipset) connect to the access-point. And to the Internet, of course.

Just to give you a clue, my dear reader, ndiswrapper on this card won’t work — I had no success.

Update

It seems the device is stuck with a signal quality below 20%, not sure why… Well, I guess it’s still better than nothing…

Update #2

There’s a bug filed on bugzilla.kernel.org about the issue above.

Advertisements

HAL + FAT32/NTFS + USB = automount problems

Warning: some of the following command-line programs should be run as root and, if wrongly used, can cause harm to the system, loss of data, scaly skin and inchoate baldness. Thus, before doing something foolish (or blaming me) read all the necessary documentation and then proceed.

If you use HAL and one of your external hard drive is not automatically mounted, but you can mount it from command line, maybe your problem is similar to mine.

Let’s check: plug your external hard drive and see what dmesg says:

    $ dmesg
    [...]
    usb 1-8: new high speed USB device using ehci_hcd and address 4
    usb 1-8: configuration #1 chosen from 1 choice
    scsi3 : SCSI emulation for USB Mass Storage devices
    usb-storage: device found at 4
    usb-storage: waiting for device to settle before scanning
    usb 1-8: New USB device found, idVendor=XXXX, idProduct=XXXX
    usb 1-8: New USB device strings: Mfr=XX, Product=XX, SerialNumber=X
    usb 1-8: Product: XXXXXXXXXXXXXXXXXX
    usb 1-8: Manufacturer: XXXXXX
    usb 1-8: SerialNumber: XXXXXXXXXXXX
    scsi 3:0:0:0: XXXXXXXXXXXXXX
    sd 3:0:0:0: [sdb] XXXXXXXX 512-byte hardware sectors (XXXXXX MB)
    sd 3:0:0:0: [sdb] Write Protect is off
    sd 3:0:0:0: [sdb] Mode Sense: XX XX XX XX
    sd 3:0:0:0: [sdb] Assuming drive cache: write through
    sd 3:0:0:0: [sdb] XXXXXXXX 512-byte hardware sectors (XXXXXX MB)
    sd 3:0:0:0: [sdb] Write Protect is off
    sd 3:0:0:0: [sdb] Mode Sense: XX XX XX XX
    sd 3:0:0:0: [sdb] Assuming drive cache: write through
    sdb: sdb1
    sd 3:0:0:0: [sdb] Attached SCSI disk
    sd 3:0:0:0: Attached scsi generic sg1 type 0
    usb-storage: device scan complete

If you see something like the above (obviously you’ll see something else instead of the X) it means that your hardware has been detected. Good.

Now let’s see if the proper messages reach HAL. Unmount and unplug the device, run lshal -m and then plug it back in:

    $ lshal -m
    Start monitoring devicelist:
    -------------------------------------------------
    15:32:54.354: usb_device_XXXXXXXXXX added
    [...]
    15:33:00.244: storage_serial_XXXXXXXXXXX added
    15:33:00.276: volume_part1_size_XXXXXXXXXXXXX added
    15:38:35.406: usb_device_XXXXXXXXXXX removed
    15:38:35.410: volume_part1_size_XXXXXXXXXXXXX removed
    15:38:35.416: storage_serial_XXXXXXXXXXX removed
    15:38:35.419: usb_device_XXXXXXXXXXX removed
    [...]

Here we see that HAL knows whether/when our hard drive is plugged, but our desktop didn’t say (or do) a thing: no popups, no icons, no warnings, no error messages nowhere, not even in the system logs.

From dmesg we know that the hard drive is given the device /dev/sdb, with one partition, /dev/sdb1. Let’s try and mount it:

    $ mount /dev/sdb1

Or, if the device is not listed in /etc/fstab do (as root):


    # mkdir /tmp/disk
    # mount -t vfat /dev/sdb1 /tmp/disk

If you succeeded: very good, your system mostly works, there should only be a minor problem somewhere.

Let’s check if there are symbolic links to /dev/sdb1 under /dev/disk/*:

    $ ls -l /dev/disk/* | grep sdb1

In my system there were links under /dev/disk/by-id and /dev/disk/by-path. The link under /dev/disk/by-uuid was missing.

Thinking about it, even the output of lshal had something wrong: the “udi” containing the string block.device = '/dev/sdb1' had others void variables; for example: volume.{fstype,label,partition.uuid,uuid}.

I should say that I tried with other external drives, and had no problems. I thought there was something wrong in the filesystem: but mount worked and gave no error. So I checked with dosfsck, and found something: I repaired the errors it found, but there still was something wrong, since automount didn’t work. So I tried parted: it found an error and refused to continue. At last, I ran testdisk: choose the device, choose the Intel partition table, choose analyse. It certified at once: “invalid FAT boot sector”. Good (?) let’s repair it: choose “MBR Code”. It told me both boot sectors were at fault. Let’s rebuild them right away! All done, I could quit from testdisk.

I unplugged my hard drive and plugged it back in: the infamous windows appeared asking me what to do. Problem solved. Uhmmm. Well, it was fun.

/etc/fstab and HAL

If you find somebody claiming that if a device is listed in /etc/fstab, then automount won’t work anymore on that device, disregard him. You can do it, and it can be useful: now you can mount/unmount devices from the command line as a normal user, and they get mounted where you told them to; and you won’t have problems with accented letters (it can happen if you don’t have an utf8 locale and use HAL with a clean fstab to mount a fat32/ntfs filesystem).

You can use this line as an example:

    /dev/disk/by-uuid/XXXXXXXX /mnt/XXXXXX vfat noauto,users,umask=000 0 0

(Remember, you have to mkdir /mnt/XXXXXX as root).

NTFS

Most of the above observations should be valid and useful for NTFS too, but I didn’t test.

NTFS-3G: Permission denied

If you get this message while trying to mount an NTFS filesystem with ntfs-3g:

    Error opening '/dev/sdb1': Permission denied
    Failed to mount '/dev/sdb1': Permission denied
    Please check '/dev/sdb1' and the ntfs-3g binary permissions,
    and the mounting user ID. More explanation is provided at
    http://ntfs-3g.org/support.html#unprivileged

Then you should begin following the suggestions in: http://ntfs-3g.org/support.html#unprivileged

Let’s have an ntfs-3g ‘setuid root’:

    # chmod 4755 /bin/ntfs-3g

Now plug your external hard drive back in. If you still have permissions’ problems, you have to check the device filesystem.

Below you can see permissions of an external hard drive with an NTFS filesystem (/dev/sdb*) and those of an usb pendrive with a FAT32 filesystem (/dev/sdc*). My user belongs to the “plugdev” group, and can thus mount the pendrive with no problems. The external hard drive mounted fine when it was a FAT32 filesystem; maybe udev used a different rule and gave it the ‘plugdev’ group?

    brw-rw---- 1 root disk 8, 16 2009-05-16 14:06 /dev/sdb
    brw-rw---- 1 root disk 8, 17 2009-05-16 14:06 /dev/sdb1
    brw-rw---- 1 root plugdev 8, 32 2009-05-16 14:08 /dev/sdc
    brw-rw---- 1 root plugdev 8, 33 2009-05-16 14:08 /dev/sdc1

Let’s change udev rules to do our selfish needs (we want to have /dev/sdb* in the plugdev group). With the help of the guide at:

We search in sysfs:

    # find /sys -name sdb

… here we have /sys/block/sdb. That’s the parameter to feed to the _obvious_ command

    # udevadm info --path=/sys/class/block/sdb --attribute-walk|less

Now we can search the device whose group we want to change, and will build rules such as:

    ATTRS{vendor}=="VENDOR" ATTRS{model}=="MODEL" GROUP="plugdev"

… and we will put this rule in a file under /etc/udev/rules.d/. For example, in /etc/udev/rules.d/90-local.rules. Note that the _last_ rules override the previous ones: that’s why this file begins with “90”.

With a kernel supporting inotify you won’t have to restart udev, so you can repeat the usual “unplug-plug back” mantra.

If you still have problems with permissions, check /etc/fstab: if you have a rule about this device, you have to make a proper directory where the drive will be mounted and change its permissions.