RIMBoy's Tech Support Page

1. Introduction and Considerations (Faq's, do's, don't, suggestions)

2. Why? (Why not?)

3. A word about kernels (and modules)

4. Hardware Used

5. Discovery and Recognition of Hardware

6. Drive Recognition

7. File System Setup

8. Mounting At Boot

9. Spin Up / Spin Down Drive(s)

10. Links

11. Definitions

12. Acknowledgements

1. Introduction

This how-to / faq is intended to aid in the configuration of firewire (aka IEEE-1394) hard disk based storage devices with Linux. The scope of this how-to will only deal with commonly available hard disk storage devices and interface hardware. This how-to does not cover connection to storage devices such as the Apple iPod or DVD type devices. This how-to / faq assumes you are using PC hardware. This how-to also assumes rudimentary skills in kernel compilation, filesystem(s), and hardware installation. You are advised to consult the various how-to's and man pages available if you have questions regarding the concepts presented.

DISCLAIMER: This author cannot be held responsible for any damages to hardware, software, or data that may be damaged as a result of following these instructions. As such, you are warned that in certain cases, damage may occur and the author assumes no responsibility. It goes without saying that if you are concerned about data loss that proper backups are a must.

This how-to was put together by Sean /the RIMBoy/ Jewett. I will attempt to answer any questions. However, I had to research alot of the info you are now receiving the answer for. If I cannot answer your question, a Linux User Group (LUG) will be your best bet for answers. You may also want to hit some of the other various how-to's available. A list of how-to's and other relavent links are listed towards the end of this document.

NOTE: Firewire is a registered trademark of Apple Computer. Firewire is also known as IEEE-1394 outside of the Apple circles. This document will use the term Firewire, in part because it's easier to type.

2. Why?

Why would you want to do this? In my case, I needed a scalable storage solution. I've have a fairly large collection of MP3's (all ripped from CD's I own). My mp3 server already had a hard drive for the root filesystem and a 45 gig HD dedicated to mp3's. In addition, I had a CDRom hooked up, which leaves only one free IDE connector. The last thing I wanted to do was open the case on a regular basis to upgrade the disk space. At some point I knew I would fill the additional harddrive, at which point I'd still have to figure out where to put additional HD space. Until firewire came along, SCSI was the only other scalable solution per se. Given that a single SCSI drive can cost as much as the entire firewire card / firewire hard drive kit, SCSI was decided to be too expensive. In addition, I have many SCSI-1/2 external HD cases that I would want to use should I go that route. Unfortunately SCSI-1/2 drives are hard to find and even then a reasonably priced one will generally top out at 18 gigs (note, I said reasonably priced). It occured to me that Firewire would fit the bill quite nicely and have the added benefit of hot swap / plug and play. Thus adding an new filesystem would amount to plugging in, telling the kernel about the new drive, format, and mount accordingly. Furthermore, these external drive solutions are using inexpensive IDE drives. I did not need high performance, though firewire has impressive specs. I needed accessable storage which could serve the files when I requested them. And I needed accessable storage which could scale as I needed it. As a result, Firewire fit the bill for my need.

Oh yeah. No device ID issues, no conflicts and NO TERMINATION!

3. A word about kernels (and modules)

Before we go any further, we need to look at how we're going to get from point a to b. We certainly can't get there without support in the Linux Kernel. The 2.4 kernel has Firewire support distributed by default. Patches are available to add support in the 2.2 series. This document will cover 2.4 series kernels. Setup, testing, and useage took place with 2.4.19 kernel with the SGI XFS files system patches.

I'm of the firm belief that if you're going to be doing something as important as writing and reading data from a storage device, the drivers for that device should be a part of the kernel. Not modular. I find it easier to compile monolithic the support that I need rather than having to deal with such things as initrd and module conflicts. Your mileage my vary. However, this documentation was built upon the fact that the necessary support to enable firewire support was built sans modules.

If your distribution was not built with firewire support you'll need to build a new kernel. When building the kernel, you'll need to enable the following drivers (make menuconfig):

• Under SCSI support, enable the following drivers:
  SCSI support
  SCSI disk support
  SCSI generic support
  You may also wish to enable the SCSI logging facility. You need not enable the SCSI low level drivers unless you have those devices.

• Under the IEEE 1394 (FireWire) support (EXPERIMENTAL) heading, enable the following drivers:
  IEEE 1394 (FireWire) support (EXPERIMENTAL)
  OHCI-1394 support. Most cards support this standard.
  SBP-2 support (Harddisks etc.). You'll obviously need this if you want to hook your Firewire HD up.
  Raw IEEE1394 I/O support. This is not necessary, but does not hurt to have.

You'll need scsi generic support because the drive(s) will be seen as SCSI devices.

Note that you'll need the appropriate file system support (ext2/3 xfs, etc) in place. Most default kernels and kernels shipped by distributors already have much of this support enabled in the default config.

Obviously at this point, it's time to compile the kernel and any modules.

If you've not done so already, now would be a good time to shut the computer down and install the Firewire card.

4. Hardware Used

Here's where things may get a little specific. However, most of what will be covered is not specific to any hardware per se.

The firewire card was ordered from an online retailer advertising it as a generic card with a TI chipset. When the card arrived it had a sticker indicating it was OHCI-1394 compliant. It was a 3 port card for $14. Otherwise it was a no-name PCI card.

After some extensive research and weighing several options, I settled upon the LaCie D2 series of Firewire drives. It became readily apparent that those drives supporting both Firewire and USB-2 incurred additional cost. Several aftermarket conversion cases were considered but in the end the LaCie option looked the best for my application.

One thing to note is that the firewire cable should snugly fit into both the drive connector and the firewire card connector. If there there is a 1/4" or more of the cable connector showing then chances are the cable is not socketed properly. Only mentioned because this happened during setup.

Because firewire is a specification to support plug and play, it's not necessary to have the drive connected when the system is powered up. However, NEVER unplug a firewire drive that is mounted, especially during reads and writes. You've been warned.

5. Discovery and Recognition of Hardware

When you boot up your system, provided the Firewire card is installed and you have your drive connected, you should see some messages at boot. No need to worry if you don't catch it all. The command

dmesg

Here's what my system reported at boot time:

ohci1394: $Rev: 530 $ Ben Collins 
PCI: Found IRQ 10 for device 00:0a.0
IRQ routing conflict for 00:0a.0, have irq 5, want irq 10
ohci1394_0: OHCI-1394 1.0 (PCI): IRQ=[5]  MMIO=[e6414000-e6414800]  Max Packet=[2048]

What above states is that the ohci1394 driver was loaded. It was reported at IRQ 10, however, there was already another device at IRQ 10, so the firewire card was given IRQ 5 (there is no soundcard in this system). So, the firewire card was recognized.

raw1394: /dev/raw1394 device initialized

Remember that raw device we told the kernel we wanted at configuration time? That above line would be it. And it's in /dev/raw1394 in case we want to use it.

Here's where things get interesting:

scsi1 : IEEE-1394 SBP-2 protocol driver (host: ohci1394)
$Rev: 530 $ James Goodwin 
SBP-2 module load options:
- Max speed supported: S400
- Max sectors per I/O supported: 255
- Max outstanding commands supported: 8
- Max outstanding commands per lun supported: 1
- Serialized I/O (debug): no
- Exclusive login: yes

If you don't have something resembling the above then you'll need to double check everything. In particular, if you're seeing your ohci1394 device but not your SBP-2 device then double check your cabling.

6. Drive Recognition

Here's where things get tricky. According to the Linux Firewire notes, the kernel scans the known scsi busses as one of the first things it does at boot. Makes sense, many systems have their root file system on scsi devices. From there other devices are polled accordingly. One group of devices that are polled after the SCSI devices are polled are the Firewire devices. Seeing as the firewire devices, in particular the storage devices are treated as SCSI devices, those devices miss being polled by the kernel in that first sweep. As a result, until the kernel gets some data on the "new" devices you can't use that brand new 60 gig firewire drive. This shell script will poll those devices and update the information accordingly. It's useful for anything connected to the SCSI bus, not just firewire. It happens to work here and as a result we use it to get the kernel to recognize our drive. When we run the script (which I saved into /usr/local/bin for reasons to be stated later) we see the following output:

[root@miles linux]# /usr/local/bin/rescan-scsi-bus.sh
Host adapter 0 (ide-scsi) found.
Host adapter 1 (sbp2) found.
Scanning for device 0 0 0 0 ...
OLD: Host: scsi0 Channel: 00 Id: 00 Lun: 00
      Vendor:   ATAPI  Model: 44X CDROM        Rev: 3.10
      Type:   CD-ROM                           ANSI SCSI revision: 02
Scanning for device 1 0 0 0 ...
OLD: Host: scsi1 Channel: 00 Id: 00 Lun: 00
      Vendor: ST360021 Model: A                Rev: 3.19
      Type:   Direct-Access                    ANSI SCSI revision: 06
0 new device(s) found.
0 device(s) removed.
[root@miles linux]#

Scanning for device 1 0 0 0 ...
NEW: Host: scsi1 Channel: 00 Id: 00 Lun: 00
      Vendor: ST360021 Model: A                Rev: 3.19
      Type:   Direct-Access                    ANSI SCSI revision: 06
1 new device(s) found.
0 device(s) removed.

instead. Now, if you use the command

dmesg

ieee1394: sbp2: Logged into SBP-2 device
ieee1394: sbp2: Node[00:1023]: Max speed [S400] - Max payload [2048]
ieee1394: Device added: Node[00:1023]  GUID[00d04b281e0a0607]  [LaCie Group SA  ]
ieee1394: Host added: Node[01:1023]  GUID[003095231000eed8]  [Linux OHCI-1394]
scsi singledevice 0 0 1 0
scsi singledevice 0 0 2 0
scsi singledevice 0 0 3 0
scsi singledevice 0 0 4 0
scsi singledevice 0 0 5 0
scsi singledevice 0 0 6 0
scsi singledevice 0 0 7 0
scsi singledevice 1 0 0 0
  Vendor: ST360021  Model: A                 Rev: 3.19
  Type:   Direct-Access                      ANSI SCSI revision: 06
Attached scsi disk sda at scsi1, channel 0, id 0, lun 0
SCSI device sda: 117231408 512-byte hdwr sectors (60022 MB)
 sda: sda1
scsi singledevice 1 0 1 0
scsi singledevice 1 0 2 0
scsi singledevice 1 0 3 0
scsi singledevice 1 0 4 0
scsi singledevice 1 0 5 0
scsi singledevice 1 0 6 0
scsi singledevice 1 0 7 0

In this case, it's aware there's an SBP-2 device is connected. The next line states some of the same diagnostics we saw earlier. The third line identifies where the drive is located on the bus, and the manufacturer. The fourth line contains information about the adapter we're using.

The next set of devices are the scan of the bus the ide-scsi cdrom drive is located on. These messages are there as a result of the shell script. If you notice, when it begins to scan the scsi1 bus the first device it detects (0,0,0) is our LaCie enclosure with the Seagate drive. The drive we're using is formatted, otherwise it should only state sda as the dev entry. Since we've already formatted the drive, it lets us know that there's a valid file system on /dev/sda1.

7. File System Setup

Warning, the following information may damage data if the wrong parameters are specified. Use with caution.

It's now time to setup the filesystem on your new drive. First and foremost, you'll need to setup a valid file system on the drive. We'll use fdisk to accomlish this.

fdisk /dev/sda 

Note that sda was the valid device for my system. It may not be a valid device for your system. Consult the results of dmesg to determine what is the correct /dev entry for your drive.

Since LaCie is a long time manufacturer of aftermarket products for the Macintosh, we want to make sure we don't have a pre-formatted drive (as with the case with any other drives where you want to start from scratch with). You can use the p option in fdisk to print the partition table and then use the d option to delete those partitions accordingly. From there, you'll want to use n to add a new partition. If you want to make the entire drive one big partition simply make it primary (1) and then follow the instructions to use the entire space available on the drive for that partition. After successful creation you now need to change the partitions system id (option t). Use 83 for Linux.

When everything looks good, write out the parition table.

You'll need to format the newly created filesystem. I'll leave this as an exercise to the user given the variety of choices available.

mkfs

I do suggest using the label options available if your filesystem supports it. This should allow you to plug in and remove various drives without having to update your fstab according to their /dev locations. Please note that if you follow fstab entries from the popular distros that the / in the name is part of the label name. Thus, if you create a labeled drive called mp3, then it's entry in the /etc/fstab should be LABEL=mp3, not LABEL=/mp3. If you want /mp3 then you'll need to create your drive's label as /mp3.

8. Mounting at Boot

It's no fun to have to manually remount your mp3 collection everytime your system reboots. As mentioned before, it's a chicken and egg situation regarding the scsi bus. The kernel does not know there's another scsi bus because the firewire devices were not made available until after the initial scsi bus scan.

There's a solution of sorts though. That script rescan-scsi-bus.sh? We're going to make that a part of the boot process. Before we go any further though, you're going to need to make sure that the script is saved somewhere on the ROOT drive. It can be in any directory you want, as long as it's on the root drive. If you've put /usr on it's own filesystem then you can't put the script there. Put it in /sbin then.

In my case, /usr is on the same partition as / (the root fs) and accordingly, I put the script in /usr/local/bin/.

My next step would be to find a place to run the script as part of the boot process. It's important that the script is run before the mount command is executed for all other file systems. Failure to do so will result in your system hanging at boot time. A little bit of research on my Red Hat 7.3 system revealed that rc.sysinit would be the best place to add in the rescan. In /etc/rc.sysinit, I added the following line:

#Re-Init Firewire devices:

action $"Re-Initializing Firewire Devices:" /usr/local/bin/rescan-scsi-bus.sh

Please note that this line fits in with RedHat's standard boot procedure. As a result, running of this script will generate an [OK] message during boot.

Timing is key. You want to make sure that the devices are available for the mount command to function properly. From the looks of things in that rc.sysinit, USB devices have the same problem. As a result, I put the above lines just after the

# Set the hostname.
action $"Setting hostname ${HOSTNAME}: " hostname ${HOSTNAME}

lines and before

# Initialize USB controller and HID devices

lines.

Next, you'll want to update the fstab. Here's what my fstab looks like:

LABEL=/                 /                       xfs     defaults        1 1
LABEL=/boot             /boot                   xfs     defaults        1 2
none                    /dev/pts                devpts  gid=5,mode=620  0 0
LABEL=/home             /home                   xfs     defaults        1 2
LABEL=/mp3              /mp3                    xfs     defaults        1 2
LABEL=mp3.2             /mp3.2                  xfs     defaults        1 2
none                    /proc                   proc    defaults        0 0
none                    /dev/shm                tmpfs   defaults        0 0
LABEL=/var              /var                    xfs     defaults        1 2
/dev/hda5               swap                    swap    defaults        0 0
/dev/cdrom              /mnt/cdrom              iso9660 noauto,owner,kudzu,ro 0 0
/dev/fd0                /mnt/floppy             auto    noauto,owner,kudzu 0 0
/dev/fd1                /mnt/floppy1            auto    noauto,owner,kudzu 0 0

As you can see, I've got a / (root), /boot, /var and /home partitions. All of those reside on one HD. The next mountpoint, /mp3, is a 45 gig drive on one of the existing IDE busses. I decided to call this new drive mp3.2. As you can see, it's label differs from the other drives, but only because I created the drive label sans the / (ie /mp3.2). It's not the end of the world if that / is not there. As you can see, it's an xfs file system, default mount options, and fsck flags set according the way the other non-root file systems are set.

Now, provided your drive was recognized and the shell script run, mount your mount point (ie, mount /mp3.2). If all goes well you should be able to do a

df -h

While I'm one to avoid rebooting Linux systems whenever possible, now is the time to reboot. You've just verified your mount point works. Before you load this drive with data and make it a necessary part of your computing life, take the time to ensure that the drive will be available should you have to reboot the system. Remember, you probably won't remember 4 months from now how things were setup. And that's always when it's a crisis situation.

9. Spin Up / Spin Down Drive

I just wanted to let you know that these commands work to "spin up" and
"spin down" an IDE disk inside of Oxford911 FireWire enclosure (which
shows up as a SCSI device) in Linux.

I did this with all partitions unmounted:

/sbin/scsi-spin -d /dev/sda
/sbin/scsi-spin -u /dev/sda

BTW I'm using the debian stable version of this software:
"scsitools    0.3-2   Collection of tools for SCSI hardware management"

PLEASE NOTE that he did this with the drives UNmounted. Brett followed up with this info:

If you try to spin down a mounted partition, you get this error:

scsi-spin: device already in use (mounted partition)

10. Links

11. Definitions

Firewire, aka IEEE-1394: (from Apple.com) Apple invented FireWire in the mid-90s and shepherded it to become the established cross-platform industry standard IEEE 1394. FireWire is a high-speed serial input/output technology for connecting digital devices such as digital camcorders and cameras to desktop and portable computers. Widely adopted by digital peripheral companies such as Sony, Canon, JVC and Kodak, FireWire has become the established industry standard for both consumers and professionals.

12. Acknowledgements

Brett Hamilton for the drive spin up / spin down info.

Questions, comments, contact Sean /the RIMBoy/ Jewett @
sean@rimboy.com