How to boot from scsi on Puppy 4.1-alpha-5

How to do things, solutions, recipes, tutorials
Post Reply
Message
Author
User avatar
Sit Heel Speak
Posts: 2595
Joined: Fri 31 Mar 2006, 03:22
Location: downwind

How to boot from scsi on Puppy 4.1-alpha-5

#1 Post by Sit Heel Speak »

(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.

Xena has the following profile:
Mainboard: vintage-2003 Supermicro X5DPE-G2, dual-P4-Xeon
Primary IDE master: Western Digital WD102BA, 10GB, UDMA5
Primary IDE slave: Samsung SV4002H, 40GB, UDMA5
Secondary IDE master: Plextor PX-760A DVD writer/reader.
Secondary IDE slave: not connected.
SCSI adapter: vintage-2001 Adaptec 39160, 64-bit pci, scsi-160
SCSI disk 1: Quantum Atlas V 9.1 GB
SCSI disk 2: Quantum Atlas V 9.1 GB
SCSI disk 3: Quantum Atlas IV 9.1 GB
SCSI disk 4: Quantum Atlas V 18.2 GB
Originally I built Xena with the quad raid array cage out of a discarded server, but accidentally destroyed one disk, and the only available replacement was the 18.2 GB. Another V I traded for a IV in a package swap.

Gabrielle has the following profile:
Mainboard: vintage-1999 Asus P2B-DS, two P3-600EB's.
Primary IDE master: Samsung SV1021D, UDMA5, 10 GB.
Primary IDE slave: Hitachi HDS722580VLAT20, UDMA5, 80 GB.
Secondary IDE master: Western Digital WD400BB-00DE, UDMA4, 40 GB.
Secondary IDE slave: BenQ 52x CD-RW writer/reader, UDMA4.
SCSI adapter: vintage-1998 Adaptec AHA2940UW, 32-bit pci, scsi-40.
SCSI disk: vintage-1998 Seagate Hawk ST32155W, 2 GB.
SCSI cd-rom drive: vintage-1999 Toshiba XM-6401TA
Last edited by Sit Heel Speak on Wed 06 Aug 2008, 06:22, edited 10 times in total.

User avatar
Sit Heel Speak
Posts: 2595
Joined: Fri 31 Mar 2006, 03:22
Location: downwind

#2 Post by Sit Heel Speak »

For history and technical overview, see the Wikipedia article on SCSI. I won't re-hash it here. One thing I will add at the outset is, scsi drives characteristically run hot.

This photo shows the scsi drives cage out of the case on Xena.

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, 04:26, edited 4 times in total.

User avatar
Sit Heel Speak
Posts: 2595
Joined: Fri 31 Mar 2006, 03:22
Location: downwind

#3 Post by Sit Heel Speak »

Reference photographs:
Top of drive
Turning the drive over - 1
Turning the drive over - 2
Bottom of drive
Jumper pins

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, 04:15, edited 13 times in total.

User avatar
Sit Heel Speak
Posts: 2595
Joined: Fri 31 Mar 2006, 03:22
Location: downwind

#4 Post by Sit Heel Speak »

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, 18:11, edited 10 times in total.

User avatar
Sit Heel Speak
Posts: 2595
Joined: Fri 31 Mar 2006, 03:22
Location: downwind

#5 Post by Sit Heel Speak »

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.

Rename your previous vmlinuz to vmlinuz-original, download vmlinuz-SCSI1 (for example) into the /boot folder (or /mnt/home, or wherever you keep vmlinuz). and rename vmlinuz-SCSI1 to vmlinuz.

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:

Code: Select all

# GRUB configuration file '/boot/grub/menu.lst'.
# generated by 'grubconfig'.  Thu Jul 31 16:52:13 2008
#
# The backup copy of the MBR for drive '/dev/sda' is
# here '/boot/grub/mbr.sda.10175'.  You can restore it like this.
# dd if=/boot/grub/mbr.sda.10175 of=/dev/sda bs=512 count=1
#
# Start GRUB global section
default 0
timeout 30
color light-gray/blue black/light-gray
# End GRUB global section
# Linux bootable partition config begins
  title Puppy Linux 4.1-alpha-5 frugal install on sda2
  rootnoverify (hd0,1)
  kernel /puppy405-sda2/vmlinuz pmedia=atahd psubdir=puppy405-sda2
  initrd /puppy405-sda2/initrd.gz
# Linux bootable partition config ends
# Linux bootable partition config begins
  title Puppy Linux 4.1-alpha-5 full install on sda3
  rootnoverify  (hd0,2)
  kernel /boot/vmlinuz root=/dev/sda3 pmedia=atahd
# Linux bootable partition config ends
Last edited by Sit Heel Speak on Wed 06 Aug 2008, 02:59, edited 9 times in total.

User avatar
Sit Heel Speak
Posts: 2595
Joined: Fri 31 Mar 2006, 03:22
Location: downwind

#6 Post by Sit Heel Speak »

...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:

Code: Select all

# GRUB configuration file '/boot/grub/menu.lst'.
# generated by 'grubconfig'.  Tue Jul 15 00:31:03 2008
# This is on Sit Heel Speak's /dev/hda1, first ata disk,
# for when bios setup is told to boot first ata (ide) disk first.
#
# Start GRUB global section
timeout 5
default 1
color light-gray/blue black/light-gray
# End GRUB global section
# Linux bootable partition config begins
  title Puppy Linux 4-alpha-6 (k2.6.21.7) frugal install on /dev/hda1
  rootnoverify (hd0,0)
  kernel /pup400-2-6-21-7/vmlinuz ro vga=normal pmedia=atahd root=/dev/ram0 psubdir=pup400-2-6-21-7
  initrd /pup400-2-6-21-7/initrd.gz
# Linux bootable partition config ends
# Linux bootable partition config begins
  title Puppy Linux 4.00 (k2.6.25) frugal install on/dev/hda2
 rootnoverify (hd0,1)
  kernel /Pup400-2-6-25/vmlinuz ro vga=normal pmedia=atahd root=/dev/ram0 psubdir=Pup400-2-6-25 loglevel=7
  initrd /Pup400-2-6-25/initrd.gz
# Linux bootable partition config ends
# Linux bootable partition config begins
  title Puppy 2.14R frugal install on /dev/hda3
  root (hd0,2)
  kernel /pup214R/vmlinuz root=/dev/ram0 ro vga=normal psubdir=pup214R pdev1=hda3 loglevel=7
  initrd /pup214R/initrd.gz
# Linux bootable partition config ends
# Other bootable partition config begins
  title (nonexistent, grub-install puts this in) DOS (on /dev/hdb1)
  map (hd0) (hd1)
  map (hd1) (hd0)
  rootnoverify (hd1,0)
  makeactive
  chainloader +1
# Other bootable partition config ends
# Linux bootable partition config begins
  title Sabayon Linux 1.1 PE on 2nd ata disk, 2nd partition
  root (hd5,1)
	kernel /boot/kernel-genkernel-x86-2.6.23-sabayon-r1  root=/dev/ram0 ramdisk=8192 real_root=/dev/sdf2  quiet  init=/linuxrc splash=silent,theme:sabayon vga=791 irqpoll CONSOLE=/dev/tty1 dodmraid pci=nomsi xdriver=nvidia res=1024x768 
	initrd /boot/initramfs-genkernel-x86-2.6.23-sabayon-r1
# Linux bootable partition config ends
# Linux bootable partition config begins
  title Sabayon Linux 3.5 on 2nd ata disk, 3rd partition
  root (hd5,2)
  kernel /boot/kernel-genkernel-x86-2.6.25-sabayon-r1  root=/dev/ram0 ramdisk=8192 real_root=/dev/sdf3 quiet  init=/linuxrc splash=silent,theme:sabayon vga=791 irqpoll CONSOLE=/dev/tty1 xdriver=nvidia res=1024x768 resume=swap:/dev/sda4
  initrd /boot/initramfs-genkernel-x86-2.6.25-sabayon-r1
# Linux bootable partition config ends
# Linux bootable partition config begins
  title Puppy Linux 4.1-alpha-5 frugal install on scsi disk /dev/sda2
  rootnoverify (hd2,1)
  kernel /puppy405-sda2/vmlinuz root=/dev/ram0 pmedia=atahd psubdir=puppy405-sda2 vga=normal doscsi 
  initrd /puppy405-sda2/initrd.gz
# Linux bootable partition config ends
# Linux bootable partition config begins
  title Puppy Linux 4.1-alpha-5 full install on scsi disk /dev/sda3
  rootnoverify (hd2,2)
  kernel /boot/vmlinuz root=/dev/sda3 vga=normal doscsi
# Linux bootable partition config ends
title Install GRUB to floppy disk (on /dev/fd0)
pause Insert a formatted floppy disk and press enter.
root (hd0,0)
setup (fd0)
pause Press enter to continue.
title Install GRUB to Linux partition (on /dev/hda1)
root (hd0,0)
setup (hd0,0)
pause Press enter to continue.
title -     For help press 'c', then type: 'help'
root (hd0)
title -     For usage examples, type: 'cat /boot/grub/usage.txt'
root (hd0)
Last edited by Sit Heel Speak on Tue 05 Aug 2008, 03:34, edited 4 times in total.

User avatar
Sit Heel Speak
Posts: 2595
Joined: Fri 31 Mar 2006, 03:22
Location: downwind

#7 Post by Sit Heel Speak »

The change in drive orders can be confusing when multi-booting different Puppies, i.e. different Puppies will see the same (1st ata) drive as hda, sda, or sde depending on which kernel is used.

Illustrative screenshots from Xena:

Screenshot of Puppy 4.00 test version (k2.6.25) with charnisingh's .sfs's, frugal install on 1st ata disk, 2nd partition
--sees all disks ata and scsi as sd*
--first scsi drive is sdd
--first ata drive is sda
--Boot Manager does mount add-on .sfs's

Screenshot of Puppy 2.14R (k2.6.18.1) frugal install on 1st ata disk, 3rd partition
--sees ata disks as hd*, scsi disks as sd*
--first scsi drive is sda
--first ata drive is hda

Screenshot of Puppy 4.1-alpha-5 frugal on 1st scsi disk, 2nd partition, booted from ata grub
--sees all disks ata and scsi as sd*
--first scsi drive is sda
--first ata drive is sde
--Puppy Event Manager does not start an upper row, rather overlaps drive icons at far right, when res is only 1024x768
--Boot Manager does mount add-on .sfs's

Screenshot of Puppy 4.1-alpha-5 full install on 1st scsi disk, 3rd partition, booted from ata grub
--sees all disks ata and scsi as sd*
--first scsi drive is sda
--first ata drive is sde
--if screen res is boosted to 1280x1024, there is enough room for the drive icons on a single row
--Boot Manager does not work, on full installs of the 4.1 alpha's.
Last edited by Sit Heel Speak on Tue 05 Aug 2008, 04:11, edited 10 times in total.

User avatar
Sit Heel Speak
Posts: 2595
Joined: Fri 31 Mar 2006, 03:22
Location: downwind

#8 Post by Sit Heel Speak »

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, 04:18, edited 12 times in total.

User avatar
Sit Heel Speak
Posts: 2595
Joined: Fri 31 Mar 2006, 03:22
Location: downwind

#9 Post by Sit Heel Speak »

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, 04:21, edited 2 times in total.

User avatar
Sit Heel Speak
Posts: 2595
Joined: Fri 31 Mar 2006, 03:22
Location: downwind

#10 Post by Sit Heel Speak »

~THE END~

I open the floor. If the above can be whipped into good enough shape, I guess it will go on the Wiki.

User avatar
steevieb
Posts: 289
Joined: Sun 31 Dec 2006, 00:11
Location: Poole, Dorset. UK

#11 Post by steevieb »

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)

Sage
Posts: 5536
Joined: Tue 04 Oct 2005, 08:34
Location: GB

#12 Post by Sage »

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!!

User avatar
Aitch
Posts: 6518
Joined: Wed 04 Apr 2007, 15:57
Location: Chatham, Kent, UK

#13 Post by Aitch »

Excellent effort SHS

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, [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

Aitch

User avatar
Sit Heel Speak
Posts: 2595
Joined: Fri 31 Mar 2006, 03:22
Location: downwind

#14 Post by Sit Heel Speak »

steevieb wrote:lsmod does not show any scsi modules loaded, but everything works ok
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.
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.
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).

User avatar
Aitch
Posts: 6518
Joined: Wed 04 Apr 2007, 15:57
Location: Chatham, Kent, UK

#15 Post by Aitch »

Hey SHS

Final query,

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

http://www.murga-linux.com/puppy/viewtopic.php?t=32458

as provided by flash [apparently it has scsi recognition working, I believe]

Sorry if its a rambley list of vagaries, only I'm not sure of exactly how the boot sequence works, so just trying throwing possibilities at one who may know

Thanks again for bringing hope back to us scsians :D
There's so much good kit out there!!

Aitch

User avatar
Sit Heel Speak
Posts: 2595
Joined: Fri 31 Mar 2006, 03:22
Location: downwind

#16 Post by Sit Heel Speak »

Aitch wrote:Is it possible/could you confirm/otherwise that 2.14R or other puppy kernels could be made to work with scsi booting?
Neither 2.16CE nor 4.00 will boot from live-CD on Gabrielle's scsi cd-rom drive, but 2.14R will. Any Puppy can be recompiled to boot and find its pup_save from a specific scsi adapter, provided the source code / patchset are still available, and provided one has a free evening or two.
Aitch wrote:...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
Of course, yes. You could boot into MS-DOS7 and call grub4dos (grub.exe) from autoexec.bat.
Aitch wrote:...or maybe found with wakepup2008 and a marker
I don't know. I've never tried wakepup on scsi. When I need to boot a usb stick, on a machine which lacks that capability natively as an option in its own BIOS setup, I do so using pakt's original wakepup2. I've never had to boot from scsi or cdrom using wakepup, nor use wakepup in a situation beyond the original's capabilities.

User avatar
Aitch
Posts: 6518
Joined: Wed 04 Apr 2007, 15:57
Location: Chatham, Kent, UK

#17 Post by Aitch »

I do so using pakt's original wakepup2. I've never had to boot from scsi or cdrom using wakepup, nor use wakepup in a situation beyond the original's capabilities.
otropogo wrote: Evidently Freedos/Wakepup2 is able to identify the target partition "W:" (partition 4 on the Zip disk) and read the the name of the Pup_4.sfs file on it, Why the kernel can't find it again is a mystery to me. It can't be that it doesn't know how to handle Zip disks, because Puppy 4.0 mounts and reads the same Zip 100 disk I used in my parallel port tests when it's inserted in a SCSI Zip drive.

Maybe Puppy just doesn't know how to access the parallel port anymore?

Strangely, where Puppy 4.0 kernel 2.6.21 can mount, read and write to both of my SCSI hard drives, and my SCSI ZIP 100 drive, Puppy 4.1 alpha 5 , kernel 2.6.25 doesn't even detect any of these three SCSI drives. I don't think it can be the kernel's fault, because Knoppix 5.3.1, using kernel 2.6.24 still mounts all of them as well.
Crash wrote:Can you believe - two more corrupt (truncated) files on the disk:

\driver\backpack\bpcddrv.sys
\driver\backpack\readme.txt

And no one complained about this over the last year...

I'm working on a floppy image that among other things has versions copied from Wakepup1.1 that at least don't crash when I test them......

.......1st Menu: >.7. PCMCIA

2nd Menu: > 2. PP ZIP

3rd Menu: ASPIPPM1/2/both/none > 4. Neither

4th Menu: Run Guest.exe yes/no > yes

This is contrary to documentation that I find elsewhere, but apparently is how Wakepup 1.1c did the sequence. In other words, Guest.exe is smart enough to load the driver by itself.
This is the concluding stuff after working, heroically, up to date since early May 08, developing Wakepup2008

http://www.murga-linux.com/puppy/viewtopic.php?t=29241

and now Crash has posted it for general testing/proving

I will have to get my kit sorted, as I have a selection of internal and external zip 100/250 as well as 1G & 2G Jaz scsi drives, and zip100/250 parallel drives, [mainly collected from discarded MACs] all of which it would be good to discover if they can be made bootable or not

I think the real arbiter should probably be Pakt, as the creator, AFAIK, some long time back in the past

Aitch

User avatar
Sit Heel Speak
Posts: 2595
Joined: Fri 31 Mar 2006, 03:22
Location: downwind

#18 Post by Sit Heel Speak »

Well, the short version is:

If a frugal install, the pup_nnn.sfs and pup_save.(n)fs are loaded by the init script (inside initrd) at a point before probing is done for necessary driver modules which were not compiled into the kernel.

If a full install, all the environmental variables are set in rc.sysinit, likewise again, at a point before probing is done for necessary driver modules not compiled into the kernel.

If you are using a wakepup boot floppy, what types of drives it can see and search for the kernel and initrd on, depends on what drivers are loaded in the floppy's config.sys.

However, once the bootloader transfers control to vmlinuz (the kernel), the kernel no longer uses the bootloader's device drivers. The composition of the wakepup floppy becomes irrelevant.

So, bottom line: whatever device drivers are necessary for booting, must be either compiled into the kernel, or a modprobe statement must be edited into init or rc.sysinit at a sufficiently early point.

After rc.sysinit, profile, et al have run, and you are at the desktop, it may be possible to read and write from your unusual drives, if rc.sysinit probes and finds that it needs such drivers, or if the user puts a modprobe statement for the necessary driver into rc.local. Regardless of whether it is possible or not to boot from said unusual drives.

User avatar
Aitch
Posts: 6518
Joined: Wed 04 Apr 2007, 15:57
Location: Chatham, Kent, UK

#19 Post by Aitch »

Many thanks, SHS

Your usual succinct clarity, I wish some others had that ability

[me, too, he he]

Aitch :D

Post Reply