Wakepup2 Aug 2008 - floppy image for booting from USB

[Crash]

otropogo-

I never mixed and matched the Kernel and the version of Puppy, but I would think you would get unpredictable results. Which is I guess what you are observing. I wouldn't have thought it would work at all, but that's the miracle of software - you never know.

At the risk of treading over old material, I wonder if the September 2008 version of Wakepup2 would work if you used the following options:

Code: Select all

7 PCMCIA, SCSI, and Zip Parallel Devices (Experimental)

1 PCMCIA

3 aspi2dos.sys

2 No, continue

6 aspicd.sys /d:USB-CD

But first, since I still don't know if archiving off config.exe messes up the pcmcia stuff, could you rename the file "\driver\cardsoft\config.exe" on your working boot floppy and see if it still works? This is important, as archiving off that file frees up about 50K on the floppy that can be used for other things like the text editor. Renaming it back should restore its function if it doesn't work.

[otropogo]

At the risk of treading over old material, I wonder if the September 2008 version of Wakepup2 would work if you used the following options:

Code: Select all

7 PCMCIA, SCSI, and Zip Parallel Devices (Experimental)

1 PCMCIA

3 aspi2dos.sys

2 No, continue

6 aspicd.sys /d:USB-CD

I can't even remember those menu options, after booting more than a dozen times with the latest. And I didn't keep a copy of the September Wakepup. All I've got right now is your test1 floppy.

I renamed \driver\cardsoft\config.exe on it and it still booted 301/301R from "usbcd".

BTW I had a look at the sysinit.log this time, and saw that it kept reporting that it couldn't find kernel 2.6.21.7

[Crash]

I renamed \driver\cardsoft\config.exe on it and it still booted 301/301R from "usbcd".

That's good. That means the archiving I did should work OK, assuming I didn't make any other mistakes.

I can't even remember those menu options, after booting more than a dozen times with the latest.

Yea, it is kinda all becoming a big blur now. Anyway, the option sequence I posted above is as a result of the tests we did over the last couple of days, and should work for the September 2008 version that I posted near the end of the first page of this thread:

ed3984f9208a3c8d55b8cbecd0d673b2 Wakepup2.img

I like that version, although at the time you couldn't get it to work with the PCMCIA SCSI CD. If it works for you with the above option sequence, I won't have to dig deeper into it to look for errors.

P.S. Save that floppy that is working for you now, maybe mark it with "Known Good" or something.

[otropogo]

Code: Select all

7 PCMCIA, SCSI, and Zip Parallel Devices (Experimental)

1 PCMCIA

3 aspi2dos.sys

2 No, continue

6 aspicd.sys /d:USB-CD

... the option sequence I posted above is as a result of the tests we did over the last couple of days, and should work for the September 2008 version that I posted near the end of the first page of this thread:

ed3984f9208a3c8d55b8cbecd0d673b2 Wakepup2.img

I like that version, although at the time you couldn't get it to work with the PCMCIA SCSI CD. If it works for you with the above option sequence, I won't have to dig deeper into it to look for errors.

OK. It works, although there are two more menu steps required

2. usbcd

1. Normal

NB: I dislike Voodoo, and I dislike even more having my credibility undermined. So I set out to replicate the failures I reported earlier with this Sept 7 version of Wakepup2.

I booted ten times in total as follows:

1. following your menu suggestions above, with the 3.01 Standard LiveCD - "usbcd" boot successful

2. same as above, but with 4 alpha 5 LiveCD - adapter recognized

3, 4, 5, 6, 7 selected #1 ALL on third menu, instead of #2 apsi2dos.sys - all five boots failed with "no valid devices present", adapter was not recognized (this is the method I used when I first reported the failure)

8. selected #2 aspi2dos.sys on third menu, but #7 ALL, instead of #6 aspicd.sys /d:USB-CD on the following menu - "no valid device found", adapter not recognized

9. repeat of test 2 - same result, adapter recognized

10. repeat of test 8 - same result, adapter not recognized.

I had done a full format on the disk before writing Wakepup2 to it. Then did a surface scan before booting from it. That, and the consistency of successful and failed boots in this series lead me to conclude that the problem is in the image, not the drive nor the media.

"ALL" presumably includes every individual driver offered in the menu. Yet in seven tries when "ALL" was selected, the adapter was not recognized every time. OTOH, in three tries when aspi2dos and aspicd.sys were specifically selected from the menu, the adapter was recognized every time. So I think the results are pretty conclusive that you need to fix something that goes wrong when either of these two "ALL" options is selected.

BTW - I'm wondering whether Puppy 4.0 or 4.1 LiveCDs would also 'boot" if I their sfs files were changed to "301.sfs" on the disk. Any idea how I could do that?

Is there a way to rename the file on a CD-RW?

[Crash]

otropogo-

Excellent work. Your observations are extremely helpful. I had no doubt that what you were reporting was accurate, but until we narrowed in on exactly what drivers you actually needed, it was hard for me to develop a test case to find out what was happening.

I had added the case "7. All - usbaspi.sys, aspidisk.sys, Addonics, and aspicd" myself. On reflection, it shouldn't have been included - the usbaspi.sys program doesn't go well with himem, so it is an option that I should delete.

As a next test, can you run this combination? It will confirm that the "ASPI Host Adapter Drivers" - "All" option is not a problem:

Code: Select all

7. PCMCIA, SCSI, and Zip Parallel Devices (Experimental)

1. PCMCIA

1. All

6. aspicd.sys /d:USB-CD 

there are two more menu steps required

2. usbcd

1. Normal

I didn't exactly know which options you were taking there, so that's why I didn't include them in the suggested code.

Is there a way to rename the file on a CD-RW?

Yes, there is. You can open up the .iso file on the hard drive, rename the file, and re-write the .iso file back to the hard drive. Then you burn a new CD. I don't believe you can do it directly on the CD. I think the program ISOMaster, which is in the Puppy Multimedia menu, can do this.

Hey, we're getting a lot closer. I was tearing my hair out - getting to know the ins and outs of the "diff" program more than I care to, etc - checking other possible problems. Without being able to run these test cases, I would still be floundering.

[otropogo]

otropogo-


As a next test, can you run this combination? It will confirm that the "ASPI Host Adapter Drivers" - "All" option is not a problem:

Code: Select all

7. PCMCIA, SCSI, and Zip Parallel Devices (Experimental)

1. PCMCIA

1. All

6. aspicd.sys /d:USB-CD 

Yes, that combination works. It's definitely the second "All" option that's responsible for the failure to recognize the host adapter.

When that menu option is invoked, the ASPI CD-ROM driver for DOS is "not loaded: no valid devices present".

BTW - I acquired an old ALR2200 Server yesterday with no drives except a SCSI CDROM player on an AIC7890 host adapter.

I tried to boot the Puppy 4.1 alpha 5 and the Puppy 3.01 Retro LiveCDs with the Sept. 7 Wakepup2, using the #7 pcmcia/#3 SCSI/ #1 All/ # 7 All menu options, and in this instance, the first "ALL option successfully loaded ASPI8u2.sys, and the second loaded ASPICD.sys, and the adapter, the drive, and their settings were successfully recognized.

And then the load failed with exactly the same error message we've been getting with the pcmcia_scsi and parallel port ZIP drives:

"unable to find pup_xxx.sfs"

Hey, we're getting a lot closer. ... Without being able to run these test cases, I would still be floundering.

Ok. Just remember - my floppy drive could give up the ghost any time...Although it looks like the problem is the same with PCI SCSI, so maybe we could continue our experimentation with the server.

[John Doe]

And then the load failed with exactly the same error message we've been getting with the pcmcia_scsi and parallel port ZIP drives:

"unable to find pup_xxx.sfs"

That means you loaded initrd.gz from DOS and it failed to find what it was looking for. It appears that there are not the correct drivers or logic in there to do what you want.

You have the DOS part fixed.

[8-bit]

[/quote]

That means you loaded initrd.gz from DOS and it failed to find what it was looking for. It appears that there are not the correct drivers or logic in there to do what you want.

You have the DOS part fixed.[/quote]

That is what I also mentioned. The boot process is started with the dos version of the drivers needed.
When the kernel boots and passes control to initrd.gz, the linux drivers for the device have to be loaded for the boot to continue.
Otherwise, you come up with a file not being found.
The question here is can the drivers be loaded through initrd.gz to continue the boot process before it goes off to look for pupxxx.sfs?

The Freedos part of the boot process is taking you to the kernel boot process.
It is the linux part of the boot that is failing for lack of loaded device drivers.

[Crash]

Yes, that combination works. It's definitely the second "All" option that's responsible for the failure to recognize the host adapter.

That's good. The bug is confirmed.

There is still one last option sequence that I would like you to try:

Code: Select all

7. PCMCIA, SCSI, and Zip Parallel Devices (Experimental)

1. PCMCIA

1. All

1. Original: aspidisk.sys, Addonics, and aspicd 

This will test that I didn't mess up the original ASPI Peripherals drivers sequence. If this is successful, I will post another September version of Wakepup with the "7. All" option deleted to eliminate its use.

BTW - I acquired an old ALR2200 Server yesterday with no drives except a SCSI CDROM player on an AIC7890 host adapter.

I tried to boot the Puppy 4.1 alpha 5 and the Puppy 3.01 Retro LiveCDs with the Sept. 7 Wakepup2, using the #7 pcmcia/#3 SCSI/ #1 All/ # 7 All menu options, and in this instance, the first "ALL option successfully loaded ASPI8u2.sys, and the second loaded ASPICD.sys, and the adapter, the drive, and their settings were successfully recognized.

This setup should also work with "#7 pcmcia/#3 SCSI/ #1 All/ #1. Original" menu options.
To speed it up, you should also be able to just load the ASPI8U2 driver by selecting
"#7 pcmcia/#3 SCSI/ #7. aspi8u2.sys/ #2. No, continue/ #1. Original".

The Freedos part of the boot process is taking you to the kernel boot process.
It is the linux part of the boot that is failing for lack of loaded device drivers.

I agree too. I have the feeling this thread is going to generate a new one that talks about SCSI support in the Kernel. I'm going to have to dust off my Kernighan & Ritchie...

[otropogo]

[quote="Crash"]

There is still one last option sequence that I would like you to try:

Code: Select all

7. PCMCIA, SCSI, and Zip Parallel Devices (Experimental)

1. PCMCIA

1. All

1. Original: aspidisk.sys, Addonics, and aspicd 

Ok. I used the above menu sequence twice with the pcmcia_scsi, three times with the PCI scsi, and they all ended up at "pup_xxx.sfs not found."

[Crash]

Ok. I used the above menu sequence twice with the pcmcia_scsi, three times with the PCI scsi, and they all ended up at "pup_xxx.sfs not found."

OK, it looks like the test results are successful, even if the full boot sequence can't be achieved. I'll make the change above, edit the readme file, and post a new version. It will take me a couple of days. This should be about as good as it is going to get for Wakepup2 in its present incarnation.

/// Edited Sep 18

In order to avoid confusion, I posted the final version of Wakepup2 at this thread:

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

///

[erikson]

When the kernel boots and passes control to initrd.gz, the linux drivers for the device have to be loaded for the boot to continue.
Otherwise, you come up with a file not being found.
The question here is can the drivers be loaded through initrd.gz to continue the boot process before it goes off to look for pupxxx.sfs?

Yes.

For a full install, the bootloader loads vmlinuz and then passes control to vmlinuz - for further steps, the necessary device drivers must be in there. That's why, for instance, a Puppy full install can't boot off a usb device; the necessary usb device drivers aren't available in its vmlinuz kernel.

For a frugal install, the bootloader loads vmlinuz followed by initrd.gz (loaded into the initial ram disk and containing the init script), then passes control to vmlinuz, that in its turn passes control to init in ramdisk. This is the script that searches for (and mounts) pup_save.2fs and pup_xxx.sfs - in other words, it's okay if the necessary device drivers are (1) available in ramdisk (i.e. in initrd.gz) and (2) correctly modprobed by init.

[otropogo]

For a full install, the bootloader loads vmlinuz and then passes control to vmlinuz -...

For a frugal install, the bootloader loads vmlinuz followed by initrd.gz ....

You haven't explicitly addressed what happens when trying to load Puppy to memory from the LiveCD alone, rather than doing an install.

More specifically, what needs to be done to the LiveCD ISO to allow it to load into memory from SCSI, pcmcia, usb, or the parallel port, after booting with the Wakepup2 floppy? Or, for that matter, what changes the ISO requires to load directly from a bootable SCSI CD drive?

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.

In fact, it appears that the ONLY configuration for which Wakepup has ever been useful is that of loading Puppy from a non-bootable IDE CDROM drive.

Worse, if I understand Crash, 8-bit, and you, correctly, there is nothing more one can do with Wakepup to enable these long advertised but never realized capabilities. It has to be done in the Puppy LiveCD ISO.

Have I grasped the situation correctly?

[erikson]

You haven't explicitly addressed what happens when trying to load Puppy to memory from the LiveCD alone, rather than doing an install.

No, because I haven't investigated the LiveCD boot sequence as yet.

At first sight I think it's the same as "frugal", in the sense that the LiveCD bootloader loads vmlinuz and initrd.gz from the CD, and then transfers control to vmlinuz (with initrd.gz in initial ramdisk, as for frugal). Then init takes over to load pup_xxx.sfs; it can do so because iso drivers for cd are available in initrd.gz.

Worse, if I understand Crash, 8-bit, and you, correctly, there is nothing more one can do with Wakepup to enable these long advertised but never realized capabilities. (...) Have I grasped the situation correctly?

I'm not familiar with wakepup.

Insofar I understand, wakepup is nothing more than an alternative bootloader, that runs from a DOS-formatted floppy, and that's supposed to load vmlinuz and initrd.gz from devices without boot capability.

Ultimately the init script has to take over for the rest of the booting process, and for doing so, the appropriate device drivers must be available in the kernel or in initrd.gz - otherwise you'll get "pup_xxx not found" or something equivalent.

[erikson]

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

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

If in the Puppy-frugal-core then issue (2) is fulfilled and a frugal-installed Puppy should boot from device xyz.

If elsewhere in Puppy, you have to do some extra work to fulfill issue (2), namely:
(i) identify the relevant driver(s),
(ii) locate it/them in pup_xxx.sfs or zdrv_xxx.sfs,
(iii) extract it/them and merge it/them into a custom-made initrd.gz,
(iv) edit the init script in your custom initrd.gz such that the driver(s) are correctly modprobed and such that device xyz is properly mounted and scanned for pup_save.2fs, pup_xxx.sfs and zdrv_xxx,
(v) install your custom initrd.gz along with standard vmlinuz, pup_xxx.2fs and zdrv_xxx.sfs on device xyz.

If not in Puppy (i.e. if you can't access device xyz from a completely booted Puppy), you're out of luck. You'll have to find relevant drivers on the web --- maybe in pets, maybe in packages for other linux distro's, maybe in source form... --- integrate them into your custom initrd.gz as discussed in previous paragraph, and iterate through testing and debugging.

---

Above applies to frugal installs (details are mutatis mutandis for various Puppy versions; I focused on the concepts).

For full installs, exactly the same reasoning can be used, but there's no initrd.gz and the relevant drivers must be available in resp. custom-added to vmlinuz. That's way more difficult than integration in initrd.gz.

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