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

[Sit Heel Speak]

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.

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

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

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

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.

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

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

[Aitch]

Many thanks, SHS

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

[me, too, he he]

Aitch