I booted the Puppy 3.98 CD on an HP Vectra VE, 64 MB RAM, some Linux swap,
with "puppy pfix=ram" just fine. (Love the new arctic coastline wallpaper...)

The console screen log entry about "Searching for Puppy files...", or whatever,
appears on both the Gateway 2000 and HP CD boots with "puppy pfix=ram".
At this point, however, the Gateway 2000 gets a
Kernel panic (something not syncing) every time, the HP does not.

On the Gateway, with Puppy 3.96, k2.6.23.12,
the CD boots work perfectly.
With Puppy 3.97, k2.6.21.7, the same Kernel panics occur as with 3.98.

So, is this a case where ancient hardware (1997 vintage, Pentium MMX, 200 MHz!)
boots with a newer kernel, but not with an older kernel?

I installed both Dingo beta and barebones as manual frugal installs. I had a strange issue with drive/partition designations. My hard drive was mounted as sda1, sda2, and sda3. These designation are usually given to my flash devices plugged into my multibay card reader. sdc was still given to my mp3 player, but my multibay card reader was reassigned the designation of sro1, through sro4(If I had that many cards plugged into the reader).
Also I found that the pdev1 and psubdir parameters did not work unless there was a an actual pup_save file in the directory specified. When I want to load straight away into ram (no pup_save) I use pdev1 and psubdir without putting a pup_save in the specified directory. This prevents (at least with all other 3.x and up series pups and puplets) the loading of my pup_save which resides elsewhere. Barebones however, refuses to boot like this. My only option to test was to boot from CD then creat a 32mb dummy pup_save and place it next to my real pup_save, eject the CD, delete the pdev1 and psubdir parameters then reboot. This course of action brought up the expected menu choice asking me to choose the correct pup_save file or 0 for no pup_save file. It really should be considered to have puppy always offer to boot without a pup_save from frugal. If there is only one pup_save it should not be assumed Puppy found the correct one as many people often do not want to use one at all, especially if it means upgrading to a version they only want to test out for a while.
Lastly I still cannot get an eth port for any of my wireless card in any of the Dingo versions. I can get the driver to load, but no port gets created. Very strange.

I have have tried to install a .pup package (MU's Puppy-Software-Installer). It first told me that .pup was superceded and that I needed to install a couple of others (dotpuphandler and puppybasic) before it would work. That was fine, but executing the .pup brought up a window with the package name and then did nothing else.

Am I trying something stupid because .pup packages no longer work at all? Or is PSI broken/redundant in Dingo?

When the screen said: "Power down.",
I pressed the CD drive Eject button to eject my Puppy 3.98 CD.
The drive would not eject my CD!
The machine (HP Vectra VE) was still powered on,
the screen said, "Power down.",
but pressing the CD drive Eject button
did not make the CD eject.

How could that be?
Oh, must be a Bug in there somewhere
keeping it from ejecting.

Oh, that reminds me, with Puppy 3.96 doing an install...
I was booted from HD,
but used the CD for the source of files for a second install.
After the files were copied,
and the install application finished using the CD drive,
I could not eject my CD then, either!
The CD drive Eject button would not work!

What's happening with all this CD hoarding
after the CD is no longer being used
by the application or system?

Hi Barry, I am getting this error when trying to boot from a CD (also happened on Alphas) with my Intel's D201GLY2 MB. See screen shot. I think it only worked with the newer kernel.
Also any chance of the video drivers added to puppy please
http://www.murga-linux.com/puppy/viewtopic.php?p=187900#187900
Cheers
Tony[/img]

All going well with my usual install of firefox, gqview, gimp and other goodies,
desk setup the way I like it , with a reboot of each install of new prog.

All going well until I loaded a prog to view what's on my USB ports,
as this is not in the basic DINGO V4.00 I got from the repos and completed the
install only to find after a reboot that my bottom toolbar had gone also the MENU
opening. I can still get to the progs I loaded with the mouse control but I notice
that the style and size of fonts are changed .

I tried three different installations of Dingo Beta. I did two simple upgrades of a frugal installations. A simple upgrade is just deleting the old version of vmlinuz, initrd.gz, pup_###.sfs and zdrive_###.sfs and then copying the new versions of the files.

The first frugal installation was on my desk machine with Intel Celeron 2.5GHz with 1024 Megabytes of memory and a 40 gigabyte hard drive. The partition is ext2 filesystem, so Puppy used the entire partition and no save file. It worked fine.

The second frugal installation was on a Intel Classmate (500 Mhz and 512 Megabyte memory). The puppy installation is on FAT32 partition and uses a save file. Once again, the update when well. The only problem is the Classmate small screen. Dingo Beta restored all the screen icons. The small screen gets a bit crowded. One has to remove the un-used icons (Play, Draw, Spreadsheet, etc.) to get some room. I also had to set the JWM tray/bar to autohide. Once again for more screen. I had changed my screen background to the one of the first PupEee (an Eagle in flight). The new installation did not change the background.

The third installation was a full installation on an available empty ext2 partition on the desktop hard drive. The first attempt the "Universal Installer" just stopped and exit after selecting the drive and partition to be used. I tried a second attempt and got the same results. So on the third attempt, I had Pprocess up to watch what was going on. On the third attempt, the Universal Installer worked perfectly fine. A version of Murphy's Law (when one can track down the cause of a problem, everything will work correctly) was invoked by the system. I had selected "update" Grub option. It work, but the actual Grub loader was on another partition so no changes were made. The /temp directory did have the "NewGrubText" file so it was easy to cut and paste the correct information into the menu.lst file of Grub. I have found always to check for Grub changes when modifying Grub after a new installation.