Bug 175998 - Firewire iPod no longer mounts to desktop after upgrade to 2.6.14-1.1653_FC4
Firewire iPod no longer mounts to desktop after upgrade to 2.6.14-1.1653_FC4
Status: CLOSED DUPLICATE of bug 174723
Product: Fedora
Classification: Fedora
Component: hal (Show other bugs)
4
i686 Linux
medium Severity low
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-12-16 22:05 EST by David Goldberg
Modified: 2015-01-04 17:23 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-18 23:56:31 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
FreeDesktop.org 5158 None None None Never

  None (edit)
Description David Goldberg 2005-12-16 22:05:37 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7

Description of problem:
When running kernel-2.6.13-1.1532_FC4 and earlier, my Firewire iPod (2nd generation) is recognized and automatically mounts with files owned by my uid.  After upgrading to 2.6.14-1.1637_FC4 and all subsequent 2.6.14 versions, the device is recognized (e.g. I can manually mount it) but have to jump through the options hoops to get the ownership done right.  No other package appears to be the culprit because, keeping everything else the same (e.g. at most recent update version) I boot to kernel-2.6.13-1.1532_FC4 and it works as expected.

Version-Release number of selected component (if applicable):
kernel-2.6.14-1.1653_FC4

How reproducible:
Always

Steps to Reproduce:
1.Plug in iPod
2.Watch dmesg output
3.See device be recognized
4.Observe that it is not automatically mounted.
  

Actual Results:  Observe that device is not automatically mounted.

Expected Results:  Device should have been automatically mounted.

Additional info:

I see no difference in dmesg output when the device is plugged in between the kernel versions.  If there's another place I should look for data, please let me know.
Comment 1 Pete Zaitcev 2005-12-19 20:45:10 EST
This is what happens here.

- On plug-in, nothing happens.

- Doing su, modprobe sbp2:

Dec 19 17:41:56 lembas su(pam_unix)[23609]: session opened for user root by
(uid=531)
Dec 19 17:42:05 lembas kernel: SCSI subsystem initialized
Dec 19 17:42:05 lembas kernel: sbp2: $Rev: 1306 $ Ben Collins <bcollins@debian.org>
Dec 19 17:42:05 lembas kernel: ieee1394: sbp2: Driver forced to serialize I/O
(serialize_io=1)
Dec 19 17:42:05 lembas kernel: ieee1394: sbp2: Try serialize_io=0 for better
performance
Dec 19 17:42:05 lembas kernel: scsi0 : SCSI emulation for IEEE-1394 SBP-2 Devices
Dec 19 17:42:07 lembas kernel: ieee1394: sbp2: Logged into SBP-2 device
Dec 19 17:42:07 lembas kernel:   Vendor: Apple     Model: iPod              Rev:
1.51
Dec 19 17:42:07 lembas kernel:   Type:   Direct-Access-RBC                  ANSI
SCSI revision: 02
Dec 19 17:42:09 lembas su(pam_unix)[23609]: session closed for user root
Dec 19 17:42:11 lembas kernel: sda: Spinning up disk.....ready
Dec 19 17:42:11 lembas kernel: SCSI device sda: 19531260 512-byte hdwr sectors
(10000 MB)
Dec 19 17:42:11 lembas kernel: sda: test WP failed, assume Write Enabled
Dec 19 17:42:11 lembas kernel: sda: asking for cache data failed
Dec 19 17:42:11 lembas kernel: sda: assuming drive cache: write through
Dec 19 17:42:11 lembas kernel: SCSI device sda: 19531260 512-byte hdwr sectors
(10000 MB)
Dec 19 17:42:11 lembas kernel: sda: test WP failed, assume Write Enabled
Dec 19 17:42:11 lembas kernel: sda: asking for cache data failed
Dec 19 17:42:11 lembas kernel: sda: assuming drive cache: write through
Dec 19 17:42:11 lembas kernel:  sda: sda1 sda2
Dec 19 17:42:11 lembas kernel: sd 0:0:0:0: Attached scsi removable disk sda

Observe that udev worked (and block special files were created),
but HAL didn't. However, I have no idea how a kernel update could
have broken HAL. Maybe David knows (adding to cc:)
Comment 2 David Goldberg 2005-12-19 21:25:19 EST
Agree that udev works.  I can manually mount the ipod.  I'm not familiar with
HAL, but I do see that I have it installed and enabled/running.  But HAL version
is the same (as is everything else) whichever kernel I use.  All I'm doing to
get back to 2.6.13 is selecting it from the grub menu.
Comment 3 Pete Zaitcev 2005-12-19 21:50:00 EST
Right. It's not that HAL is broken, it's my inability to figure how
exactly the kernel broke it. Maybe a symlink in /sys went from block
to block:sda or something of such nature.
Comment 4 Ronny Buchmann 2005-12-23 13:29:42 EST
see http://thread.gmane.org/gmane.comp.freedesktop.hal/3915
Comment 5 Ronny Buchmann 2005-12-23 13:34:22 EST
this patch works for me
Comment 6 Vladimir Kotal 2006-01-14 09:39:58 EST
Same problems here: I own iPod mini which I connect via firewire cable (original
Apple firewire Dock cable). After it is connected, it shows up in dmesg and
device nodes are created via udev and I can mount it successfully. Even ejecting
the device (so the iPod does not display the 'Do not disconnect' message) works
fine.

However, HAL does nothing about it. I would expect it to add entry to /etc/fstab
via fstab-sync(8) but nothing happens.

I have installed following versions of relevant software:
kernel-2.6.14-1.1656_FC4
hal-0.5.2-2
hal-cups-utils-0.5.3-3
udev-058-1.0.FC4.1
Comment 7 Vladimir Kotal 2006-01-14 09:44:59 EST
This issue might be related to the one discussed at:
  http://lists.freedesktop.org/archives/hal/2005-December/004065.html

On my system the device is identified by:

[root@erazim katka]# cat /sys/block/sdb/device/type
14


relevant dmesg entries:

ieee1394: sbp2: Logged into SBP-2 device
ieee1394: Node 0-00:1023: Max speed [S400] - Max payload [2048]
  Vendor: Apple     Model: iPod              Rev: 1.62
  Type:   Direct-Access-RBC                  ANSI SCSI revision: 00
sdb: Spinning up disk......ready
SCSI device sdb: 7999488 512-byte hdwr sectors (4096 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 04 00 00
sdb: asking for cache data failed
sdb: assuming drive cache: write through
SCSI device sdb: 7999488 512-byte hdwr sectors (4096 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 04 00 00
sdb: asking for cache data failed
sdb: assuming drive cache: write through
 sdb: sdb1 sdb2
Attached scsi removable disk sdb at scsi3, channel 0, id 0, lun 0
Attached scsi generic sg1 at scsi3, channel 0, id 0, lun 0,  type 14


I have no problems with sbp2 kernel module not being loaded.
Comment 8 Vladimir Kotal 2006-01-14 11:35:22 EST
One more thing: this might be related to the following hal changelog (http://cvs.freedesktop.org/hal/
hal/ChangeLog?view=markup) entry:

2005-03-20  David Zeuthen  <davidz@redhat.com>

	Teach hal about Firewire devices; tested with both my iPod and
	my Powerbook in Target Disk Mode

	* tools/device-manager/Const.py.in: Collapse ieee1394_host
	and ieee1394_node into ieee1394

	* hald/linux2/physdev.c (ieee1394_add): New function
	(ieee1394_compute_udi): New function


It is evident that ipod+firewire worked at some point for David Zeuthen. (adding to CC)
Comment 9 Dave Jones 2006-02-03 00:10:09 EST
This is a mass-update to all currently open kernel bugs.

A new kernel update has been released (Version: 2.6.15-1.1830_FC4)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO_REPORTER state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

Thank you.
Comment 10 David Goldberg 2006-02-04 15:18:05 EST
Still no joy in the 2.6.15-1.1830_FC4 kernel.  Same symptoms.  Kernel and udev
do their thing, setting up the device files, but HAL does not set up fstab for
it much less mount it.  Manual mounting works, but is annoying.  And it does
still work if I back out to kernel-2.6.13-1.1532_FC4.
Comment 11 David Zeuthen 2006-02-04 15:56:36 EST
As a data point my Firewire storage devices (CF card reader, Harddisk enclosure,
no iPod after I upgraded to the nano :-) works fine on my Powerbook G4 12"
867Mhz using the built-in firewire port. They don't work on my IBM T41 using a
PCCard Firewire adapter.
Comment 12 Ronny Buchmann 2006-02-04 16:29:00 EST
This is actually a bug in hal, see link in comment 4.

Can someone please change the component to hal, so we get a chance that this bug
will be fixed?
Comment 13 Vladimir Kotal 2006-02-05 15:36:04 EST
I have tried to update kernel 2.6.14-1.1653_FC4 to kernel-2.6.15-1.1830_FC4 and it just corrupted my 
GDM login screen two seconds after it appeared on the screen.
Comment 14 David Goldberg 2006-02-09 15:12:59 EST
I opened this with the component set to kernel because it was a kernel upgrade
that triggered the situation (no other changes, as noted in the original post).
 However, I've seen enough in the comments to suggest this is really an issue
with Hal, so I'm setting the component to that now.  I apologize in advance if
that violates any proper procedure.
Comment 15 Stefan Richter 2006-02-14 13:26:04 EST
David's initial assessment that this was a kernel issue is correct in its own
right: The SCSI kernel subsystem maintainers moved RBC handling into a proper
place (from sbp2 which mapped RBC disks to normal disks to sd_mod, the actual
command-set specific driver). Along the way they changed a sysfs attribute of
such devices, thereby broke the kernel's interface to userspace.

This will not be reverted. Instead, userspace tools like hotplug scripts or hal
which evaluate the sysfs attribute "type" of SCSI devices need to be adapted.

Hence it was correct to move this bug to the component "hal".
Comment 16 Stefan Richter 2006-02-14 13:37:39 EST
This is actually a duplicate of bug 174723.
Comment 17 Dave Jones 2006-02-18 23:56:31 EST

*** This bug has been marked as a duplicate of 174723 ***

Note You need to log in before you can comment on or make changes to this bug.