(This is a rough draft. I'm asking for input, toward working it up to Wiki quality)

Beginning with Puppy Linux 4.1-alpha-5, a set of optional kernels with scsi support compiled-in is available for download. By choosing the kernel suitable to your particular scsi adapter, you can now boot Puppy from an scsi disk. The purpose of this thread is to disclose how I do so on two systems, Xena and Gabrielle. The method used for installing scsi-Puppy on Gabrielle is applicable to systems that do not have an ide/ata drive.

In the cage's original Dell tower case, the cage sits just behind the front panel, at about the center, and gets air blown across the disks from a duct, fed by a muffin fan mounted at the bottom front inside of the case.

The case I built Xena in does not have such a fan. Cooling fans (and other cooling devices) exist which are specially designed to cool hard drives, and they work OK, but they are expensive and I am tight-fisted. So, as shown, I bolted the 120mm 12V muffin fan out of a scrapped power supply to the uncabled end of the cage, positioned so that all four disks get fanned.

Unfortunately, one day I was running Xena with the cage out of the case as you see here, and neglected to plug-in the fan. Consequently the bottom drive in the cage, in close proximity to the insulating layer of the carpet, overheated and went to That Great Server Farm In The Sky.

Even if you are running just a single scsi drive, as in Gabrielle, it is a good idea to rig a modest fan --the nearly silent 60mm CPU cooling fan from a Pentium Pro is ideal-- so that the drive receives a breeze. It doesn't need a blast, just a slight breeze is sufficient, blowing across either the top or bottom surface of the drive. If you wet your fingertip and stick it at the end of the scsi drive opposite the cooling fan, and you feel any cooling at all, that will be enough.

I have owned the Seagate Hawk in Gabrielle since 1999; I plucked it from a Gateway server I bought used while living in Washington DC. The Hawk has outlasted five computers.

In my experience scsi drives are in general more reliable than IDE drives, but they do demand cooling.Last edited by Sit Heel Speak on Wed 06 Aug 2008, 00:26; edited 4 times in total

In this composite photograph (scroll down) you can see how the label on the drive's top matches the etched labels near the jumper pins on the bottom of the drive, thus you can tell which jumper is which. If your drive does not have such labelling, then you must go online and obtain the manual from the manufacturer.

Explanation of the jumpers on the Quantum Atlas IV/V is here. With this drive, which was standard equipment in Dell servers of its day, jumpering is dead simple: each drive has three jumpers.

The drives are numbered from top to bottom of the cage 1, 2, 4, 8 by jumpering, respectively, SCSI id jumpers 0, 1, 2, and 3. If you number yours differently, leave id #7 for the adapter. That's its standard number.

Delay Spin is jumpered. And so, each drive spins up upon receiving a "start/stop unit" command from the 39160 controller. Since the controller probes the scsi ID #'s one-at-a-time in order at boot time, this ensures there won't be undue strain, i.e. all-at-once current draw, on your power supply. If your scsi adapter does not probe in sequence, then you would want to jumper "Stagger Spin" instead. This make spin delay a multiple of id #.

Termination Power is jumpered on all drives. For an explanation of scsi termination see here, under "TERMINATION - basics".

OK --drives are jumpered and installed in the cage, fan is screwed on tight so it blows across all four. Now, the cable...make sure it is certified for scsi-160 operation. I used an Amphenol 4-drive ribbon cable, nice because the connectors are clearly labelled that the cable meets the LVD/SE standard, which means it's good for scsi-160. ***edited: and it is another example of the incredible bad luck I've had with hardware this whole year...that this cable failed not long after I photographed it. I see a kink near drive ID # eight). (Fortunately, these were US$1 apiece in the scrap bin, so I bought a few spares)***

The connector next to the terminator (that little circuit board on the end) goes on the bottom drive in the cage, #8, next-up goes on #4, then #2, then #1, then finally the end opposite the terminator goes on the inboard port (channel A) on the 39160. Connect power plugs to the drives,...don't forget to connect the cooling fan...install the cage back in your computer...and...

...connect up your scsi drive activity LED plug(s). On the 39160, from the corner in, they are positive-negative-for-channel-A, positive-negative-for-channel-B. The white wire or black wire goes on negative, the colored wire on positive. Now...boot the machine.Last edited by Sit Heel Speak on Tue 05 Aug 2008, 00:15; edited 13 times in total

There is probably no need to go into the machine's BIOS setup, assuming nothing unusual has been done to it in the past. It's OK if you just let the 39160's PCI slot get auto-assigned an IRQ. Typically the 39160 takes IRQ 11.

Presently the Adaptec's own BIOS starts up and you see a prompt "Press Ctrl-A for Adaptec SCSI Select(TM) Utility". Press Ctrl-A and you will presently see these screens:

First screen, press Enter.
Second screen, press Enter. You'll see the
Configuration screen. Down-arrow to "Boot Device Configuration," press Enter, and you should see this.
Now press Escape back to the Configuration screen, down-arrow to "SCSI Device Configuration," press Enter and you should see this.
Now press Escape back to the Configuration screen, down-arrow to "Advanced Configuration," press Enter and you should see this.
Now press Escape back out to the Second screen, down-arrow to "SCSI Disk Utilities," press Enter, and the Adaptec should proceed to do a scan of the scsi bus, at the end of which you should see all your drives plus your adapter shown like this.

At this point, Congratulations! It is a reasonably good bet that you have a good cable, good drives, and you have jumpered them correctly.

OK...Now Escape out of Adaptec SCSISelect, and you should see a splash screen of some sort, showing that you have four drives at "Sync 160". If it shows only "Sync 40" then either you don't have scsi-160 drives or else you have a ribbon cable not rated for scsi-160. If you see "sync something-in-between" --I never have, but I am told that "sync 80" happens sometimes-- then perhaps you have only a 32-bit PCI slot, rather than the 64-bit which Xena's mainboard has. No worries, the 39160 will still work on the 32-bit slot.

Assuming you see "Sync 160" or "Sync 80" on all your drives...let's boot up Puppy 4.1-alpha-5 from the Live-CD, with "puppy pfix=ram" at the "boot:" prompt, and proceed to install grub and Puppy on the scsi disks.Last edited by Sit Heel Speak on Mon 04 Aug 2008, 14:11; edited 10 times in total

Ok...you're at the desktop now...and, you don't see any of your scsi drives. Before you can see them, you need a kernel with scsi support compiled-in.

With Xena, here's how I made the necessary special kernel-install: first, I made a frugal install of Puppy 4.1-alpha-5 to an ata disk partition in the usual way. Then, I rebooted into the new install...set up my network...and the browser...and surfed to where the scsi kernels for Puppy 4.1-alpha-5 are kept, thanks to the generosity of TedDog from the great state of Texas. You need to download one of the three, vmlinuz-SCSI1, -SCSI2, or -SCSI3. For the Adaptec 39160 the correct one is vmlinuz-SCSI1. The way to tell is, you must compare your scsi adapter by brand name to the list of config switches for each of the three scsi kernels.

Now, reboot. This time, you will see your scsi drives. On Xena, PMount looks like this. Notice, the scsi drives are assigned letters first, followed by the ata drives, followed by the usb stick. Too bad they aren't sorted sda sdb etc. correctly, but PMount is getting there...

Next, I used GPartEd to create these partitions on sda (the first scsi drive). The reason for the small first partition is, I discovered that grub, at least in the version used in 4.1-alpha-5, cannot boot from an scsi drive if installed to the root superblock (the default). Instead I had success with grub installed to the mbr. I placed the grub config file (/boot/grub/menu.lst) on /dev/sda1, and the /boot subdir is all that is on sda1 (except for lost+found). Given the reputation of grub-in-the-mbr...I decided to put the actual installs elsewhere, a frugal install on sda2 and a full on sda3...with the copy of the original mbr on sda1 which the grub installer makes, as well as /boot/grub/menu.lst, copied to another drive just in case things go south; if I lose my sda mbr I can always use GPartEd to reformat the partition, then reinstall grub to the mbr, copy over the previous (working) menu.lst, and I'm back in business.

So...you can proceed then to use Puppy Universal Installer to install Puppy. I placed a frugal install on sda2 and a full on sda3. At the point where PUI asks what type of disk to place it on, do not answer "old scsi" (not exact wording) but rather tell PUI it is an internal IDE or SATA disk.

Here is the Grub menu.lst, on /mnt/sda1/boot/grub, which, when "boot first scsi disk first" is chosen in BIOS setup, gives me the choice of booting the frugal on sda2 or the full on sda3. Yes, I know, I'm telling the kernel it is on an ata hard drive, nevertheless this works:

...and now, if when I reboot, I go into BIOS setup and select the first scsi disk to be the first boot device...I get Puppy booted off scsi. At this point it would be possible to entirely do away with any ata hard disks.

Puppy 4.1-alpha-5 can, of course, also be installed to one of the ata drives. Then, with "first ata drive" chosen to be first boot device in BIOS setup...menu entries can exist in menu.lst, to boot the scsi-resident Puppies. However, the number-assignment conventions of grub are a bit puzzling, in that if the 1st ata disk is (to grub) hd0, and the first scsi disk is hd2, then why is it necessary to call the second ata disk hd5 to boot the Sabayon installs? All disks do have a boot-flagged partition. I will further investigate this puzzle as time permits.

Here is the menu.lst I use when "first ata drive" is selected as the first boot device:

And now for Gabrielle. A diagram of the jumpers on the Seagate disk drive is here;. I have it jumpered as follows:

J6 (SCSI ID#): un-jumpered, = ID#0. The factory cover is still on the four pins to the left of the ID jumpers pin-row.
J2 has two jumpers: Terminator Enable, and Terminator Power From Drive. Unlike the Quantum drives on Xena, the Hawk on Gabrielle does have its own termination circuitry onboard, so does not require its 68-pin cable to have an end terminator.

Manufacturer documents for the Toshiba cd-rom drive are here. I have it jumpered thus:

SCSI ID# is 5
Parity-checking jumper is on. Gabrielle's 2940UW adapter supports parity checking.
Terminator jumper is on. Like the Hawk disk, the XM-6401B has its own internal termination circuitry, so its 50-pin cable does not need its own terminator.
Eject Prevention jumper is off.
Audio Reproduction jumper is off.
Termination Power jumper is on.

The cables are connected to the drives with the colored edges (pin 1) next to the 4-pin power connectors. The colored edges connect to the ends of their respective sockets on the AHA2940UW closest to the external 68-pin connector. SCSI activity LED's are the same arrangement as Xena's 39160.

OK, it's all cabled...insert the 2940UW into a free pci slot, plug power into the drives, and boot up. Presently you'll see the same Ctrl-A prompt as with Xena's 39160. Pressing it brings you the Adaptec AHA-2940UW's own setup screens.

The screens on the 2940UW resemble those on the 39160, except it goes straight into what on the 39160 is the second screen. Thus, you see:

First screen.
Configuration screen.
Down-arrow-and-Enter on "Boot Device Options" brings you to the
Boot Device Configuration Screen. Notice, it is different from the Boot Device Configuration Screen on the 39160, in that, on the 39160 you are choosing which channel (A or B) to boot from, with the choice of which individual device left up to the machine's own Boot Device setting in BIOS setup; but here, on the 2940UW, you select the individual boot device by ID#. The default is device #0, which was assigned (by jumper) (on the drive) to the scsi hard drive. Press Enter, down-arrow to 5, and Escape back out. It will now look like this.

Now the first scsi boot device will be the cd-rom (which was set by jumper, above, to device id #5). If no bootable live-CD is in the drive, then the 2940UW searches up the chain beginning with device #0, which we have set to the scsi hard drive.

"SCSI Device Configuration" screen looks like this, essentially identical to that on the 39160 except for the slower 40 MB/sec sync transfer rate.

"Advanced Configuration Options" screen looks like this. Escape back out to the First screen, down-arrow to "SCSI Disk Utilities," Enter, and the 2940UW does the same probe as the 39160, presently showing the devices on the scsi bus like this.

Escape back out, choose to exit the Adaptec SCSI Select Utility and reboot. Now...you have two options.

First option is, you can boot the 4.1-alpha-5 Live-CD in the ata cd-rom drive, and make a frugal install to an ata drive, then import the new scsi-support kernel in, as described above in the case of Xena.

Or, you can use a nifty trick I discovered: it turns out, that the Puppy 2.14R Live-CD, is capable of booting with the "puppy pfix=ram" boot parameter, from either the scsi cd-rom drive or the ata one. (Puppy 2.14R is almost capable of booting natively from scsi; it will boot OK from an scsi drive, just cannot find its pup_save.3fs if the pup_save is on the scsi disk).

If you boot 2.14R from the scsi cd-rom, once it's up and you have the network and browser set up, you can then use 2.14R's GPartEd to place one small and two equal partitions on the scsi drive, similar to what I did on the first Quantum on Xena, and then remove the 2.14R Live-CD, put in the 4.1-alpha-5 Live-CD (or, alternately, put the 4.1-alpha-5 Live-CD in the ata cd-rom) and mount it; copy the Puppy 4.1-alpha-5 files onto the second partition of the scsi drive in similar manner as I did on Xena; surf to the scsi-kernels webpage and download the appropriate scsi-kernel to the new 4.1-a5 frugal install; rename the vmlinuz; install grub to the mbr of sda; and adjust the /boot/grub/menu.lst on sda1 to match the one I placed on the Quantum on Xena. You can now remove all cd's from the cd drives, reboot, choose "SCSI boot device" as the first boot device in BIOS setup. The machine will try the scsi cd, find nothing there, and proceed to boot into the scsi drive, and you can choose the new frugal install. From this you can then proceed to put a full install on the third partition of the scsi drive, same as on Xena.

This latter method provides a route to install an scsi-native 4.1-alpha-5 on a system which has nothing but scsi, no ata/ide equipment at all.Last edited by Sit Heel Speak on Wed 06 Aug 2008, 00:18; edited 12 times in total

Finally...in theory, devices on the scsi bus are accessed in priority according to id #; if you add, for example, an scsi scanner, or an scsi cd or dvd burner, you will want to read up on the subject of id # priority here.Last edited by Sit Heel Speak on Wed 06 Aug 2008, 00:21; edited 2 times in total

Great how-to!
I now have a frugal install, booting from scsi, for the first time.
Grub is on the 1st scsi disk, as is the frugal.
Used scsi2 version of vmlinuz as scsi1 did not recognise disks, although it booted ok.
lsmod does not show any scsi modules loaded, but everything works ok.
Also sound works just by running the wizard - another first. (old isa card)

Amazing! Fantastique! Please accept this honorary knightship.
Mind you, once they read and digest all that, a lot of folks might take the easy way out....
Do you already have the above in a single nice tidy file, please? Make that .rtf or .wpd , though, not .doc!!

I have been reading/writing my scsi drives in 2.14R for a good while, [or at least until my w2k drive crashed] but never thought about trying different partitions & boot in a mini partition only, yet along you come, obviously having tried all sorts of combinations

Great effort; *****

Now, all I need is to clear a bit of workspace for the hardware manipulations, which includes rigging up a new/old stock 21" monitor to replace the visionmaster 17 which has gone green on me.....

Then contemplate digging my dualie Dell serverbox out of the cupboard, since this now looks worth a shot - twin p3/1.2ghz xeons + 4gb ram, if memory serves - woohoo
I've been needing an excuse for a speedup, .........then a gigahertz lan switch will be needed

Yep. No .ko modules (shown in lsmod) are loaded, but the necessary support is compiled into the kernel.

Sage wrote:

Amazing! Fantastique! Please accept this honorary knightship.

You must have a most intriguing trove.

Quote:

Mind you, once they read and digest all that, a lot of folks might take the easy way out....

Well, good on them. They are wealthy and can afford new usb/sata/firewire gear and I am not.

Quote:

Do you already have the above in a single nice tidy file, please? Make that .rtf or .wpd , though, not .doc!!

Not yet, but if it's going on the wiki I'll need to convert it to html, with the images all reduced to 700 (600?) pixels width and inlined. Once it's in html, creating an .rtf version will be just a few minutes' extra work. It'll take a while though. My dance card is pretty full this upcoming week. I'll notify you.

Aitch wrote:

Not quite sure I understand why setting scsi drives as ata works, but hey...I have been reading/writing my scsi drives in 2.14R for a good while

I have no idea why pmedia=atahd works and pmedia=scsihd (with the marker file named appropriately) doesn't. I simply report what worked. Yes, 2.14R in its present 1.01 incarnation has the .ko loadable modules for scsi, but they aren't yet loaded at the early moment when Puppy searches for its pup_save, which is why it is necessary to compile scsi support into the kernel in order to not simply boot from scsi but to moreover find the pup_save (if it's on scsi).

I read some time ago that scsi booting support was available in the kernel used in 2.14R [2.16.8?] and was the same as used in slackware, which could apparently boot scsi [maybe the kernels could be compared & modded?]
theory was that there was merely something needing turning on in the modules list

Is it possible/could you confirm/otherwise that 2.14R or other puppy kernels could be made to work with scsi booting?
[I know you sent me the howto compile stuff, but it's far too complex for my poor brainbox to handle]
or, are we doomed to - scsi booting only works after this version?

An alternate idea that has occurred to me, having read your methodology, is, could a small partition be put on the scsi drive formatted to fat32 with dos loaded into it, e.g. via w98 bootdisk & sys C:\ command, or for the scsi boot utility & to put puppy boot or grub into, or maybe found with wakepup2008 and a marker

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum