Second volume in a Lifedrive not mounted automatically

[José M. López-Cepero]

I have a PalmOne LifeDrive PDA. It has a 4GB hard drive and a SD card slot. It also has an application which allows it to appear just like a USB drive to the operating system when connected via USB. The application provides two different mass storage drives: one is the 4GB hard drive and the second is the SD card reader slot. (Edited - forgot to finish the paragraph the first time, stupid me...)

Up to Dapper, plugging the PDA and enabling drive mode correctly mounted and showed the two drives. However, now in Feisty the 4GB volume is no longer mounted. This is independent of whether there is a SD card in the PDA card reader or not. If there is, it's correctly detected and mounted.

I can mount the drive just fine manually, but that kind of defeats the purpose of having automounting :)

I was inclined to assign the error to hal, but the hardware browser and lshal do show the missing drive. From hal's point of view, the LifeDrive has an internal "SCSI Host Adapter" with two "SCSI Devices", one as "file storage" (the 4GB drive) and a "SDC" (the SD card).

dmesg section when plugging the PDA:

-----------

[ 166.195639] usb 5-6.6: new high speed USB device using ehci_hcd and address 11
[ 166.288417] usb 5-6.6: configuration #1 chosen from 1 choice
[ 166.288769] scsi6 : SCSI emulation for USB Mass Storage devices
[ 166.288833] usb-storage: device found at 11
[ 166.288836] usb-storage: waiting for device to settle before scanning
[ 171.289969] scsi 6:0:0:0: Direct-Access palmOne, File storage 1.0 PQ: 0 ANSI: 0
[ 171.292073] SCSI device sdg: 7818112 512-byte hdwr sectors (4003 MB)
[ 171.293985] sdg: Write Protect is off
[ 171.293991] sdg: Mode Sense: 0f 00 00 00
[ 171.293994] sdg: assuming drive cache: write through
[ 171.295945] SCSI device sdg: 7818112 512-byte hdwr sectors (4003 MB)
[ 171.296923] sdg: Write Protect is off
[ 171.296927] sdg: Mode Sense: 0f 00 00 00
[ 171.296930] sdg: assuming drive cache: write through
[ 171.296935] sdg: sdg1
[ 171.582358] sd 6:0:0:0: Attached scsi removable disk sdg
[ 171.582415] sd 6:0:0:0: Attached scsi generic sg8 type 0
[ 171.583371] scsi 6:0:0:1: Direct-Access Unknown SDC 1.0 PQ: 0 ANSI: 0
[ 171.585156] SCSI device sdh: 1999872 512-byte hdwr sectors (1024 MB)
[ 171.585930] sdh: Write Protect is on
[ 171.585934] sdh: Mode Sense: 0f 00 80 00
[ 171.585936] sdh: assuming drive cache: write through
[ 171.588180] SCSI device sdh: 1999872 512-byte hdwr sectors (1024 MB)
[ 171.588927] sdh: Write Protect is on
[ 171.588930] sdh: Mode Sense: 0f 00 80 00
[ 171.588932] sdh: assuming drive cache: write through
[ 171.588937] sdh: sdh1
[ 171.592219] sd 6:0:0:1: Attached scsi removable disk sdh
[ 171.592278] sd 6:0:0:1: Attached scsi generic sg9 type 0
[ 171.593629] usb-storage: device scan complete

-----------

Thanks for any help!

[Cristian Aravena Romero (caravena)]

Thanks for taking the time to report this bug. Unfortunately we can't fix it, because your description didn't include enough information.

Please include the information requested from https://wiki.ubuntu.com/DebuggingRemovableDevices as separate attachments.

[José M. López-Cepero (cepe)]

Thanks for the comment, Cristian. I attach all the files as directed (I followed the Dapper instructions). I have cut the dmesg file to only include the messages produced from the moment the device was plugged in.

Be warned that the device is not exactly a USB key in its behavior. When it is first plugged in, it gets recognized as a Palm PDA (that's what the "Handspring Visor" messages are for). Then, you run an utility on the device and it starts to behave like a USB drive, so the kernel "sees" a disconnect from the Visor and a connect from the USB drives. The device used to work perfectly that way under Edgy and, just to try, I have done it the other way around (first enable "USB key mode", then plug it in) and the behavior is identical.

The result is always the same: the drives get recognized (as in, the scsi /dev/ entries are created and I can manually mount/unmount/use them) but only the SD card (first of the created drives) gets mounted (if a card is present, that is; in fact, the "photos found" dialog box pops up in that case). The "palmOne file storage" device does not get mounted automatically (no matter whether there is a SD card in the slot or not) but, as I just mentioned, I can access it just fine by mounting it manually.

Output of id: uid=1000(cepe) gid=1000(cepe) grupos=4(adm),20(dialout),24(cdrom),25(floppy),29(audio),44(video),103(plugdev),107(lpadmin),108(scanner),1000(cepe)

Output of id hal: complains that the user hal does not exist

Output of id haldaemon: uid=118(haldaemon) gid=118(haldaemon) grupos=118(haldaemon),24(cdrom),25(floppy),103(plugdev),122(powerdev)

Output of uname -a: Linux ubuntu 2.6.20-8-generic #2 SMP Tue Feb 13 05:18:42 UTC 2007 i686 GNU/Linux

I hope that sheds some light on the problem. Thanks for your help and don't hesitate to ask for any further information you might need.

Best regards.

[Ben Collins (ben-collins)]

Well, the kernel correctly sees the driver, and initializes it. If manual mounting works, then the kernel has done everything it can. I can't make hal DTRT :)

[Martin Pitt (pitti)]

Thanks for the logs so far. The problem is that hal does not detect any file system on the PDA hard drive (/dev/sdb1):

  volume.label = '' (string)
  volume.uuid = '' (string)
  volume.fsversion = '' (string)
  volume.fsusage = '' (string)
  volume.fstype = '' (string)
  storage.model = '' (string)

However, to find out why I need a hal debug log, as described on the second half of https://wiki.ubuntu.com/DebuggingRemovableDevices. Can you please do that and attach the log? Thank you!

[José M. López-Cepero (cepe)]

Hi Martin,

Sorry for the delay. I have just begun a short research stay abroad and it's always a little difficult to completely settle down fast. :)

I have confirmed the problem in a different computer (also with feisty, up to the last updates). I have generated a hal.log file by following the Dapper instructions in the wiki page you posted. The device is plugged in at timestamp 22:59:06.551. Confusingly enough, hal does seem to find the partition. The only eye-catching difference I can spot between the processes followed for the HD and the SD card reader is that after the "Doing addon-storage for /dev/sdX" message, only the second time around does osspec.c report having added the device name:

[29032]: 22:59:12.541 [D] addon-storage.c:312: **************************************************
[29032]: 22:59:12.541 [D] addon-storage.c:313: Doing addon-storage for /dev/sdd (bus usb) (drive_type disk) (udi /org/freedesktop/Hal/devices/storage_serial_Unknown_SDC_PVG0M635V2EV)
[29032]: 22:59:12.541 [D] addon-storage.c:314: **************************************************
22:59:12.568 [I] osspec.c:226: SEQNUM=3028, ACTION=add, SUBSYSTEM=block, EVPATH
=/sys/block/sdd/sdd1, DEVNAME=/dev/sdd1, IFINDEX=0

The previous "doing addon-storage" for /dev/sdc (the 4Gb HD) does not have a similar osspec.c line.

I hope this helps. Thanks for your attention!

[Matt Yun (matt-yun)]

I can confirm this bug.

My Palm Lifedrive also automounted in Dapper, but no longer does this in Feisty-beta. The SD card, however, does mount automatically.

I can still mount the Lifedrive manually as /dev/sdb1. My system lists it under /sys/block/sdb.

While Googling this subject, I came across a duplicate bug: https://launchpad.net/ubuntu/+source/hal/+bug/89723

[José M. López-Cepero (cepe)]

Sadly, this bug does not seem to have made it on time for the final release of Feisty, which makes it a regression as compared to Edgy (and Dapper). Too bad.

I have marked #89723 (where some similar information is posted) as a duplicate as reported by Matt. Both bugs are now marked as "needs info". Since more information has been reported in both cases, it would be nice to have a developer quickly review it and state whether more information is still needed or, if not, update the status to something more appropriate.

Some word from the developers on the matter would be welcome. Of course, I (and I suppose everybody) understand that the reason this bug has not been dealt with yet is probably just lack of time, so I don't want to sound like I'm rushing anybody. Just asking nicely.

Best regards.

[bapoumba (bapoumba)]

Not sure how the "duplicate bug" works. I commented and gave infos in #89723. Chiming in to point out that the situation is the same in gutsy. Sorry if just one comment in one of the bugs was enough to have everyone informed :)

[Bruce Cowan (bruce89-deactivatedaccount)]

Quoting bapoumba <email address hidden>:

> Not sure how the "duplicate bug" works. I commented and gave infos in
> #89723. Chiming in to point out that the situation is the same in gutsy.
> Sorry if just one comment in one of the bugs was enough to have everyone
> informed :)

You should post your commments on the parent bug, in this case, Bug #81219. Duplicates should be ignored after they
are marked as a duplicate, use the non-duplicated bug for further details.

Sorry if none of that made sense, it's quite late here.
>
> --
> [Feisty] Second volume in a USB drive not mounted
> https://bugs.launchpad.net/bugs/81219
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

--

[bapoumba (bapoumba)]

This applies to gutsy too.

Tried this: http://ubuntuforums.org/showpost.php?p=3317634&postcount=10

It works once, and only once. I have done this, several times in a row now.

Step to reproduce:

1- blkid (relevant part part only)
/dev/sdd1: LABEL="LIFEDRIVE" UUID="1234-5678" TYPE="vfat"

If /dev/sdd1 properly added to /etc/fstab:
/dev/sdd1 /mnt/LIFEDRIVE vfat user,noauto 0 0
the vfat partition on the Lifedrive mounts.

2- Disable drive mode on the Lifedrive

3- Enable drive mode again:
blkid
/dev/sde1: LABEL="LIFEDRIVE" UUID="1234-5678" TYPE="vfat"

The /dev/sd*1 has changed. And so on (first time I tested, blkid returned /dev/sda1)
I cannot mount by UUID either.

[Launchpad Janitor (janitor)]

[Expired for hal (Ubuntu) because there has been no activity for 60 days.]

[bapoumba (bapoumba)]

[Expired for hal (Ubuntu) because there has been no activity for 60 days.]
Please see post above yours. What does activity means? Thanks.

[Tigge (admin-tigge)]

If more info is needed I too have this problem and would gladly submit additional info to help solve this. What is the status? What can be done to fix hal?

[aka.bugle (aka.bugle)]

Well, I've had the same issues w/ gentoo and I have found a solution...
see http://forums.gentoo.org/viewtopic-p-4773200.html#4773200

~aka.bugle

[Javier S. Pedro (javispedro+lpad)]

I have a Palm T|X and this same error -- no sensible filesystem -- happens too when using Hardy (and recent Debian Lenny) and the Palm OS application called "Drive Mode".

Actually, the problem is the FAT filesystem on the card itself. Formatting a card using the PalmOS "Card Info" application, then trying to insert the card in a 5$ card reader results in the no sensible filesystem error too.

However, this didn't happen in previous Ubuntu releases. It seems that G-V-M is now more picky "sensing" FAT filesystems than previous versions. The filesystem does mount fine using standard linux vfat kernel driver, mtools, dosfsck and of course windows.

[iMil (imil)]

Since the problem still exists in Hardy and no real fix has been proposed, note that installing the ivman package did the trick. sudo apt-get install ivman, enabled drivemode, and tadaa, the 4Gb LifeDrive appeared on my desktop.

Hope this helps

[ezekiel000 (ezekiel000)]

Installing ivman does fix the 4Gb internal drive mounting but then you can't unmount it it comes up with this error:

Cannot unmount volume

Error org.freedesktop.DBus.Error.UnknownMethod.

Details:
Method "Unmount" with signature "as" on interface "org.freedesktop.Hal.Device.Volume" doesn't exist

[ezekiel000 (ezekiel000)]

There are enough reports including mine that this is a constant bug.

[ezekiel000 (ezekiel000)]

I found you can unmount it using sudo umount in a terminal but this shouldn't be needed.
Obviously the problem is that the vfat file system that PalmOS produces when you format a card is slightly different than the standard vfat and is not recognised any more.

[Matt Behrens (zigg)]

Here's an image of a zero-ed then on-device-reformatted LifeDrive data partition. Probably the most narrowed-down test case that can be made. :)

It doesn't automount, of course, but it can be mounted with sudo mount -t vfat -o loop `pwd`/sdb1.img /mnt

Hopefully someone who doesn't have a LifeDrive can use it to fix the appropriate recognition code.

[ezekiel000 (ezekiel000)]

The fix using ivman doesn't work on Ubuntu 8.10.

[Matt Behrens (zigg)]

I explained the problem to the hal list, since it doesn't look like this problem has ever surfaced there.

http://lists.freedesktop.org/archives/hal/2008-November/012598.html

[Matt Behrens (zigg)]

On Matthew Garrett's advice I've forwarded the problem to the udev guys now, since udev is apparently responsible for fs probing.

[Scott James Remnant (Canonical) (canonical-scott)]

Nope, HAL does that itself

[Matt Behrens (zigg)]

Are you sure about that, Scott? Matthew Garrett told me that libvolume_id, which is part of the udev source package, is used by hald to identify volumes.

Changes have since been made to udev and I have personally tested that the volid tool can identify the LifeDrive but I have not had the time to try to figure out what needs to be done to get hald on board.

[Matt Behrens (zigg)]

Are you sure about that, Scott? Matthew Garrett told me that libvolume_id, which is part of the udev source package, is used by hald to identify volumes.

Changes have since been made to udev and I have personally tested that the volid tool can identify the LifeDrive but I have not had the time to try to figure out what needs to be done as far as patching up Ubuntu packages to get hald on board.

[Matt Behrens (zigg)]

jaunty just auto-mounted my LifeDrive upon connection.

Can anyone else confirm this is fixed for jaunty?

[Matt Behrens (zigg)]

I've connected my LifeDrive to a competely new jaunty install now. This bug is definitely fixed for jaunty.

[ezekiel000 (ezekiel000)]

Not sure if this is the way to do it but it is fixed in Ubuntu 9.04.