does not poll ZIP drive for media changes

> 5) once mounted, it doesn't pop-up a nautilus window to show the content
> 7) when you right-clik on the ZIP disk icon and select "Eject", it will unmount
> the disk properly, but it will not eject the disk.

Addendum : After many mount/unmout experiments, Nautilus managed to pop-up a
window ONCE, and it also managed to actually eject the disk ONCE.
So it can do it then, but only very very very rarely, and in a random fashion.
So there is still a problem...

(In reply to comment #0)
> I epxerienced many issues with ZIP drives in Warty, and the Array 6 shows that
> not much has improved, so I thought I would list the problems, if anyone of them
> can be fixed before final release, then great, and hopefully it will all be
> sorted for Hoary+1
>
> Okay here goes. This applies to my external 100MB drive on parallel port, but I
> experienced similar issues when I using an internal IDE 100MB drive.
>
> 1) 'ppa' module not loaded

This driver is only used for parallel port devices, so I don't expect that you
had this problem with your IDE model.
I don't think that parallel-attached devices can be reliably autodetected, so I
don't think this will go away (though parallel port hardware will).

> 2) 'sda4' device not created

This seems to overlap/conflict with 4)

> 3) Entry in fstab not created

This is not a bug; entries are not created in fstab dynamically. Mounting is
accomplished using pmount.

> Once this is done by hand, then the following problems appear during use :
>
> 4) if there is no disc in the drive when the machine is booting, then it won't
> mount discs, it will complain that the sda4 device doens't exist, eventhough it
> is there. You have to unload then reload the 'ppa' module, to fix it ("modprobe
> -r ppa" then "modprobe ppa")

Apparently the partition table is not being re-read when the disc is changed;
this may or may not be fixable depending on the capabilities of the device.

> 5) When you insert a disc, it doesn't get mounted automatically, and once
> mounted, it doesn't pop-up a nautilus window to show the content, like it does
> for CDs, despite the settings in "System->Preferences->Removeable Drives and
Media".

Later, you say that this happens sometimes, but not reliably. Check
~/.xsession-errors in all cases.

> 6) Once mounted, the text under the ZIP icon says "zip0" (reference to the mount
> point I guess), instead of displaying the volume name, like for data CDs. If the
> ZIP has no label it could just display something like "Zip Drive 1:
> Unidentified" or "Zip Drive 1: No Name", or something like that, anything but
> "zip0"...

A cosmetic issue at best; let's consider the larger problems first.

> 7) when you right-clik on the ZIP disk icon and select "Eject", it will unmount
> the disk properly, but it will not eject the disk. You have to either press the
> button on the drive, or type "eject /dev/sda4" in a terminal. When doing the
> same on a CD, the CD does eject fine, not just unmount.

So eject from the command line works reliably, but ejecting from the desktop
does not?

Created an attachment (id=1523)
.xsession-errors

> > 1) 'ppa' module not loaded
>
> This driver is only used for parallel port devices, so I don't expect that you
> had this problem with your IDE model.

Well yes, of course, the module for the IDE one was ide-floppy IIRC (fro memory)
and it didn't get loaded either.

> I don't think that parallel-attached devices can be reliably autodetected, so I
> don't think this will go away

Ah, I understand. So that's why my printer was detected properly, but not
installed, in case the detection got it wrong ?
Ah well, that's okay then. As long as the parallel device do work properly, I
guess a little bit of manual tweaking is acceptable.

> > 2) 'sda4' device not created
>> This seems to overlap/conflict with 4)

Hmmm yes, maybe ;-P

> Later, you say that this happens sometimes, but not reliably. Check
> ~/.xsession-errors in all cases.

I uploaded the file.There are loads of errors in there, not sure what to look
for. Only thing that caught my eye were errors like :

** ERROR **: file gam_tree.c: line 146 (gam_tree_remove): assertion failed:
(g_node_n_children(node->node) == 0)
aborting...
end from FAM server connection
failed to read() from server connection
end from FAM server connection
end from FAM server connection
end from FAM server connection
end from FAM server connection
failed to read() from server connection
end from FAM server connection

But I am not sure if it had anything to do with my parallel ZIP drive problems ???

> So eject from the command line works reliably, but ejecting from the desktop
does not?

Yes.

Can this bug be confirmed against latest breezy or Colony 5?

(In reply to comment #5)
> Can this bug be confirmed against latest breezy or Colony 5?

Okay, I dug out my zip drives. Result : a complete disaster !!! I thought it was
bad enough in Wart/Hoary, but with (up to date of course) Breezy, it looks like
alph software, like ZIP drives were a revolutionary device that hit the market
on ly 3 days ago, and for which the Linux community was nt prepared.
It is truly appaling. I fought with both drives (100MB parport external, and
100MB ATAPI internal) for an hour, taking notes, then as everything was going so
wrong, I stopped taking notes as it became useless. I hope Dapper Drake will
rectifiy the situation, I am willing to help/test of course, just drop me a mail
when something needs testing/evaluating.

Here are some notes from my testing...

External 100MB Parallel Port Drive
-----------------------------
(Booted with no disk in drive.)
Drive not recognized.
Loading the 'ppa' module by hand (and putting it in etc/modules at the same
time) creates the /dev/sda device corresponding to the drive, but no drive icon
will show up in the 'computer' place.
I insert a disk: /dev/sda4 not created. I run "cfdisk /dev/sda", and it can see
the partition. Exit cfdisk.. oh miracle, /dev/sda4 is now visible at the CLI.
The disk was no auto-mounted. Typing by hand the CLI : "pmount /dev/sda4
Zip_External does create an icon, and I can browse the partition with Nautilus.
However, the icon represents a standard/generic disk drive icon, not the
usual/required/expecte, and very good looking ZIP disk icon.
When right-clicking on the icon, there is an option to unmount, but no option to
eject. Unmount works, however ejecting (using 'eject /dev/sda' at the CLI) does
not work, though no error is reported.

Internal ATAPI 100MB drive
--------------------------
Booted with no disk in the drive.

There is an icon for the drive, in the 'Computer place', but it won't the disk
when inserted.
I loaded the module 'ide-floppy', but still won't mount the disk.
If I create a mount point manually, and mount if at the CLI, it does mount the
partition/disk, and I can access it at the CLI, but if I try to double-click on
the drive icon, it says : "Error: special device /dev/hdd4 does not exist".
Reboot the machine with the disk in the drive.
I can now double click on the icon and it will mount the disk and I can browse
it with Nautilus. However, mounting the disk, and reading/accessing it, is
rather slower than it used to be in Hoary/Warty, for no apparent reason.
If I right-click on the icon, I have an option to 'Eject', which unmounts the
disk, but will not actually eject it. Using 'eject' at CLI doesn't work either,
nor does pressing the eject button on the drive itself !

At this point I could feel I was starting to go slightly mad, so I decided to
put a stop to it before I go get a sledge hammer ;-) :-/

Ok, so the drive actually works, correct? The thing here is that from my point
of view (the kernel maintainer) I just have to assure that it works. Making
things look better from the GUI isn't a bug the kernel maintainer handles.

Honestly, when I read your report, I was expecting terrible terrible things, but
I think you are over dramatizing the problems. Sure, it doesn't look good from
the UI, and that's a user issue we don't wont, but it wasn't horrible and maddening.

There's several issues I can outline from your report:

1) ppa does not get autoloaded. This is likely because paraport is such a dated
interface, and it doesn't lend itself easily to autodetection. This will
probably not get fixed.

2) I think ide-floppy was actually loaded, you said you did load it (guessing
modprobe) and it didn't change anything, plus the drive would not have shown
under "Computer" unless it was already loaded. So that's a non-issue. Modprobe
would exit with no messages if the module was already loaded.

3) Partitions not getting automounted. My guess here is that the driver or the
drive is not getting or handling signals for media change. This is much like a
CD drive. I'm guessing this should work, and maybe the driver handles it, but
since zipdrives are so old, and not many people use them anymore, there's not
been much maint on the driver itself. I'll look into this.

4) Eject. This surely is a bug, and one which I'll look into.

This bug has been flagged because it is old and possibly inactive. It may or may
not be fixed in the latest release (Breezy Badger 5.10). It is being marked as
"NEEDSINFO". In two weeks time, if the bug is not updated back to "NEW" and
validated against Breezy, it will be closed.

This is needed in order to help manage the current bug list for the kernel. We
would like to fix all bugs, but need users to test and help with debugging.

If this change was in error for this bug, please respond and make the
appropriate change (or email <email address hidden> if you cannot make the
change).

Thanks for your help.

(In reply to comment #8)
> This bug has been flagged because it is old and possibly inactive.

That is also sadly my feeling !! :o(

> It may or may not be fixed in the latest release (Breezy Badger 5.10).

Definitely not fixed...

> It is being marked as "NEEDSINFO".

"needinfo" ?! Hell, I though I gave quite a few details no ?!
If you need more info just ask, I will delighted to help smooth things out, as
the current support for ZIP drives is appalingly rough to say the least, and has
badly deteriorated since Hoary, things are going backwards...

> In two weeks time, if the bug is not updated back to "NEW" and
> validated against Breezy, it will be closed.

Okay, I will mark it as new :o)

> This is needed in order to help manage the current bug list for the kernel. We
> would like to fix all bugs, but need users to test and help with debugging.
> If this change was in error for this bug, please respond and make the
> appropriate change (or email <email address hidden> if you cannot make the
> change).

Well, if I understand you well, the kernel is not at fault here, since it is not
impossible to read and write to my ZIP drives ? Still, there many other, higher
level problems, so please don't close my bug ! ;-)

If possible, please upgrade to Dapper's 2.6.15-7 kernel. If you do not want to
upgrade to Dapper, then you can also wait for the Dapper Flight 2 CD's, which
are due out within the next few days.

Let me know if this bug still exists with this kernel.

(In reply to comment #10)
> If possible, please upgrade to Dapper's 2.6.15-7 kernel. If you do not want to
> upgrade to Dapper, then you can also wait for the Dapper Flight 2 CD's, which
> are due out within the next few days.
>
> Let me know if this bug still exists with this kernel.

Hello,

No problem with running Dapper, I run it alongside Breezy, on a dedicated
hard-drive, so I can carry out the wildest possible tests with total peace of
mind ;-)
I have just updated Dapper 2 minutes ago actually, which included this new
2.6.15-7 kernel.
But since things are so broken and all over the place wrt ZIP drives, is there
any aspect in particular that I should look out for ? Or have things improved a
lot and it's worth spending hours again to do very comprehensive testing ??

Okay I did some basic testing. I am writing this from Dapper while testing my
drives. Here is what I found so far, with regard to my internal, IDE drive. I
will run tests on my parallel external drive later if you deem it useful.

Conditions of test: a ZIP disk is present and inserted in the drive, while the
computer is being booted. In the past that proved to help things...

Good things:
------------
- Drive detected at boot ("ide_floppy" module loaded automatically)
- Nice ZIP icon, with proper label, in Nautilus
- Double click on the icon shows contents of disk
- Able to copy files from ZIP to computer and vice versa
- While copying from ZIP to computer, a dialog with progress bar shows up

Bad things:
-----------
- Very slow to respond: takes 20 secones to mount the disk, and 15 seconds to
read/show its contents in a Nautilus window.
- When right-clicking on the icon and selecting "Eject" (there is no unmount
option, only eject), it won't eject the disk (pressing the button on the drive
won't work either sadly), and gives an error dialog: "Unable to eject media:
eject: unable to eject, last error: Invalid argument".
If I try to eject it by hand at the command line (eject /dev/hdd), it returns
this error: "not an sg device, or old sg driver".
I am using the internal IDE drive here, so it's weird that it's talking about
scsi devices, probably why Nautilus throws an error when asked to eject the disk ?!

So the situation has improved quite a lot compared to Breezy, maybe we can get
it 100% right in time for Dapper, who knows ! ;-)

I will now give my external parallel port a go, hopefully it too will work
better... :-)

Some more testing:

I added a line to /etc/fstab to mount the internal drive to /mnt/ZIP Drive -
External.
This does add an icon in Nautilus, but it doesn't work, and the original icon is
still there (which still does work), so I have now two icons for the same drive !

Now, about the external drive on the parallel port. I added the "ppa" module to
/etc/modules, since I can possibly/reasonably expect the system to autodetect
the drive on the parport.
It basically works, and unlike the internal drive, does not takes ages to mount
a disk. However, it's horribly slow at copying files. It took 2 minutes to copy
a 3MB files, whereas normally this drive achives about 500KB per second.
The drive icons is not correct. it's a general purpose/generic drive icon. It
does change properly when mouting and unmounting the disk, though.

The pop-up menus are inconsistent too, they don't offer the same options for the
IDE and parport drives.

state \ drive type | IDE | parport
---------------------------------------------
unmounted | mount, eject | mount
---------------------------------------------
mounted | eject | unmount
---------------------------------------------

I think I will stop testing now. When all these problems are fixed, I will test
again and file new, more specific, bug reports if some problem remains.

Ok, as far as the kernel is concerned, I'm going to say this bug is done.
However, some things are still unresolved. I'm pushing this to gnome, and see
where it goes from there.

Not sure I can do anything about the speed issues. The eject problem is likely
because the ide interface doesn't lend itself well to plug/unplug and change of
media (except in cases of cdrom's, but this device is seen as a harddrive).

Because zip is such an old technology, I also don't expect much help on this
from upstream, if there even is one anymore.

> Because zip is such an old technology, I also don't expect much help on this
> from upstream, if there even is one anymore.

Hmmmm... well, to me one of the strength of Linux is its ability to run old
hardware ;-) Also, I got the impression that Ubuntu specifically made a point to
be friendly with old hardware, so it can run on obsolete donated computers for
people in need in rich countries, or everybody in Africa, or just people (like
me...) who just don't like to bin hardware that still works ! ;-) More
specifically, I got the impression that the main reason we have an ugly
graphical boot (usplash), is because Ubuntu wanted it to work on as much old
video cards as possible. Well, I have a 10 year old video card (2D PCI Matrox
Millenium), and even this old dog is capable of displaying much better graphics
than what usplash decided on. So looks like the aim is to support at least 10
year old hardware... ;-) Also, 1.44MB 3.5" floppy disk drive are muuuch older
than ZIP drives, yet it looks to me like they are much better supported than ZIP
drive... hum hum... ;-)
And, last but not least ;-) .... Zip drives are hardly obsolete, they are still
very much current and still manufactured ! Much to my surprise I must admit ;-)
I just had a look at their web site, and they have a full range of ZIP drives.
They have increased capacities of the disk (750MB), improved transfer speeds
(7.5MB/s) which makes them viable alternatives to rewritable CDs. There is still
an internal model with IDE/ATAPI interface. For external units, you have USB2
and Firewire interfaces, which do replace the old SCSI and parallel port interfaces.
So, why should we not support the people who buy these products, especially
considering that it's already implemented and just needs polishing/fixing, and I
am there to help you test that ;-) And, the life expectancy of these products
is I much longer (10 years so far...) than all these short lived super cheap USB
scanners and inkjet printers, that come and go on a monthly basis, but
noentheless get attention from the community/driver developers. So I think you
really are unfair with these poor ZIP drives, please don't let them down ! ;-)
Jeez, why did I study electronics engineering, I should have been a lawyer
instead, specialising in defending poor old hardware ;-)

What is really strange is that I just got finished installing Ubuntu on an older k6 233Mhz system I had lying around here. Everything in the unit is SCSI based (HD, both CDs, and ZIP). I started with the 4.10 release and everything worked fine. CDs were automounted, displayed on the desktop, and ejected smoothly. The same was true of ZIP disks. I say was, because after finishing the upgrade to 5.10 this is no longer the case. Now, ZIP disks are automatically mounted on insert and a Nautilus window started. However, there is no icon on the desktop for them , nor is there one in the Computer view of Nautilus. Thus the only way to eject the disk is to run eject via sudo against the device or mount point.

That's interesting. So it kinda 99.99% works with SCSI then. And the other day a friend visited me with a USB 250MB model, and it worked perfectly, sweet as chocolate.

So ZIP drive support is not "that" broken then, rather, it's broken only for 2 interfaces out of 4. That's encouraging, means there is no conspiracy to drop support for ZIp drives in general.

SCSI : works 99%
USB: jsut works
parport: all over the place
IDE : idem.

I still have my computer opened, ready to plug my IDE ZIP drive to conduct tests when needed, and my parport drive is permantly connected.
So I am ready to test anything the devs can do to help fix these... :o)

That sounds very encouraging, thank you :)

So it seems that automounting etc. works just fine, and gnome-vfs doesn't just recognize the new drive. Seb, Daniel, any idea how to debug this in gnome-vfs?

Also, Vincent, can you test this with a current Dapper CD (live or install)?

Well yes, I have updated Dapper 2 minutes ago, I will conduct a series of tests again on my IDE and parport drives...

Okay, I did some basic tests. Nothing has improved at all since my last comments. Not with the internal ATAPI drive, nor with the external Parallel port drive. Nothing has changed (good or bad) at all.

Does this version happen to fix this at least partly? I should...

 hal (0.5.7-1ubuntu6) dapper; urgency=low
 .
   * Add debian/patches/02_ignored_volumes.patch:
     - Add a policy for which volumes are shown in gnome-vfs and which aren't.
       This replaces the gconf based policy in gnome-vfs2, which was ripped out
       two seconds before the final Gnome relase (*cough* freezes?).
     - Now ignore volumes on non-hottpluggable and non-removable volumes unless
       they are mounted under /mnt or /media, or are a mounted NTFS or VFAT
       partition. This should come close to what the majority of users will
       want to see.
     - Malone #34886 (might also fix at leastparts of #13554)
   * Add debian/patches/09_sony_brightness.patch:
     - Apply trivial upstream patch to fix LCD brightness setting on Sony
       laptops.
     - Patch taken from upstream CVS, thanks to Paolo Borelli.
     - Malone #31289

(Please reboot after upgrade to this version)

> Does this version happen to fix this at least partly? I should...

doesn't change much at all unfortunately.
With regard to my parport drive, when I put a disk in it, it is not auto-mounted.
Double-clicking on the icon gives an error/fails. If I use 'pmount' to mount it manually, it works, but then I get a normal/generic drive icon, not a nice ZIP disk icon like I have for example when using the ATAPI/internal ZIP drive.

Can you please do the debugging dance described on http://wiki.ubuntu.com/DebuggingRemovableDevices again on latest dapper? My assumption is that hal does not poll the drive for new media.

Can you also please do

for i in `pidof hald-addon-storage`; do sudo grep -z HAL_PROP_BLOCK_DEVICE /proc/$i/environ; echo; done

and copy the output here?

I loaded the 'ppa' module by hand, the kernel detected the parport drive properly, and created /dev/sda accordingly. So far so good. Then I proceeded with the test procedure described in that wiki page.

To make it short, it seems that you are right... the log files are empty (nothing is logged upon the insertion of the disk), and when I run hald in "debug"/verobse mode, when I insert the ZIP disk, it does not print a single message, not a word, not even a single character...

As for the command you asked me to type, here is the ouput:
HAL_PROP_BLOCK_DEVICE=/dev/hdd
HAL_PROP_BLOCK_DEVICE=/dev/hdd

Can you confirm that /dev/hdd (secondary slave IDE device) is actually your ZIP drive? You said that your system was SCSI otherwise.

So it seems that polling /dev/hdd is either not done properly, or it's just the wrong device. Hm, should that be /dev/hdd4 actually? There was some oddity with ZIP drives AFAIR.

> Can you confirm that /dev/hdd is actually your ZIP drive?

No, /dev/hdd is my DVD drive, /hda and /hdc are the hard drives, and nothing is connected to /hdb.

> You said that your system was SCSI otherwise.

Nope, as I said in my comment, my ZIP drive is external, connected to the parallel port.
I think you are mistaking me for "Jamin W. Collins", who did say that his system is indeed SCSI inside out (Hard rives, CD drives and ZIP drive).

> So it seems that polling /dev/hdd is either not done properly,
> or it's just the wrong device.
> Hm, should that be /dev/hdd4 actually?

The kernel maps the drive to /dev/sda, and the disk partition is mapped as /dev/sda4.
I don't understand why the command you asked me to type talks about /hdd, but I guess the real problem is that it does NOT talk about /dev/sda ??

Vincent,

ah, indeed, I mixed up the different reporters, sorry. So you are right, hal does not poll the ZIP drive for media changes. Can you please do

  lshal > hal.txt

and attach hal.txt here?

no comment

xxxxxxx

I attached the lshal output, no sign of the zip drive in there.
I did another "lshal" after inserting a zip disk in the drive, but the file was exactly the same (same size exactly).

I also added the messages that the kernel prints when I load the 'ppa' module to detect the drive. There is one line that says:

"Driver 'sd' needs updating - please use bus_type methods"

which maybe is interesting ?

So, to summarize:

 * hal knows nothing about the ZIP drive.
 * The system does not know about the ZIP drive after a clean boot.
 * The kernel recognizes the drive properly and you can manually mount it after 'modprobe ppa'

Is that correct? If so, does hal see the ZIP drive after

  sudo /etc/dbus-1/event.d/20hal restart

? If so, then the problem is somewhere in the hal/udev communication.

Also, can you please do a clean boot, then do

  sudo udevmonitor -e

then do 'sudo modprobe ppa' on another console, and copy&paste the udevmonitor output here? (Assuming that there is no /dev/* device for your ZIP drive before loading ppa).

Thank you!

Your bug lacks information we would need to investigate further. We
are now going to close the bug - please reopen if you have more
information at hand.

I think this bug shouldn't be closed, as then people, which has problems with ZIP drives on Ubuntu (look for example at bug #53251) can't find it can cant suplly needed info for you.

Martin asked in https://launchpad.net/distros/ubuntu/+source/hal/+bug/13554/comments/32 for info half a year ago. If nobody cares to answer, the bug should be closed, everybody who's subscribed to the bug will get a mail with the reminder now.