Wakepup2 Aug 2008 - floppy image for booting from USB

[otropogo]

It seems that, after many weeks of detecting and replacing all of the numerous corrupted files in Wakepup, we have only succeeded in establishing beyond a shadow of a doubt that it CANNOT load Puppy from:

Parallel port Backpack CDROM
Parallel port ZIP drive
pci/isa/eisa SCSI drive
PCMCIA, and
USB

despite having sported menus for these functions for years.

Actually there are *two* distinct issues to consider:

(1) wakepup's capability to load the "Puppy-frugal-core" i.e. vmlinuz plus initrd.gz into RAM

And what is the definitive sign that (1) has occurred?

(2) the Puppy-frugal-core's capability to take over and mount/load pup_save.2fs and pup_xxx.sfs.


As I said before, I don't know wakepup well enough to discuss whether/how it handles issue (1) for the devices you mention; I'll leave that to crash. Evidently one can't blame wakepup for failure of issue (2).

But that is precisely the issue we're trying to nail down here...

So, now regarding (2).

Assume that you succeed in booting Puppy one way or another, e.g. from Live-CD. Now you can test whether or not this completely-booted Puppy can access some particular mass storage device "xyz".

If so, the necessary drivers are available in Puppy. Conceptually, these are the "device driver" to access the physical medium (e.g. usb-attached hdd, parallel-port attached ZIP drive...) and the "filesystem driver" to handle the filesystem as formatted (e.g. ext2/3, fat16, fat32, ntfs...). The drivers may be in the Puppy-frugal-core or "elsewhere" in Puppy i.e. in pup_xxx.sfs or in zdrv_xxx.sfs.

What if they're in the 2fs file?

When I boot my frugal install of Puppy 3.01 Retro on the CF-25 laptop without the 2fs file, gpccard reports the pcmcia_scsi host adapter and an "ATA/IDE fixed disk" in Sockets 1 and 0, respectively. But neither the filesystem on the LiveCd attached to the scsi adapter in Socket 1, nor that on the CF card in Socket 2 are mountable, or even noted, by Pmount or MUT.

They're only accessible when the 2fs file is loaded.

[erikson]

And what is the definitive sign that (1) has occurred?

The first message issued by the init script to console, namely "Loading kernel drivers needed to access disk drives"

(...) Evidently one can't blame wakepup for failure of issue (2).

But that is precisely the issue we're trying to nail down here...

Okay, that's what I thought.

But it *can't* be solved in wakepup (remember, that's just another bootloader) --- as soon as wakepup has passed control to vmlinuz, wakepup has done its part and is no longer in charge.

What if they're in the 2fs file? (...) They're only accessible when the 2fs file is loaded.

Ah okay, *great* !!!

If I understand correctly that you *can* access files on those devices when your pup_save.2fs is loaded, this means that you already *have* located the necessary drivers from "somewhere", and that you got them working.

Now, for solving issue (2), these drivers aren't needed in pup_save.2fs (that's "too late") but in initrd.gz. Just do the extra work (i.e. merge them in a custom-built initrd.gz and adapt its init script) as I outlined in steps (i)...(v).

Note that mere "detection" of the devices by gpccard is not enough, as you experienced.

[8-bit]

I do not know if this will help you on the puppy boot end, but go to
http://puppylinux.com
Select Developers Page.
Select Loading modules
There are very detailed guide to how puppy loads modules on boot and where it finds them, and also how to include your own.

I hope that helps out some.

[erikson]

I do not know if this will help you on the puppy boot end, but go to
http://puppylinux.com
Select Developers Page.
Select Loading modules
There are very detailed guide to how puppy loads modules on boot and where it finds them, and also how to include your own.

Thx for pointing out, the developers section indeed contains lots of useful background info.

Two comments about the specific page you're referring to ("Kernel module loading"):

(1) The page applies to Puppy 4 and how it supports device hotplugging, actually a new Puppy feature. Older Puppies don't have the pup_event and udev schemes and don't handle hotplugging very well.

(2) The page focuses predominantly on driver loading after the switch_root event, that takes place at the very end of the init script in initrd.gz. For our purposes of solving issue (2) as I identified it, that's too late. The drivers for exotic device xyz from which we want to boot must be available inside kernel or initrd.gz - otherwise pup_save and pup_xxx (with the additional drivers) just can't be loaded. It's a chicken-and-egg problem.

[otropogo]

..What if they're in the 2fs file? (...) They're only accessible when the 2fs file is loaded.

Ah okay, *great* !!!

If I understand correctly that you *can* access files on those devices when your pup_save.2fs is loaded, this means that you already *have* located the necessary drivers from "somewhere", and that you got them working.

Not really. Of the several devices I listed, the ONLY one known to work when Puppy is fully loaded and running (and only when the 2fs file is loaded), is pcmcia_scsi. AND that only works in Puppy 3.01 Retro, because there's no driver module compiled (at least as far as I can determine) for Kernels later than 2.6.18.

I don't know whether there are drivers available to support parallel ZIP, parallel Backpack CD, or bootable PCI SCSI adapters in Kernels 2.6.18. 2.6.21, or 2.6.25 I only know that the former two aren't accessible when Puppy 3.01 Retro or 4.0 are loaded and running, and that the last won't load a Puppy LiveCD.

Add it all up, and the sum total is a big fat "0".

[erikson]

Add it all up, and the sum total is a big fat "0".

I dunno.

A quick google search on, for instance...

linux parallel port storage driver

... returns 113,000 hits.

I bet there must be at least something useful.

Though I'm personally not motivated to dig through the material, my laptop doesn't even have a parallel port...

[otropogo]

....

A quick google search on, for instance...

linux parallel port storage driver

... returns 113,000 hits.

I bet there must be at least something useful...

By that logic, the fact that Wakepup has for years and through many versions had menus for loading Puppy from parallel port Zip and parallel port Backpack should be rock solid assurance that one could actually do this....

[erikson]

By that logic, the fact that Wakepup has for years and through many versions had menus for loading Puppy from parallel port Zip and parallel port Backpack should be rock solid assurance that one could actually do this....

Right.

But wakepup uses DOS drivers (crash can confirm or correct me). What is needed for inclusion in initrd.gz are the corresponding Linux drivers.

[8-bit]

Resoning says I am missing something here.
Wakepup essentually boots vmlinux (the kernel) and passes parameters as to what device to boot from.
How can the kernel access the initrd.gz file after it loads by using DOS drivers that it was never meant to be able to use.
Not finding the pupxxx.sfs file I can understand.
As we are assuming with no linux support drivers for the device the pupxxx.sfs file is on we get it not being found.

Have you given thought to a linux boot disk set that say loads the kernel from the first disk and a drivers disk that loads after that and continues to boot Puppy from tthe device.
I bring this up since Deli linux uses this method for install from cd using floppies to boot the kernel and drivers needed to access the cd.

[Crash]

But wakepup uses DOS drivers

Yes, only DOS drivers are in Wakepup, no Linux drivers.

I'm not too much into the Linux side of things, but as far as I can tell, once vmlinuz executes, all the DOS stuff "goes away". Then it is up to the Kernel to find the rest of Puppy.

This can be demonstrated by the following: First, copy vmlinuz and initrd.gz onto your hard drive. Next, boot to DOS with no drivers, maybe using a floppy disk. Then execute vmlinuz with your method of choice - mine is to use linld.com and execute a line something like "LINLD.COM image=C:\vmlinuz initrd=C:\initrd.gz "cl=root=/dev/ram0". If the Kernel has driver support for your hardware, it will find and execute Puppy no matter where it is - CD, USB Stick, etc. This is with ZERO DOS DRIVERS. It all happens in the Kernel.

I've done this procedure entirely from floppy - it takes three disks - one to boot that also has initrd.gz on it, two more to hold vmlinuz. Vmlinuz is too big to fit on one floppy, so it has to be split and concatenated back together into a RAM disk before execution. In hindsight, it was kind of a lot of work to convince myself that Linux doesn't care anything about the DOS drivers.

[erikson]

Resoning says I am missing something here.
Wakepup essentually boots vmlinux (the kernel) and passes parameters as to what device to boot from.
How can the kernel access the initrd.gz file after it loads by using DOS drivers that it was never meant to be able to use.

I assume that wakepup is similar to e.g. isolinux or grub bootloaders, i.e. it loads vmlinuz *and* initrd.gz, then passes control to vmlinuz.

If my assumption is correct (it must be), vmlinuz can find the init script from initrd.gz in the initial ramdisk (initramfs). This script can then modprobe the (Linux) device drivers for loading pup_save and pup_xxx --- of course, if and only if these Linux device drivers are built into vmlinuz or into initrd.gz. That's the whole point of our discussion.

That's for a frugal install. For a full install, there is no initrd.gz - in that case, only vmlinuz is loaded and must be capable of accessing the drives using built-in (Linux) device drivers.

I'm not too much into the Linux side of things, but as far as I can tell, once vmlinuz executes, all the DOS stuff "goes away". Then it is up to the Kernel to find the rest of Puppy.

Correct. In the case of a frugal install, the "Kernel" is what I called "Puppy-frugal-core", i.e. vmlinuz plus initrd.gz in initramfs, that both have to be loaded into RAM by the bootloader before it hands over control to vmlinuz.

(...) use linld.com and execute a line something like "LINLD.COM image=C:\vmlinuz initrd=C:\initrd.gz "cl=root=/dev/ram0"

Actually linld.com, yet another bootloader, *does* use DOS drivers to get the specified image (vmlinuz) and initramdisk (initrd.gz) into RAM.

[Jesse]

BTW - although Puppy loaded into memory from the pcmcia_scsi CDROM, neither Pmount nor MUT show the drive.

I forgot to try this when I had the 3.01 Retro LiveCD mounted, but I know it would be the same, since it was only after Tempestuous found the aha152x_cs driver for the kernel that I was able to access the pcmcia_scsi chain with my frugal install.

So this is yet another mystery to me. How is it that the kernel is able to load Puppy into memory from a pcmcia_scsi drive, but once loaded and running, it can no longer access that drive?

Oh, and one other thing. Neither Pmount nor MUT detect the CF adapter in the other pcmcia slot either.

Hello,
The kernel is loaded by bios driver commands, once it starts running the bios drivers are obliterated so the kernel has to install its own drivers to be able to access the boot device.
Once you have figured out which drivers are needed, its basically as simple as putting those drivers in the initrd.gz, and getting the init script to load them.
mut, and lsmod might be able to help you figure out which ones you need.

From your fully working setup you can use the steps below to figure out what drivers are needed.
This mut2 command (below) will get mut to tell you what is on the PCI bus, and what drivers are loaded there, here you should see your PCMCIA device (probably not the plug in cards themselves). It'll advise what it reckons the drivers and driver dependancies are.
/usr/sbin/mut probepci --list -d -b
Once your PCMCIA has its drivers loaded, you'll need the scsi layers to access the drives, kernel module names: "cdrom" "sr_mod" "usbcore" "usb_storage" "ehci_hcd" "ohci_hcd" "uhci_hcd".
There may be some missing drivers that crossover between the two sets of drivers, and you'll need to crossreference with lsmod output to see if theres anything extra there.
Now boot up with kernel and initrd and see what drivers are missing from your list, add them into the initrd.gz and retry.
Once all the right drivers are loaded, Pmount and MUT will see the drives.

Hope that helps.
Jesse

[Crash]

Actually linld.com, yet another bootloader, *does* use DOS drivers to get the specified image (vmlinuz) and initramdisk (initrd.gz) into RAM.

It got me to thinking, hey, this stuff is GPL, so I should be able to find the source code somewhere. Sure enough, after some Googling, I found linld097devel.tar.bz2 at the iso9660.org web site. To my surprise, it was not just the source code, but the Borland C compiler, assembler, linker - everything needed to do a make. It's only 535K compressed! Pretty cool. I copied the files over to a FAT32 partition and re-booted in DOS, then proceeded to run the make file - actually just a batch file. It compiled, assembled, and linked just fine. Excellent learning exercise.

As a newbie to Linux, I haven't even scratched the surface of all the great tools that are available. I'm just beginning to look at the Puppy Unleashed information, looking into the contents of the kernel directories, etc. I may never be able to contribute at that level, but at least I can have fun trying.

[otropogo]

...
From your fully working setup you can use the steps below to figure out what drivers are needed.
This mut2 command (below) will get mut to tell you what is on the PCI bus, and what drivers are loaded there, here you should see your PCMCIA device (probably not the plug in cards themselves). It'll advise what it reckons the drivers and driver dependancies are.

Code: Select all

/usr/sbin/mut probepci --list -d -b

Afraid not.

This command opens the MUT Window but returns no information in the console. In fact, the console hangs...

Mut shows my Sandisk SDCFH2-002G (2GB CF card) as a generic Vfat drive

And the Puppy 4 alpha 5 LiveCD in the drive on the pcmcia_scsi adapter simply as sr0 Data CDROM

I don't think any drivers are needed to support the CF adapter and card other than those enabling pcmcia support itself.

For the pcmcia_scsi chain the problem is that the most recent working scsi module I've been able to find is that for Kernel 2.6.18. Presumably, it would have to be recompiled to work in later Kernel versions.

[sideburns]

One thing is not clear to me: do you put wakepuppy on a boot floppy, or does putting it on the floppy make it bootable? Some of the posts in this thread seem to imply that wakepuppy does everything you need to boot, but nobody ever says so. I ask, because I remember the old loadlin days where you had to boot into DOS and run it from there, and I wanted to make sure.

[otropogo]

One thing is not clear to me: do you put wakepuppy on a boot floppy, or does putting it on the floppy make it bootable? Some of the posts in this thread seem to imply that wakepuppy does everything you need to boot, but nobody ever says so. I ask, because I remember the old loadlin days where you had to boot into DOS and run it from there, and I wanted to make sure.

Wakepup2 is normally created from the Puppy Desktop, but it's been cleaned up and reorganized, with an img file posted in this thread Sept 14 IIRC being the final product.

You use rawrite under DOS, or the equivalent Windows or Linux methods, to make a bootable floppy disk from this image. This should allow you to boot Puppy from a hard drive installation that won't boot for some reason, or from a Puppy LiveCD in an IDE CD drive that's not bootable.

It's supposed to be able to allow you to boot Puppy also from:

a non-bootable isa/pci/eisa SCSI drive

a pcmcia_scsi drive

a parallel port ZIP drive

a parallel port Microsolutions Backpack drive

But so far there's no evidence it has ever succeeded with any of the last four methods. And we've been trying to figure out how to realize all or even any of these capabilities.

[sideburns]

I see. Thank you. I was planning to install Puppy on a thumb drive and have a floppy with wakepuppy for PCs that can't boot off a USB drive, but it looks like that won't work. Again, thank you.

[cromabianca]

I don't know if this can be helpful, but I want to ad my experience.

I started by trying to load linux from a PenDrive, then I tried from a PCMCIA CD-ROM drive...

well, in each case, I get this:

Code: Select all

Autoexec.bat does not contain label 'writeoption'

I can in fact access both the PenDrive and the CD-ROM from the DOS prompt (simply by typing

Code: Select all

D:

and

Code: Select all

W:

) so I know that wakepup makes them devices available); so it seems to me that the problem must be the autoexec.bat file, not the drivers.

What does Autoexec.bat does not contain label 'writeoption' mean anyway!?!?

[Keef]

Just for reference:
I have a Compaq Armada 3500 with no HDD or CDROM and a single USB port that can't be booted from.
WakePup2 will successfully boot a frugal install on a USB stick, either directly in the port, or in a hub. Also works with a CF card in a multi-card reader / USB hub combo.
I've just received a cheapo PCMCIA CF card adapter, and I'm going to see if I can get any joy from that (seems highly unlikely, going by what's been said so far...)

[otropogo]

Just for reference:
I have a Compaq Armada 3500 with no HDD or CDROM and a single USB port that can't be booted from.
WakePup2 will successfully boot a frugal install on a USB stick, either directly in the port, or in a hub. Also works with a CF card in a multi-card reader / USB hub combo.
I've just received a cheapo PCMCIA CF card adapter, and I'm going to see if I can get any joy from that (seems highly unlikely, going by what's been said so far...)

That's certainly good news for USB laptop owners. This is the one Wakepup boot option I haven't actually been able to test myself, as my laptop has no usable USB support.

There was one previous report of success, but that was later withdrawn as unreliable IIRC..

If you can get Wakepup2 to boot Puppy from a CF card in USB_pcmcia adapter, that would certainly be amazing. Please report your results in any case.

Which Puppy version and Kernel did you succeed in booting BTW?