After I installed openSUSE 11.1 / KDE on a 64-bit HP laptop, I connected an external WD hard-drive via Firewire, but it didn’t appear in the Device Notifier, and it’s not in the Dolphin display either. (The controller does show up in Hardware Information, as “Texas Instruments OHCI Compliant IEEE 1394 Host Controller”.)
So I installed libraw1394 and -8 with Yast, but it makes no difference.
Anyone know how to proceed?
My external firewire drives “just work” with both a 32-bit and 64-bit openSUSE-11.1, both running KDE-3.5.10.
Some suggestions:
Thanks, Oldcpu. [The oldest one I’m familiar with was in an IBM System 360/50 mainframe. Happy days.]
Actually there are two identical dual-interface WD external drives, one all NTFS and the other all FAT32. Behaviour is the same for both. I’ve only tried connecting them one-at-a-time via Firewire so far. (There’s only one socket on the laptop, and no daisy-chain attempted.)*
Can you post output of:
lsmod | grep 1394
This would show us if at least something is loaded for the firewire protocol.
My pleasure . . .
[18:54:25 /etc]> lsmod|grep 1394
ohci1394 31364 0
ieee1394 98464 2 sbp2,ohci1394
[18:56:28 /etc]>
I was not so much interested in it appearing in dolphin, to see if " fdisk -l " detects it.
its good that the USB detects it (and presumeably it shows up with " fdisk -l " when you plug in via USB).
Have you tested the drive’s Firewire with MS-windows? It works? I’m somewhat surprised it does not show up with “fdisk”. Your dolphin statement makes me think you did not understand what I asked, … you did run “fdisk” twice, right? And compare the outputs with drive plugged and not plugged in? Note you may have to give the drive a minute or so after plugging in (dependant on the drive).
I’m wondering if UDEV/HAL have a problem with Firewire on your drive.
The: lsmod | grep 1394 #command without the drive plugged in gives me this:
oldcpu@hal1000:~> lsmod | grep 1394
ohci1394 31364 0
ieee1394 98464 1 ohci1394
oldcpu@hal1000:~>
where my system works.
with the drive plugged in gives me this (where again, my drive works):
oldcpu@hal1000:~> lsmod | grep 1394
ohci1394 31364 1
ieee1394 98464 2 sbp2,ohci1394
Also for comparison, the “fdisk -l” gives me this with my drive plugged (where sdb is the firewire external drive on my PC):
hal1000:/home/oldcpu # fdisk -l
Disk /dev/sda: 1500.3 GB, 1500301910016 bytes
255 heads, 63 sectors/track, 182401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00094fab
Device Boot Start End Blocks Id System
/dev/sda1 1 12748 102398278+ 7 HPFS/NTFS
/dev/sda2 * 12749 16572 30716280 83 Linux
/dev/sda3 16573 16827 2048287+ 82 Linux swap / Solaris
/dev/sda4 16828 182401 1329973155 5 Extended
/dev/sda5 16828 176027 1278773968+ 83 Linux
/dev/sda6 176028 177939 15358108+ 83 Linux
/dev/sda7 177940 182401 35840983+ 83 Linux
Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x844f0716
Device Boot Start End Blocks Id System
/dev/sdb1 1 121601 976760001 7 HPFS/NTFS
Yes, I did fdisk twice, before and after connecting the drive, and gave it plenty of time to ready itself. Identical results. No trace of the external drive. (I meant AND doesn’t appear in Dolphin. Also not in the Device Notifier.)
It’s the same with the lsmod display. Doesn’t change whether or not the Firewire cable is connected (sbp2 always appears).
The drives work fine on the same machine in XP with Firewire. In fact that’s how I wrote most of their contents in the first place.
Do you have any other USB or firewire devices plugged in at the same time?
I’m still suspicious this could be hal or udev related (which is well beyond my expertise to address)
No other Firewire devices (there’s only one socket), and only a USB mouse. No other connections to anything except an ADSL router via Ethernet.
I’ve seen HAL mentioned in a Dolphin message, but I can’t remember the context.
. . . I had switched the laptop off, but I just booted it up again to check out the HAL message. This time the drive was powered on and connected during boot, and it came up with no problem. Strangely reminiscent of how Windoze often behaves.
Looks like my problem has solved itself. Thanks for your time, Oldcpu, and my apologies for wasting it.
This time the drive was powered on and connected during boot, and it came up with no problem.
It looks like that was all you needed to do then?
Glad to read you are happy with a solution, although hot plug automounting should work.
The behaviour you described (works when booting with the drive, but does not boot with hot plug auto mount) is IMHO the same symptoms one would get if there was an inappropriate entry in the /etc/fstab file that is blocking the hot plug auto mounting.
The behaviour is still not correct.
IMHO you should either write a bug report, or work with the community to solving why hot plug auto mounting does not work. Note if its not an inappropriate entry in the /etc/fstab, then its unlikely that I can help.
I’m happy enough for now, but only because I have a lot more setting up to do on three, maybe four, machines and this was getting in the way.
Nothing would please me more than to help solve the problem, but my Linux skills are as yet pretty limited. Which doesn’t mean that I haven’t already learned a lot from this fine messageboard.
So – what can I best do to help? First off, I’ll go to the laptop and post its fstab, lsmod, and fdisk output. After that, I’ll do whatever some expert suggests as a good problem-solving approach.
[Meanwhile, I’ll be trying to kick Samba into submission.]
Here’s that information. The device was connected via Firewire at the time.
[09:39:50 /etc]> lsmod|grep 1394
ohci1394 31364 1
ieee1394 98464 2 sbp2,ohci1394
[09:40:04 /etc]> cat fstab
/dev/disk/by-id/ata-TOSHIBA_MK1031GAS_36QX3599S-part5 swap swap defaults 0 0
/dev/disk/by-id/ata-TOSHIBA_MK1031GAS_36QX3599S-part6 / ext3 acl,user_xattr 1 1
/dev/disk/by-id/ata-TOSHIBA_MK1031GAS_36QX3599S-part7 /home ext3 acl,user_xattr 1 2
/dev/disk/by-id/ata-TOSHIBA_MK1031GAS_36QX3599S-part1 /windows/C ntfs-3g users,gid=users,fmask=133,dmask=022,locale=en_US.UTF-8 0 0
/dev/disk/by-id/ata-TOSHIBA_MK1031GAS_36QX3599S-part2 /windows/D vfat users,gid=users,umask=0002,utf8=true 0 0
proc /proc proc defaults 0 0
sysfs /sys sysfs noauto 0 0
debugfs /sys/kernel/debug debugfs noauto 0 0
usbfs /proc/bus/usb usbfs noauto 0 0
devpts /dev/pts devpts mode=0620,gid=5 0 0
[09:40:31 /etc]> su -c 'fdisk -l'
Password:
Disk /dev/sda: 100.0 GB, 100030242816 bytes
255 heads, 63 sectors/track, 12161 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x94e494e4
Device Boot Start End Blocks Id System
/dev/sda1 1 6963 55922265 7 HPFS/NTFS
/dev/sda2 11232 12030 6417967+ c W95 FAT32 (LBA)
/dev/sda3 12031 12161 1052257+ d7 Unknown
/dev/sda4 * 6963 11231 34290711 f W95 Ext'd (LBA)
/dev/sda5 6963 7153 1534144+ 82 Linux swap / Solaris
/dev/sda6 7154 8804 13261626 83 Linux
/dev/sda7 8805 11231 19494846 83 Linux
Partition table entries are not in disk order
Disk /dev/sdb: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x8d399bc0
Device Boot Start End Blocks Id System
/dev/sdb1 1 12238 98301703+ 7 HPFS/NTFS
/dev/sdb2 12239 24476 98301735 7 HPFS/NTFS
/dev/sdb3 24477 36714 98301735 7 HPFS/NTFS
/dev/sdb4 36715 60801 193478827+ f W95 Ext'd (LBA)
/dev/sdb5 36715 44743 64492911 7 HPFS/NTFS
/dev/sdb6 44744 52772 64492911 7 HPFS/NTFS
/dev/sdb7 52773 60801 64492911 7 HPFS/NTFS
[09:40:48 /etc]>
I now notice another problem: Dolphin displays only 5 of the 6 partitions on the WD external disk. The one at /dev/sdb6 (wd1-e2) doesn’t show. Device Notifier says “Last plugged in device: wd1-e2”. To say that I’m flummoxed would be criminal understatement.
Here’s a screen-grab. The message at the bottom is what appears when I click on “Volume …”.
Thanks. I don’t know enough about the lsmod difference we saw between your and my lsmod (for the ieee1394 sbp2) when the firewire external drive was not connected, to make any comment.
Your fstab file is clear and very straight forward. Clearly no firewire entries there. I’m not at a Linux PC so I can not comment on the usbfs entry in the fstab, but it looks ok from what I recall.
The ‘fdisk -l’ was interesting. I noted 14 partitions with the external drive attaced. Thats “just under the wire” from what I recall. When openSUSE moved to “libata” there was a 15 partition limit imposed.
So it should not be a problem … it is though ‘close to the wire’.
Any chance that partition was not unmounted correctly last time it was used. Each and every partition should be unmounted properly on both Windoze and Linux, and if necessary a " chkdsk /f " conducted on each partition.
Reference the screen-grab , I don’t know enough about this to comment on the specifics of the error message.
You likely have enough information to write a good bug report. http://en.opensuse.org/Submit_a_Bug
Is sdb internal or external?
The sdb6 part that you are having trouble with: If it’s a usb external, make sure that from windows the usb HD is safely removed.
If it’s internal you need in entry in fstab
eg:
/dev/sdb6 /media/e2 ntfs-3g defaults 0 0
It’s a 500GB Western Digital external drive with both USB and Firewire connectivity. All the stuff I’ve posted here is to do with it being connected via Firewire.
It has three Primary partitions and three Extended. The one that Dolphin doesn’t see is an Extended one. It’s not clear to me how one is supposed to detach a multi-partition drive cleanly on Linux. I’ve been detaching each partition separately in Dolphin so far, and seen no error messages, but no messages indicating success either. Is there a better way?
If the drive has been used in **windows? **and not been safely removed before reboot, it can leave the drive ‘dirty’.
The drive was originally used successfully in both Vista and XP, on three different machines.
My next move after my previous post was to reboot the laptop in question with XP, and check the drive out there. (This is ALL Firewire.)
It came up with all six partitions showing in Windows Explorer, and all of them accessible. I performed chkdsk /f on all of them (no errors reported), and then removed the drive cleanly with the Western Digital interface software provided with the drive, as usual. Explorer showed that the drive and all its partitions were no longer connected.
I then closed XP down cleanly and rebooted SUSE. Same results as already reported – one Extended partition missing and the others all present and correct. Device Notifier still shows the missing partition as “Last plugged in device”.
Anything else I can try?
I’ll just repeat what I noted earlier:
… of course I have shelfish motives here.
I have 4 external hard drives with both USB & firewire, and they all just work with openSUSE-11.1. But I am thinking of purchasing another one (I take way too many movies with my HD videocam corder) and I may again go for a USB & firewire. I would hate to run across the same problem. 
And I won’t if you get it fixed first …
Did you try this with a liveCD to see if it makes any difference?
No problem, Oldcpu. As far as I’m concerned, the world is your lobster. Let me give it another day or two. If nothing transpires, I’ll concoct a formal bug report. OK?
No, but I will try that, probably later today. It might not be SUSE. OK?
With reference to these WD drives I have, namely two 500GB WD500P032s (I think they’re marketed as MyBooks) – I love them, but they’re not perfect. The first problem I had with them (in Windoze Vista and XP, using USB) was that they would sometimes refuse to be removed cleanly, and I got some truly terrifying error messages. But never lost any data.
I think all that was to do with a USB hub, rather than the drives, and I’ve not had those problems with them since I stopped using the hub, and now I only use them with the built-in USB ports (on three Windoze machines). But data-transfer rates are completely unpredictable. Similar tasks can take minutes or hours. I can’t detect a pattern or predict which it’ll be. Maybe it’s the way I look at them.
Until now Firewire hasn’t been a problem except with daisy-chaining. That has never worked on any machine I’ve tried, and it even seems to stop a clean boot on SUSE (it hangs with an all-white screen – pull the da-ch cable out and boot completes). There are horror stories about WD daisy-chain problems on the Web, so it isn’t just me.
Perhaps WD have cleaned up their act by now – these drives are at least a year old – but I wouldn’t know.