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]