This patch changes ofboot on my Apple G5:
--- /usr/sbin/ofpath 2005-09-13 09:43:10.000000000 -0400
+++ /var/tmp/ofpath 2006-02-10 02:43:11.000000000 -0500
@@ -299,9 +299,9 @@
;;
ata_k2|sata_svw)
HOST_LIST="$(for i in `find /proc/device-tree -name compatible` ; do
- lgrep "$i" "k2-s-ata" ; done)"
+ lgrep "$i" "k2-sata" ; done)"
DEVICE_PATH="$(printhost $SCSI_HOSTNUMBER $HOST_LIST)"
- echo "${DEVICE_PATH##*device-tree}/[EMAIL PROTECTED]/[EMAIL
PROTECTED]:$PARTITION"
+ echo "${DEVICE_PATH##*device-tree}/[EMAIL PROTECTED]:$PARTITION"
;;
*)
echo 1>&2 "$PRG: Driver: $SCSI_DRIVER is not supported"
Specifically, it changes the output for /dev/sdb2 so that instead of
matching a suffix of the output for /dev/sda2, it closely resembles
the output for /dev/sda2, differing only in the number in the k2-sata@
part of the pathname.
That patch fixes one assumption, but it also adds a new assumption.
The assumption it fixes is that there is one file named "compatible"
for each SATA disk at the k2-sata-root level of the /proc/device-tree
directory structure. My /proc/device-tree directory structure has a
k2-sata subdirectory for each SATA disk in that directory. The change
to the lgrep pattern in the code which sets HOST_LIST adds one more
level to each pathname; the other change in the patch accounts for
that by not adding that level separately.
The new assumption added by the patch is that the k2-sata-root
directory underneath /proc/device-tree has subdirectories named
k2-sata; offhand that doesn't seem any worse than the assumption that
there is a k2-sata-root directory, but I don't claim to know enough
about /proc/device-tree to know that for sure.
I can, however, confirm the following: for my first SATA disk the
patched ofpath script generates the same result as the unpatched
script, and the result for the second SATA disk makes a lot more sense
from the patched script than for the unpatched script. I'm just not
sure that this patch won't make ofpath worse on other Mac systems
which I don't have available for testing purposes (but my offhand
guess is that this is the right patch).
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
