Booting from External FireWire Disk [was: Re: Simple 'yes or no' question...]

[Bill Fink]

On Sun Jun 22 2003, Tim Seufert wrote:

> On Saturday, June 21, 2003, at 10:38  PM, Bill Fink wrote:
> 
> > Actually, you can boot Linux from an external FireWire drive if you
> > have a recent enough PowerMac that has OpenFirmware support for booting
> > from FireWire.  I just wrote up a HOWTO on the process, which I'm
> > attaching to this message.
> 
> Bill, this is an impressive document.  I salute the amount of effort 
> that must've gone into it.  A couple comments / suggestions which 
> hopefully may improve it:

Thanks.  And comments are always welcome.

> > 	2.  A recent Linux distro and kernel, with the kernel built
> > 	    having the ieee1394, ohci1394, raw1394, and sbp2 drivers
> > 	    configured as modules.
> 
> This might be nitpicking but I don't think the raw1394 module is 
> actually required for any of this.  It allows userspace programs to 
> drive 1394 devices that aren't handled by in-kernel drivers.  Since 
> disks are all handled by the sbp2 driver, raw1394 isn't necessary (for 
> booting, anyways).

Ya, I realize that.  I find that having raw1394 is handy for
troubleshooting, as it allows you to run gscanbus.  But you are
correct that it's not really needed for booting from a FireWire
disk.  I just left that explanation out of the document.

> > 	     Using the Apple MacOS Drive Setup utility to originally
> > 	     format the FireWire disk may be a necessary step, as the
> > 	     ability of OpenFirmware to boot from a FireWire disk may
> > 	     depend on a FireWire driver installed on the FireWire
> > 	     disk as part of this process (note the "Apple_FWDriver"
> > 	     listed above on sdd4).
> 
> Actually, those are purely for the benefit of MacOS.  If you don't plan 
> to use any partitions on the drive under MacOS, the driver partitions 
> aren't needed.  MacOS X doesn't need them, BTW, just 9 and earlier.  
> They're an artifact of the fairly arcane disk driver architecture of 
> 'classic' MacOS.
> 
> The only time I've seen an Open Firmware driver installed on a special 
> disk partition is with MacOS X RAID volumes.  OF doesn't know about any 
> RAID formats so it needs a driver to access them.

Thanks for the info.  I wasn't sure so I figured I'd err on the overly
cautious side.  I'll update this info when I make a revised version of
the HOWTO.

Out of curiousity, maybe you know the one bit of magic that has eluded
me so far about how this actually works.  I know that OpenFirmware has
support for booting from FireWire, and that enables loading ofboot.b
and yaboot from the FireWire disk bootstrap partition.  But what I don't
fully understand is how yaboot loads the Linux kernel and initrd from
the FireWire disk's ext2|3 root file system.  I can't imagine that
OpenFirmware knows anything about ext2|3 file systems, or that yaboot
has a built-in FireWire driver, so I'm not sure exactly what magic is
performed to bridge that gap.  But it obviously does work.

> > 	 8.  Mount the FireWire root filesystem:
> >
> > 	     mkdir /fw
> > 	     mount /dev/sdd8 /fw
> >
> > 	     You may want to create an entry in /etc/fstab:
> >
> > /dev/sdd8               /fw                     ext2      noauto       
> >    0  0
> 
> OK, so this is the main thing I wanted to give some feedback about.  
> With SBP2 disks, it would probably be a very good idea to assign each 
> FS a unique volume label and perform all mounting steps by label rather 
> than /dev/sdd8 etc.  With label based mounting, the system will 
> successfully boot even if you add another Firewire disk and it happens 
> to show up as sdd, pushing your root disk to sde.  See the man pages 
> for tune2fs and mount for information about creating and using labels.

Ya, I was thinking about that over the weekend.  If I moved my
FireWire disk (sdd) to another system without SCSI devices, it
would then be sda and the /etc/fstab would be wrong.  Labels
seemed to be the obvious solution, although I haven't yet played
around with them myself.  I'll definitely be looking into this
more and will update a future version of the HOWTO once I've had
a chance to check it out.

> The one hole in this is that I don't think you can label swap 
> partitions.  I don't know what to do about that.

That is a problem although I believe you don't actually require a
swap partition to boot Linux.  Hopefully the kernel does a sanity
check on the partition before actually using it as swap.  Another
possibility might be to use a file for swap.

> Given the use of labels, the script on the initrd should really run 
> rescan-scsi-bus.sh rather than poking at a single device.  I've never 
> messed with initrds so I have no idea if the initrd environment is 
> complete enough to run a full shell script like that one.

I wanted to avoid using the actual rescan-scsi-bus.sh script because
then you need not only that script copied to the initrd, but also any
programs it references, and any shared libraries that those programs
require, plus I'm not sure what the exact capabilities of the limited
nash shell are.  Perhaps it would be sufficient to unconditionally
do a bunch of "scsi add-single-device" commands, but that would only
work if redoing a "scsi add-single-device" command for an existing
device wasn't harmful.  Or perhaps adding the required stuff to the
initrd wouldn't be that bad.  It will require some further investigation.

> One really nifty thing that is easier with labels is to prepare a Linux 
> boot drive with the IDE disk mounted on one of the internal IDE busses, 
> then move the disk to an external Firewire enclosure.

Thanks again for your comments.  They were very helpful and gave me
some good ideas to try out as soon as I get the chance.

						-Bill