logoPuppy developer news:

from 3.00 to 3.01

left-arrow Older news

arrow-rightLater news

Puppy version 3.01 released 

The announcement and release notes here:

Get it from here:
http://distro.ibiblio.org/pub/linux/dis ... uppylinux/
or if you prefer FTP:

Booting after frugal install with 'psubdir' parameter: OK
Hardware autodetection : OK
Setting Internet connection with Roaring Penguin PPPoE ADSL: OK
Downloading locale archive and setting locale to sl-SI: OK
Saving personal settings to pup_save file in 'psubdir' directory: OK
Rebooting and loading saved settings: OK

Barry, this was very effective bug cleansing. Thank you.

Leon, I forgot all about your 'chooselocale' bug report! It fixed itself! :-)

A forum thread to report bugs:

3.01 is also at www.puppylinux.ca

I'd like to suggest that you put an updated README in the ibiblio directory that describes the available files and what they're for.

Tremendius release Barry
works beautifully so far
All my queriesd got answered


I cannot get CUPS to work . My previous CUPS printer that worked in 2.17 does not work. When I try to install the printer, CUPS asks for user ID and password. Root and woffwoff is rejected. ???

It is woofwoof

Lobster (ed.jason<at>gmail.com) 
Was able to create Linux Tmxxine 3.01 "Prism"
Puppy 3.01 Final + Ezpup3 + OpenOffice 2.0.3 + Graphics programs
using the onboard remaster
inode error messages - gone :)

Many thanks.

I successfully upgraded my Puppy 3.0 to 3.01. Everything works!
So great that i feel in-love with this puppy new release. :-)

Thanks to you Sir Barry and the Puppy Team.

I forgot to mention that my HP LaserJet 4P works in a fresh and in an upgraded pup_save file:


My tg3 network driver wouldn't load with 3.0 or 3.0retro or 3.01beta, but works with 3.01!

I do like this Puppy!

I like elegant and efficient design.

I managed to fumble the installation, but got it right the second time, and I really don't know of any significant issues affecting me.

Of course we are all looking to more good choices and implementation of package handling so individual needs can be easily met.

Thanks, Barry

gust (gust_vn<at>yahoo.com) 
install seamonkey extensions error : unexpected error - 201


I think that all people having NVIDIA GC, cannot start xorg from the first run, and that was my case.

I tried it on my HP laptop having v2.14 on it, configured and working perfectly, the auto-update of the pup_save file, jammed the machine so that the old config was lost and I had to reinstall it again.

The ability to choose the pupsave to load, is not working when there is only one file found. The updating starts without warning, unfortunately...

I think the best solution in order to avoid the "unvoidable mess" due to a human mistake/or proprietary obstacles, is to hard code the version# in the names of all the version's related files. I tried it on a machine having different versions and pupsave files. The user's data are to be kept on a separate file. Regarding updating to the newest version it must be a choice btwn overwriting or creating either an updated file or just a new one.

In all cases to use the 3.01 with th Nvidia proprtry drivers I had to install them from scratch again. (it couldn't be auto-upgraded anyway).

Is there a difficulty in implementing this separation of versions?

thanks Barry and to all of you


I agree that a user's confirmation before upgrading pup_save file would be very useful.

I think that there is no need for hard coding the version# in the names of the version's related files. Since Puppy 3.01 there already is an option to have all version's related files in its own directory.

These are settings from my menu.lst:

# Boot Puppy Linux 2.17.1
title Puppy-2.17.1, idehd, /p2171
rootnoverify (hd0,4)
kernel /p2171/vmlinuz root=/dev/ram0 PMEDIA=idehd psubdir=p2171
initrd /p2171/initrd.gz

# Boot Puppy Linux
title Puppy-3.01, idehd, /p301, psubdir=p301
rootnoverify (hd0,4)
kernel /p301/vmlinuz PMEDIA=idehd psubdir=p301
initrd /p301/initrd.gz

S. Joanou 
I installed to vmware and then from there to my 2Gb USB thumbdrive. Then I booted the machine to the thumbdrive and set up wifi wpa-psk, network (static), sound, screen resolution, etc. Then shut down. IT asked me if I wanted to save my data encrypted. I chose strong encryption.

Bottom line: everything worked flawlessly :-)

Great job!

WN2A (wn2a at qsl.net) 
Just Amazing... very worthwhile!

Nice Job!


Thank you very much. I confirm that 'psubdir' is working perfectly (only just one level deep, as designed). The only 'hic' is when there is another older save file in the same dir alone (it can happen for some reason), and updating runs freely without any warning.

There is another problem with (3d) with xorg 7.2 noticed on older machines (this problem is common to other distros too). I didn't test much to know the reason (I think someone mentionned it on previous posts).

This is a new snappy build of Puppy. :-)

However, some rough edge* seems to be present in humongous initrd booting (it must be the init script changes). It's easy to simulate net-booting via a Grub menu in frugal install... Thanks!

* init fails to find then mount pup_301.sfs, which is already in the humongous initrd together with zdrv_301.sfs. I used the makecpioinitrd to build the humongous initrd.

Since upgrading to v3.00 I can no longer listen to BBC Radio (missing cook.so). I eventually discovered that I needed to install pupget package xine-extra-codecs-1, but this has missing dependency xine_lib (not an available package). Does v3.01 fix this? Apart from that it all seems good.

Resizing encrypted pup_save files 

The shutdown script has a warning that encrypted pup_save files cannot be resized. However, the actual resize script (in the Utilities menu) does not know about this limitation. You find out when you reboot and the file hasn't got bigger.

This is something that is often asked for, so although I don't want to add more than absolutely essential at this stage, I have added encrypted pup_save resizing to the 'init' script. I have just tested it, works fine.

Would it be possible in future to release the bug fixes for the alpha and betas as a "service pack" so that they can be used while testing between betas/alpha?

I'm one of those who have reported that encrypted save_file hans't been resized. Sorry if I have reported things you already knew, but I don't recall seeing any message(s) at shut-down warning that the file won't be re-sized.

Has that message gone walk-about?

psubdir bug fixed 

Whew! I thought that I had got it right this time, but Leon reported that it still isn't in 3.01beta. I couldn't see anything wrong in the code, and it took all morning, until eventually the penny dropped. There was one tiny thing wrong.

What is Your intention concerning the right place for additional sfs files like openoffice?
Right now puppy 301b recognized additional sfs files only when placed in root directory even with psubdir parameter is accepted for all other puppy files. Despite the fact that the additional sfs files itself contains often the same data, but with the puppy version in the filename it is linked to only one puppy version.
So it make sense to place it together with the correspondend puppy files in the same subdirectory and search only in the psubdir directory - or at least checking also psubdir path for additional sfs files?

I have left the extra sfs files at '/'. Reasoning was that you can choose with the Boot Manager, also they tend to need to be required by different installations of Puppy so avoids duplication.

Testing... Sending comments is failing... Maybe the content is not beign handled and is causing an error?

Part 1 ...

PSUBDIR processing seemed suboptimal in 2.1x if not bugged, and moreover it does not work at all for me in 3.00 nor 3.01.

I mount /boot from /dev/hda1 (a small partition), and / from /dev/hda2. I want to place all the Puppy files together in /boot/puppy-(version) eg 217. Puppy 2.17 cannot handle this. However 2.17 does work if I move the .sfs files to the parent, /boot. Puppy 3.xx cannot even handle this workaround.

The problem seems to be in the init code at 'FND_PUPXXXSFS="`find /mnt/data -maxdepth 2'... I think it would be better to have a parameter that tells init that the kernel, initrd, and all sfs files are somewhere, and have init just look there, and not search all the partitions. Perhaps this could be an optional extra parameter.

More coming...

Part 2 ...

BTW extra sfs's do not need to be at /, as you have mentioned lately. Eg, as per above, my openoffice sfs is in /boot. (See above: this is the top-level directory of a partition, but its not /)

FYI: Here is part of my menu.lst from grub.

(... coming in part 3, unless this is what is failing to be accepted by this comment facility)

Part 3 ...

title Puppy 301 Linux - Boot into a New 301 Setup - Fails
rootnoverify (hd0,0)
kernel /puppy-301/vmlinuz ro root=/dev/ram0 initrd=/puppy-301/initrd.gz ramdisk_size=93952 psubdir=/puppy-301 pfix=ram
initrd /puppy-301/initrd.gz

title Puppy Linux - Boot into a New Setup
rootnoverify (hd0,0)
kernel /puppy-217/vmlinuz ro root=/dev/ram0 initrd=/puppy-217/initrd.gz ramdisk_size=93952 psubdir=/puppy-217 pfix=ram
initrd /puppy-217/initrd.gz

title Puppy Linux - Normal Boot
rootnoverify (hd0,0)
kernel /puppy-217/vmlinuz ro root=/dev/ram0 initrd=/puppy-217/initrd.gz ramdisk_size=93952 psubdir=/puppy-217 PDEV1=hda1 PMEDIA=idehd
initrd /puppy-217/initrd.gz

(If this posts ok, then either the facility has fixed itself, or perhaps it has a message limit.)

I am getting caught be the security image timeout here. It must be ridiculously short. What a stupid bug. Cant it be fixed?

getnikar, hopefully the graphic image timeout problem will get fixed. In the meantime there is a message on the right side of the screen telling you how to work around it.

Puppy can only be one-folder deep.

This has various errors:
kernel /puppy-301/vmlinuz ro root=/dev/ram0 initrd=/puppy-301/initrd.gz ramdisk_size=93952 psubdir=/puppy-301 pfix=ram
initrd /puppy-301/initrd.gz

get rid of the root= and ramdisk_size= parameters.
get rid of the leading '/' in the psubdir parameter.
why is initrd specified twice?
pfix=ram is not required.
So, this is enough:

kernel /puppy-301/vmlinuz psubdir=puppy-301
initrd /puppy-301/initrd.gz

"why is initrd specified twice?"

Good question :-). The entire boot setup is like this because its hacked from how 2.17 worked, which is hacked from how 2.16 worked ... etc etc back to 2.01 or so. Thanks for the update. I shall test it shortly.

cpio bug 

Puppy 3.x has initrd.gz as a cpio archive, not a ext2 filesystem, which requires the 'cpio' utility to unpack and repack, as described in the 3.00 release notes.

However, this has revealed a bug in the cpio used in Puppy. The problem is that some versions of cpio do not handle symlinks properly when building the initrd.gz file. In Puppy Unleashed, in the 'boot' folder, I have a version that works properly, and running this with '--version' shows that it is version 2.5 (and it is dated 2002).

The current Puppy has cpio version 2.6 (dated 2006), but I have just found that it does not handle symlinks properly, and when I tested it, it created a initrd.gz of 11MB! -- it converted all the Busybox symlinks to copies of the 'busybox' executable.

I don't know why the later version is wrong, whether it is due to a configure option. I think it was compiled in T2. Anyway, I have rolled the PET package back to the correct v2.5 one that works. Interesting, the one that works is 57KB, the one that doesn't work properly is 89KB.

Note, the kernel docs do warn about this problem with certain versions of cpio. I just checked the package in Slackware 12, and hey, they are using v2.5 ...hmmm.

i found that out as well Barry when i opened up the initrd so I could eliminate the fsck routines which were annoying me
Glad you will be taking it back to 2.5 to match slackware as it saves me pulling it down :-)

Roaring Penguin PPPOE 

Hmm, I forgot to upgrade to the version 3.8 that Leon compiled. See his forum post:

...will do that right now.

There's a forum thread for reporting 3.01beta bugs:


Please check also a problem when using 'psubdir' boot parameter and some other problems that I described on the forum.

f.s. check at bootup improved 

The 'init' script does a check of ext2 and ext3 filesystems. The code in 3.01beta is a bit awkward and I have now improved it. More concise output to the screen, in keeping with the brief messages in the puppy3 series.

thanks barrt
i hate all thatr verbosity that it is throwing out
still that is the only problen i have with 301 - and its not really a problem just cosmetics

Only change of cosmetics or also a solution for the booting errors Lobster and jcoder24 reported - and are the same with me?
Every time booting a frugal installation on a fat partition when loading (even a new) saved puppy file f.s.check starts and a lot of error messages concerning "inodes" and fixing file errors are displayed.
After that Puppy is running fine - but when rebooting allways the same error messages comes up.

interesting yes I just created a completely new pup_save and it exhibits exactly the same behaviour.
The first time it boots - no problem - no errors reported
then I changed to icewm and deleted the desktop icons i didnt want and rebooted and - error messages concernig inodes and fix=yes and that repeats every boot since
I have repeated this process 3 times now and its consistnet so something is awry with the fschk apparantly

Puppy 3.01beta 

Get it from here:
http://distro.ibiblio.org/pub/linux/dis ... -3.01beta/

This is a bug-fix release for 3.00. It only has bugfixes and tweaks specifically mentioned in these Blog posts since 3.00 was released. If you have some other problem with 3.00, then 3.01 is no different.

Note, 3.01 has Gaim from Puppy 2.17.1, not Pidgin.

If this beta seems basically okay, I'll bump it up to 3.01final. Then I'll upload some updated PET packages and Unleashed-core package. Will also upload the 3.01retro.

Thanks, Barry. We can all see just how hard you are working on the Pup. Isn't there always an 'however' ! It's far too big!

amadus (amadus<at>online.fr) 
Good work Barry and bravo to you and the whole team.

I've been following the evolution of Puppy since it's earliest versions (0.7 or less) I've always believed in it.
Lately my 'working' laptop went out of order, and all the other linux versions on it including Puppy.

So I had urgently to bring to life again my old laptops and desktops, those belonging to different generations of the 20th century. 'Puppy was there!' to give them life flowlessly in the 21st century.
Fortunately, my brand new laptop joined the list, so now I'm able to identify what is the most versatile common behavior I wished to see, and what was meant to help and but came in the way.

I used a live CD, usbkey, usbflash on a generic usb-multireader,frugal install (auto and manual), and normal hd install.
I tried v1.01,2.14,2.16,3.00.

v1.01 opend all the doors.
v2.14, 2.16 and 3.00 were stuck when xwin was called. no way but a reboot. Starting with XVesa was imperative, and tweaking the xorg.conf manually. (I'm summarizing here, bcz, the behavior wasn't always consistent).

The Auto-'things' are wonderful when they work and when we really need them. But sometimes I prefer to decide.
My idea is that whenever it's the only possible, better, secure way, it's ok to auto-it. Otherwise please be gentle ask me if I agree.
(nowadays, it seems it's a 'must' to auto-update your machine for xxx reasons, you wanted it or not! ask M$ & co, they're experts!...?.

*** my wish start ***
"I wished that puppy was just an engine, that reads the machine profile, and access whatever user-data-storage he might be asked for".

At first boot: WALK... ( recognize what's there, save it in a machine-profile).
next boot : RUN! (read the machine profile, probe/load/exec *only* what is needed).
in both cases, let me mount my data, wherever it is.
I went through the boot process, scripts and so, compared the different versions, and made some necessary and vital changes:
I *eliminated* the version auto-update. It 'booz-ied' my previous pup-save and jammed the machine. (2.16->3.00)
I *eliminated* the lookup for different files that doesn't hold the same version number.
I changed to get Xvesa on the first start (probing some machines wasn't helpful).
I wanted to go further, but I decided to read some posts before proceeding, if by chance...

Sorry I was long, only enough to show the context.


(by the way Barry, it happened that this page is the first one I read when I switch on... flattered? 'encore bravo' in all cases)

I have wish/suggestion,
I want to boot full instalation of puppy from usb. I've tried everything, and its not working. I think kernel needs modifications. Error i get is: VFS: Cannot open root device "sda1" or unknown block (0,0). Please append a correct "root=" boot option.
Even rootdelay= doesnt help.
I dont care if my usb flash disk will die, that thing wasnt build to last anyway, point here is mobility and not using pup_save and running puppy in ram, which gives more free ram.

David Freese (w1hkj<at>w1hkj.com) 
Cannot get 3.00 or 3.01 to recognize ATI video system. 2.17 works just fine. Is it possible to load the ATI binary driver for use with 3.01? Can I do that after booting 3.01 in a text mode session?

I am working on a release of an amateur radio emergency communications ISO based on Puppy and special digital mode sound card programs. Moving the ISO to the 3.0x rev of Puppy is very desirable.

Thanks for your time.

Dave Freese

Testing Aufs 

See recent Blog post.

Andrei posted a modified 'petget' script. I found that one line in petget is wrong:

if [ $PUPMODE -eq 3 -o $PUPMODE -eq 7 -o $PUPMODE -eq 13 ];then
if [ "`df | grep '^unionfs' `" != "" ];then <<<<THIS LINE IS WRONG<<<<<
#if snapmergepuppy is running, wait until it has finished...
while [ "`pidof snapmergepuppy`" != "" ];do
sleep 1

It should be:
if [ $PUPMODE -eq 3 -o $PUPMODE -eq 7 -o $PUPMODE -eq 13 ];then
if [ "`lsmod | grep '^unionfs' `" != "" ];then
#if snapmergepuppy is running, wait until it has finished...
while [ "`pidof snapmergepuppy`" != "" ];do
sleep 1

'lsmod' is tested to determine if unionfs.ko is loaded. If not, it must be aufs.ko. This is fixed for 3.01.

Hey Barry is this something you could use...???


Drivers, Network Wizard updated 

tempestuous has posted various upgrades here:

I have upgraded to the patched hostap drivers.

wag-profiles.sh upgraded. The Network Wizard pkg is now net_setup-3.01.

Have upgraded to the patched snd-hda-intel.ko driver.

e1000 driver updated.

Note, I was thinking of adding Pdrive to 3.01, but v0.10 crashed when I clicked on an entry in the table. Another note: I don't see why the last column is there, can't that be dropped? Otherwise, an exciting new project and a contender for inclusion in the official Puppy live-CD.

I really have to upgrade to version 3 SOON. It sounds like there are some issues with some scripts. I'm sorry for that, but I'll follow...

Pdrive alternative to Pmount, OGG fixed 

Zigbert has upgraded Pdrive to v0.10:

gray has reported that the OGG plugin for Xine/Gxine does not work. I ran 'ldd' on the plugin and found that 'libtheora.so.0' is missing. Sigh. I'm getting really tired of these extra dependencies that I have to keep adding to get Slack packages to work. Be warned, I might get fed up and Puppy4 will be back onto everything compiled in T2, from source, with just the minimum dependencies needed, no more.

Would you be better off streamlining integration of DEB packages...?


Did you ever see Dougal's Hotpup? It places icons on the desktop for each partition/device. Detects any added or removed device. Very newbee friendly, quite nice. Though, Dougal seems to have escaped the kennel. Yes, T2 keeps looking better.

No, Dougal is still around, he has just become quiet. My reply to one of his posts in this Blog is the cause I think.

PupCtorrent icon 

It was reported that the icon was missing for the PupCtorrent menu entry (see Internet menu). Fixed.

PupCtorrent is a GUI for ctorrent, using gtkdialog -- so many Puppy-authors are going for Bash scripting and gtkdialog for the GUI -- a great light-weight combination! PupCtorrent was created by our forum member 'plinej' and is currently version 0.7, but I have changed it to 0.7-1 with this icon-fix.

Hey, I just looked on the forum, and it is now up to version 0.9! Okay, have downloaded and updated. Forum thread: http://www.murga-linux.com/puppy/viewtopic.php?t=14954

The pidgin also not working in the internet menu. But I can still use Meebo.

I am using Live CD Puppy Linux 3.00. This Linux distribution saves my laptop with a destroyed hard disk. I can still use my laptop for some computer works.

Thank you Sir Barry and the Puppy Team.


just checked and pidgin runs in my menu maybe you could try running from the command line and see if you get errors just type pidgin and enter

also try running fixmenus at the commandline and it could be that ezpup3.0 fixed my menu entry I didn't think of that at first

The Flash saga continues 

I have written about the Flash player recently in this Blog. Puppy 3.00alpha and/or beta had the most recent Flash player plugin for SeaMonkey, but it is buggy, so for the final I went back to the old Flash7 player.

Puppy 2.17 has a slightly-less-than-recent player, which is 6800KB. The latest is 7800KB. The Flash7 player is 2000KB. Huge size differences!

The Flash7 player handles youtube.com, however 'Crash' reported in the 3.00 bugs forum thread that movies.yahoo.com does not work.

The latest Flash player, at least the one I used in 3.00alpha/beta, is very buggy. I have already grumbled about that. But here's some more: <grumble>they've added 1MB more code, yet it's worse than before! No way can they write that much code. They must be "improving" the product by throwing in libraries from elsewhere</grumble>.

Anyway, the one that does work is the player used in 2.17, so I've now adopted that for 3.01. I tested it on youtube.com and movies.yahoo.com and it works fine.

Give it a try on Disney.com and some other popular e-destinations.

oberon85 (oberon85<at>gmail.com) 
I have been using the latest flash from labs.adobe.com, released Oct 1? and have not had any problems under 3.00....

Just thought you should know.

I've never checked this with Puppy's Seamonkey as I rarely use it, but the known trick to tame Flash in Firefox is symlink the plugins to /root/.mozilla/plugins. I guess it will work the same way in Seamonkey.

Changing the topic for Mobile Internet Devices, this is a good read for developers: http://www.linuxdevices.com/news/NS8166710404.html

Kernel 2.6.20 is also used in the new Splashtop for (near) instant-on Asus PC: http://www.splashtop.com/index.php

Have you seen the upgrade of Stardust gtk2-theme. It views headers of lists and trees much better.

Distro bashing 

I have noticed recently a war of words going on with someone who bad-mouthed Puppy. Sigh. If you think someone has done Puppy an injustice, it is usually better to just leave it. People often post superficial assessments, that's just the way it is.

It reminds me of my recent experiences using Slackware 12. As I have used Slackware 12 packages in the latest Puppy, I have also installed Slackware and have had occasion to use it a few times. Each time I have breathed a sigh of relief when it's over. There are so many niggles, but arguably any negative comments I make would be superficial as Slackware is not one of those distros that aims at being sleek and fully-configured for the newbie out-of-the-box, and needs tweaking. I kept hitting obstacles and started to make a list, but have discarded it.

For example, I plugged in my USB pen drive as I wanted to transfer a file via the drive. Great, automatically recognised and a window asks if I want to mount it, Kongueror opens -- but then an error message pops up with something about "HAL permissions", and I can't access the contents of my pen drive -- no info how to fix it. I'm running as root, so permissions should not be a problem. I guess I would have to learn how to modify HAL settings.

Another example, a really stupid niggle. I dislike Konqueror as a file manager, so opened Thunar -- to my astonishment, it had the same icon for folders as for files, so I was unable to tell the difference.

I can go into any of the major distros and find niggles, even major show-stoppers. It has always been my experience that Puppy is easier to use and has less niggles than other distros. But then, take that comment with a grain of salt, as I am of course intimately familiar with Puppy.

What I'm trying to say is, try to stay away from comparing with other distros, or getting drawn into heated debates. Sometimes it is appropriate to make a statement when something wrong is posted, but I think mostly it is best to leave the other distros alone. Ditto when someone bad-mouths Puppy, don't get drawn in and heated up.

If you are reading this and wondering if Puppy is for you, don't believe what others have written, try it yourself. Not just for 5 minutes either - if you're a distro-hopper, hop on.
If you find a bug or even just a niggle, let us know -- one thing about the main forum, although it has critics it is one of the most responsive and helpful of all Linux forums.

Changing the subject, for those hanging out for 3.01, I think I'll release a beta in a day or two, then the final soon after.

Yes, those are sure time-wasters, but when the correct information matters, it is difficult to hold back. I guess it's over for now.

In the middle of it all, desktoplinux posted a comprehensive review of Puppy by Howard Fosdick:

What a week!

I've tested about 6 diferent linux distros in order to replace win98 in our company, and finally went for Puppy, short, quick and productive.

I'm now tring to push some local schools to use it, instead of proprietary OS.

Great, Great work Barry.

Forget those blokes who waste their time trashing other Linux distributions. I chose Puppy Linux because it works for me.

PupScan fixed 

PupScan is a hardware information utility that I wrote many Puppy-versions ago (look under the 'System' menu), and it has always had a bug. Sometimes when the "USB information" button is clicked, PupScan crashed. This was reported recently in the 3.00 bugs thread in the forum.

I have now fixed it. Clicking the button displays information about plugged-in USB devices, but if nothing is plugged in then PupScan crashes. Under normal circumstances I never got this condition as I use a USB mouse, however today I just happened to be using a PS/2 mouse and no other USB devices plugged in and got the crash, so was able to deduce the cause and fix it.

Aufs or Unionfs? 
If anyone thinks they might have a bug that is related to Unionfs in 3.00, as shankargopal posted here: http://www.murga-linux.com/puppy/viewtopic.php?t=22508, then you might like to revert to Aufs and see if that makes any difference. Andrei has posted instructions for doing that here: http://www.murga-linux.com/puppy/viewtopic.php?t=21336

Note that Unionfs2 as used in puppy3 is very verbose and outputs lots of meaningless messages, that appear to be informational not error messages (open a terminal and type "dmesg" to see them). They are a bit disconcerting and some people have posted them to the forum thinking they may be bugs.

The Unionfs developers are very active, and probably soon I will apply the latest kernel driver patch and recompile the kernel. Not for pup 3.01 though, as this is to be a basic bug-fix release, coming Real Soon Now (does anyone know the name of the journalist who was famous for saying "Real Soon Now"?)

Hi Barry,

Maybe you mean this guy?


BTW look forward to your next aprovemant with the kernel patch for a new unionfs. Keep up to the good works!

John Wetterau 
Jerry Pournelle is his name, I think. Thanks again for a terrific job on Puppy.

Yes that's it! :-)
You guys are getting on in years too. I used to read Byte and Chaos Manor...

'save' button fixed 

Well, probably anyway. For multisession-CD/DVD, I found out what was wrong with the 'save' icon on the desktop. The script is /usr/sbin/savesession-dvd. Haven't had a chance to test that it works -- will do that later today.

Note to rarsa: if you intend to work on the /usr/sbin/puppyinstaller script, I made some changes to it to accommodate the custom naming of the pup_xxx.sfs file, so you will have to get the latest from me.

Regarding the 'retro' Puppy, although the latest Puppy is built with an older kernel, it still has Xorg 7.2. This question was asked recently. It's a problem as some people have reported problems with video in 3.00 whereas video worked okay in earlier puppies. Puppy 2.17.1 has Xorg 7.0, and I know that 7.2 has some differences when it does the auto-probe (the Xorg Wizard uses this feature). A later version does not always mean better in every respect, as I have discovered many times. However, we can't go back, as many Slackware packages will be compiled against the 7.2 library files and older library files may break the apps. So, we have to live with it and try to resolve any issues, perhaps with updated video drivers in some cases.

WN2A (wn2a<at>qsl.net) 
Thanks for pointing that out about Xorg. That explains why my Diamond card didn't like 3.00 (or 2.2 either) but all the other cards (ATI, no-name,etc) are fine with with 2.15 to 3.00 inclusive.
Have already upgraded to 3.00 in 3 PC's. The advantages outweigh a minor nit.
WN2A :-)

Barry, thanks for fixing the Save button. If it's just a matter of replacing the bad file with the new one, I'll be happy to test it.

Ted Dog 

interesting who is using puppy. :SURPRISED

looking a fixing DVD/CD multisession boot problem ( my new laptop still has that issue ) I reviewed gujin new release, it works (sort of) multisession does boot on problem laptop but kernel loading is freezing.

maybe someone can contact Etienne Lorrain and have him spin a puppy verion

I have tested the save icon, it works fine. I tested with a CD-R, kept clicking save, save, save, save, etc., until the CD was full, and it then migrated to a new blank CD-R. That's when a new bug emerged -- the zdrv_300.sfs was missing from the new CD -- I'll fix that next. Otherwise all was ok ...well, there may be an issue with too much getting saved at each session, rather than purely the differences from previous saves -- will check that out also.

Custom name for pup_xxx.sfs file 

Those who are into creating their own custom puppies will appreciate this. I have been working on the remaster-CD script and it got me thinking about how customised puppies can co-exist on the same PC.

For frugal hard drive installs we now support installing into individual folders, so each puppy can be kept separate.

However, booting from live-CD is a problem, as at first shutdown as well as asking if you want to create a 'pup_save' file, Puppy also asks if you want to copy the pup_300.fs and zdrv_300.sfs files of the CD to the same place on the hard drive as the 'pup_save' file. This greatly speeds bootup time, and it also frees-up the CD drive in low-RAM PCs. However, if you want to boot different customisations of Puppy, all with the same version number, there is a problem.

The solution is to customise the file, for example 'pup_300ce.sfs' or 'pup_300ce-beta1.sfs'. The remaster script now allows you to do this.

The way it avoids clashes is very simple. Say you have created a customised puppy with 'pup_300ce.sfs' on the CD. At first shutdown you get the usual offer to create a 'pup_save' file and to copy the 'pup_300ce.sfs' and 'zdrv_300.sfs' to the hard drive. At bootup Puppy will only look for a file on the hard drive with the same name as that on the CD, so other files, like 'pup_300.sfs' or 'pup_300tiny.sfs' will be ignored.

Well, I've done the coding for this, it was fairly simple, but haven't tested it yet.

does that carry over to the naming of the pupsave?
not to ignore certain pupsaves but to prevent unintentional upgrading or downgrading

Great,This is what i am talking about!
For Asian, If you say people is dog, You will get kill.
We all love your job with great respect.

Great. One less hack I have to do myself when Pizzapup season hits :RASPBERRY

wolf pup 
when puppy 3.01 is released, do the devx and the kernel src sfs files need to be downloaded again, or just named to _301.sfs?

Barry Kauler 
The kernel_300.sfs can just be renamed. Ditto for devx_300.sfs although I may tweak it and release a new one -- dunno yet.

pup_saves ...no changes there. If you have multiple pup_saves you will always be asked which one you want to use. Having different custom puppies is not a version upgrade issue.

guess i'll have to start giving my pupsaves better names then :-)

Lobster (ed.jason<at>gmail.com) 
Because I throw the OS about so much (at the moment KDE and Ezpup are in there) I work from CD until something gives - one experiment too far

Then I boot with puppy pfix=ram
Quite oten I move between puplets or versions of Puppy and they 'upgrade' or otherwise effect each other

So . . . this innovation is very welcome :)

While you are improving the multiple-version capabilities, it would be helpful if the booting puppy version number were included in the header for the list of available pup_save files. When testing new versions it would help in matching up version-specific pup_saves to the version being run.

The actual pup_xxx...sfs file name (without the ".sfs") might be even more useful in the pup_save list header.

rerwin wrote:
The actual pup_xxx...sfs file name (without the ".sfs") might be even more useful in the pup_save list header.

I agree, this would be useful.

I would also suggest that a user confirmation should be required before upgrading pup_save file to prevent mistakenly choosed pup_save from pup_save list.

amadus (amadus<at>online.fr) 

I agree about not 'auto_ing' things when ther is a possibility of misbehavior. (I went through this)
(2.16->3.00... oops! it was too late, the machine jammed... reboot, byebye 2.16 pup_save file, it was a one way ticket!...)


CUPS "fixed", work on multisession 

Those who have followed the CUPS saga on this Blog will know that I couldn't get the Slackware 12 CUPS package to work, so for Puppy 3.00 I dropped back to the CUPS, ESP Ghostscript and Gutenprint packages from Slackeware 11. The problem with this though, is it is an older libcups library and this breaks some Slackware 12 packages.

Last night I attempted to get the Slack 12 CUPS working, and eventually gave up. I was able to choose my printer in the web interface, everything was fine, but it would not print, with the message "Printer not connected; will retry in 30 seconds". I studied just about every Goggle hit, and found many people experienced this problem when upgrading from CUPS 1.1.x to 1.2.x, same situation as ours, where we are going from v1.2.23 to v1.2.11. It seems that some never managed to fix it. The problem seems to be something to do with file owner/group/permissions, but I spent many hours fiddling and it still wouldn't work.

Anyway, this morning I resorted to giving /dev/usb/lp0 permissions of 777, meaning that I made it world readable and writable, and finally had printing. It's a cop-out though, not at all satisfactory. I also changed /dev/usb/lp1, /dev/lp0 and /dev/lp1 (the last two are for the parallel port). So, now I have upgraded to the CUPS, ESPGS and Gutenprint packages from Slack 12, also have put in the Foomatic-rip package.

Oh yeah, one more thing. When choosing a printer it asks for a username and password, and I have been unable to configure /etc/cups/cups.conf so that it does not ask for this. You need to enter "root" and "woofwoof", and I have put this information in a popup info-box.

There was a bug report about the 'save' icon on the desktop for multisession CD/DVD, and I started by examining the rc.shutdown script, and made various improvements. There was one situation where a dialog box could get you into an endless loop, another situation where it shutdown without saving without really telling you why. I'll do another test of these changes, then get onto fixing the 'save' button.

" It's a cop-out though, not at all satisfactory."
" You need to enter "root" and "woofwoof", and I have put this information
in a popup info-box."

Obviously a case of this:


" Not happy Jan"


seems the forum is really slow(not loading at all but there is no error message) right now 7 :41 am eastern us....

puppy is now above linux mint in the 7 day period at position 7 with 1052 hit/day could it be that the forum is geting overloaded? (i'm just gonna leave my question at that cause it is allready speculation :-)


" You need to enter "root" and "woofwoof", and I have put this information in a popup info-box."

Would this work for those of us who block popups? Could it be coded into the page itself?

No, it's not a popup in the web browser. It's a separate window using 'xmessage'.

Hi Barry

Does the foomatic package contain foomatic-gs wrapper?.I think I need these along with pnm2ppa driver ccompiled in, to get my HP710C printer to work.

Great Distro Thanks.

Yes, it has foomatic-gs. I think that I left all of the foomatic pkg intact.

Which version of Puppy to use? 

I recently read a comment in a mini review of Puppy to choose version 2.17.1 rather than 3.00 if you have older hardware. Actually, it's not quite that simple.

The latest 3.00 should work just as well on old hardware. My oldest test system has a Cyrix 6x86 CPU (equivalent to a '586' CPU I suppose) and 128MB RAM, and I always make sure that Puppy works on it -- which 3.00 does. The latest Puppy should also work with less RAM.

However, some people have found that an older version of Puppy works for them and newer versions don't, or not completely. In some cases later versions won't boot, or network driver won't work, or sound, etc. Mostly this is releated to the kernel version and the drivers. The version of Xorg may also be an issue for video. In some cases a later kernel drops support for some older hardware -- or so we surmise.

What I have done with 3.00 is also released 3.00retro that has an older kernel, so hopefully someone who has problems with the latest kernel can try the retro and it may fix their problem. That is one strategy. Currently the retro kernel is (used in Puppy versions 2.12 to 2.16), and I plan to upgrade to the latest in the 2.6.18 series which is -- will do this for Puppy 3.01.

Another thing to consider is that 3.00 is the start of a new series. It is a major upgrade from puppy2, so there are some teething problems, in most cases minor and not even encountered by the majority of users. Many seasoned Puppy-users are waiting for the 3.01 release before upgrading! Fair enough. Puppy is usually quite easy to upgrade, so if you do have any issue with 3.00, just download and boot the 3.01 CD when it becomes available.

So, I am hoping that noone will have to be stuck with some old version of Puppy and will be able to enjoy the features of the new 3.x series!

Barry, G'day from Dallas. On the subject of which pup to use I've been a lurker. Time to jump in. I tested the alpha and betas, nice... but my h/w could only boot at USB 1.1 or CDROM. Since the pfix=usbcard isn't in 3.00 I'm hosed. 2.17.1 is where I'm at. I've been using Puppy for my OS since my circa 2000 Vaio HD controller burnt up in an experiment (installing Ubuntu 7.04 to a 6G HD for a 128 Meg Dell lattitude). All that is to say, my Sony Vaio (USB 1.1) with DLink (Cardbus DUB2) USB 2.0 with 2 Gig USB Stick, is stuck at 2.xx until kernel scanning of pup_save via pcmcia returns. Anyways, not a gripe, long live Puppy! Looking forward to 3.01...

Is the same Xorg update used in both retro and normal v3.00s? If so, that would explain my video woes and take the blame off of the kernels.

Reference: http://www.murga-linux.com/puppy/viewto

tony (tony<at>veronicathecow.co.uk) 
Hi Barry, perhaps this is part of the reason people might use the older version? This is a copy of a post I put in the "3.00 Bugs post"

Not sure if a bug but 3.00 final with 128mb or ram loads seamonkey in 55 seconds on PIII 650Mhz.
However with and extra 64mb ram bringing it to 192mb RAM it loads in just 10 seconds!
Any thoughts?
As always, many Thanks

Sounds like 128mb isn't enough for Puppy to load completely to ram. I don't know if it has changed, but it used to be that Puppy would only load to ram if there was enough to leave 50mb free. In the case of a ~90mb Puppy, that would mean ~140mb ram.

Now that Pizzasgood mentioned it, Barry and/or experienced Puppy users/devs, is there a reasonably simple way to check that all the core Puppy files (excluding the save file/sessions and .sfs addons) are loaded into RAM so that the LiveDVD/LiveCD would be able to be removed and/or so one could guestimate the best size for a swap partition/swap file?

For some reason I can't now remember, I never moved on to 2.17. And because gxine for me is unacceptably flakey in 3.00, I probably won't move on to 3.00 either.

It's almost as if the improvements are getting so esoteric, from the user's point of view, that they weigh little in the decision to upgrade. Who cares if the small browser is dillo or netsurf? Who cares if initrd is a cpio archive, or whatever it was before (the cpio archive broke the initrd editor dotpup that someone had cooked up, so where's the advantage)? While on the other hand, earlier improvements, like encrypted pupsaves, were eagerly awaited (by me anyway) and I would put up with other shortcomings of a new version to get them.

I would certainly upgrade if a more bug-free version came out, or if I could have dmcrypt or loop-aes encryption, or enigmail, or a newer version of gnumeric. Or maybe a change to a less-bloated browser if it's got the features I need - but then do I lose the possibility of having enigmail? Anyway, until then, I am content with 2.16.

I don't want to discourage the experimenting. It all pans out in the end...

To check if you're running in ram, try running [b]df -r[/b] and see if there's a tmpfs partition using 90-100mb. If so, it's in ram.

"(the cpio archive broke the initrd editor dotpup that someone had cooked up, so where's the advantage)"

Yep, using cpio would do that. I guess I'll have to make an updated version some day. On the plus side, my fingers are crossed that using a cpio archive won't cause as many stupid sizing issues as I was having with the filesystem images.

As far as the point, I don't remember all of them, but there was something about a cpio releasing the ram after you're booted. Though I don't know if Barry utilized that (didn't think to check). Anyways, it's only a couple megs.

What's interesting to me about 3.00 is it has updated system libraries. That becomes relevant when you want to use binary packages compiled for another distro with a more recent Glibc. I probably won't switch for another week or two though. I doubt my poor save file will last much longer than that anyways. It's to the point now where sometimes starting an application takes a very long time for no apparent reason (no CPU or drive spikes even), and random shutdown freezes...

Not blaming Barry or anything. I'm just really really hard on my system :RASPBERRY I run a save until it drops, then I either update to the latest Puppy or build a new Pizzapup. Download, compile, repeat...

Actually, that's exactly why Puppy is perfect for me. I can make backups or do a fresh install very easy. When I bork things, I don't screw up the whole machine like with a conventional install.

Well, it must be good to try the new 3.00 and create a basic unleashed build, but there seems to be a problem in the createpuppy script (the file commands seem to follow the filenames in the new kernel, and am using the retro kernel). Could you check on this Barry, please?

Ah, yes, building for the retro kernel is a bit of a problem. You have to be running Puppy with the same kernel. So, you would have to bootup with 300retro CD or Puppy 2.16.1 or earlier CD.

I think it would actually be helpful if there was an up to date page somewhere giving an idea of "system requirements" for Puppy. I think there used to be one, but I can't find one anymore.
So it could say - minimum ram for loading Puppy into ram
- recommended specs to run from live cd
- recommended specs to run full install (Also, is this faster or slower?)

BTW Pizzasgood - the zdrv file shouldn't load into ram, so Puppy is really a lot less than 90MB.

I always forget we have the zdrv file now (even though it's been around nearly a year...). That means Puppy's only loading 77 mb into ram, aside from whatever is going on with the initrd.gz nowadays. So 77 + 50 = 127. That's a nicer number :)

NetSurf upgraded, CD-remaster fixed 

A little while ago I informed the NetSurf developers that I wanted to use it for the CUPS web interface, but drop-down lists do not work. They let me know that this is now implemented in CVS and to test it. I don't have a printer on this computer, so didn't go all the way, but in preliminary testing it seems to be fixed.
This extends the usefulness of NetSurf, so that as well as being the internal HTML viewer it now can serve as the CUPS manager.

Lobster reported that the CD/DVD-remaster program does not work in Puppy 3.00. I'm not surprised, I haven't looked at the script for a very long time. I have been meaning to -- the two scripts in the menu, my original "Remaster Puppy live-CD" and "Dougal enhanced remaster CD" was only intended by me as a temporary situation, but it became almost permanent. The latter is my original script with some enhancements by Dougal.
I went right through my script, line by line, and fixed a lot of things, also added some extra features. I haven't looked at Dougal's script yet, but one thing I recall is he offered creation of an iso file, whereas my original only allowed burning to CD/DVD -- so I added that choice. I tested my new script and it works fine -- I installed a couple of PET packages, ran the remaster script accepting all the defaults mostly, created an iso, burnt it to CD, and got a new working live-CD.

So, I've now changed the menu so there is just the one remaster-CD entry. This will avoid confusion about which one to use.

I won't upload the script for testing just yet, as I want to see if I can enhance it a bit more to work nicely with kirk's Gslapt package. The remaster script needs to know if any packages have installed files into /etc or /var, as the full content of these directories is not copied as-is to the new pup_300.sfs file. The script looks at /root/.packages/ to get the lists of installed files for PET and registered DotPups, but Slackware packages are missing out. That's next on the list for tonight.

There's something else I also want to do. If someone boots the standard official live-CD 3.00 and creates a pup_save file, an offer is made at shutdown to copy pup_300.sfs and zdrv_300.sfs from CD to same place as the pup_save file. This gives faster bootup, but it does create a problem for custom live-CDs that have the same version number. So, I'm thinking of supporting a custom name, in say /etc/puppycustom, for example "retro" and "firehydrant". The remaster script will create 'pup_300firehydrant.sfs' and this will be the one looked for at bootup. Does this seem reasonable? It means that we can have any amount of customised puppies without any conflicts.

Ha, ha, just after posting about the new NetSurf, I have read on the Puppy Forum about HV3-alpha16. Danielk1977 is hitting back with a much-improved HV3. One thing about HV3 that has great promise in the long term is support for Javascript. Both have CSS support, though I think there were comments in the forum that CSS is more mature in HV3. The NetSurf developers have no plans to incorporate Javascript support. Forum link:

Lobster (ed.Jason<at>gmail.com) 
Good news about the new remastering script. Looking very much forward to it. After a few months of experimenting with frugal and HD installs I still much prefer to run Puppy from a live CD. The option to boot from a choice of saved files or (as suggested) alternative puplets is most welcome. Robert (Ecomoney) is planning to base 'Talking Stick' on Puppy 3.02 to allow a reliable code base. He would like to then use the official Puppy release version Puppy 'Talking Stick' 3.03ce. Hope that would be OK?

Puppy 3 is developing a lot of interest and once again I expect our membership and usage to increase. More diversity. Is Vincent still about?

Yes, the puppycustom naming scheme is a great idea.

As to hv3, it accepts control keys, something that is missing in NetSurf. With more work from Daniel (and help from us), hv3 can look forward to successful javascript integration.

After my lzma iso failed to boot I rebooted with the original cd with the hard drive attached which I had used to remaster it earlier. It then insisted on taking the pup_300.sfs from the hard drive instead of from the cd. Should puppy do this? There was no pupsave. I eventually booted with a v1.06 cd.

1- I always pick the same options when I use Dougal's script ie to produce a snap shot without editing any expanded filesystems nor the cfg file at the end. I then choose the 'iso only' option. Can you not add an option to do all this (or just upto the iso option)?

2- The only bit where I pause is where it offers to customise the cd for that pc only. I have another ancient pc and it would be good to have a boot option to ignore these customisations when booting with the one cd rather than burning 2. Could you add a boot option for this?

3- Could you add a boot option (or function key) to list all boot options.

Thanks Barry and team. It's good to hear of progress with the html viewer.

The custom naming is a good idea. I just wonder how high is it in the priority list.

That feature is usefull for people that wants to play with different versions "simultaneously", This is, mostly more advanced users that can find work arounds for that.

Although I dunderstand that the priority for puppy's development is to have fun and learn along the way.

chooselocale fixed 

Another bug bites the dust! Vanchatr reported a problem with choosing the locale, so I checked out the 'chooselocale' script. Normally, users would run this by clicking the 'setup' icon on the desktop, then the 'Configure Puppy for your country' button. I chose to download the extra locales, which went okay, then there was an error message and the program aborted. I dunno how this one slipped through, but anyway I've now fixed it.

URGENT - a very serious development, see the forum post:

Someone is parading himself as Puppy Linux supporter and trying to give him a bad reputation! The site editors should be alerted to this.

Thanks, and sorry for posting this here.

'zdrv' found, e2fsck at bootup 

A bug in 3.00 is that the 'zdrv_300.sfs' file is not found, consequently many kernel drivers are not loaded. This only happens under certain circumstances, see further down this Blog. I have fixed it. I studied the 'init' script (the script in the initial ramdisk, the first to execute when Puppy boots), but could not see any fault there. I eventually tracked it down to the 'zdrvfind' script, which is a script called by 'modprobe' to locate the zdrv file. While I was looking in the init script I refined some code, so I didn't waste my time in there.

The initial ramdisk (or more correctly the 'initramfs') is supposed to perform a filesystem check if any filesystem reaches a certain number of mounts. This is supposed to be an automatic thing, or so I'm lead to believe from studying the docs, but I just can't get it to work (obviously I've misunderstood something). In 3.00 everything is setup correctly, the initramfs has 'e2fsck', 'fsck', and even an /etc/fstab is created with the last two parameters set to '1 1'. But, 'mount' does not launch 'fsck' as per the docs, instead it just logs a kernel message "EXT2-fs warning: maximal mount count reached, running e2fsck is recommended" and just mounts the partition.

So, I'm puzzled. I do want the f.s. check to occur, so what I've done is add a small function in the 'init' script that runs 'dmesg' to see if the above message got logged (it keeps count of these, in case of multiple identical messages) and if so then unmounts the partition, does a f.s. check, then remounts it. Yeah, it does work, but I'm not entirely happy. But then again, having my own little routine to run the f.s. check does give me some control over the output to screen.

Could it be that mount does nothing about running the fsck itself, but only returns a different code from normal when the count is exceeded? So that the user is supposed to check the code, umount and run fsck if needed? If so that would be a lot cleaner than digging in dmesg.

What I'm wondering though, is how does the counter in mount get reset? Does it somehow know e2fsck was done - i.e. does the latter leave a trace behind? Or is it supposed to be manually reset with some parameter in tune2fs, e.g. the -C parameter?

Home sweet home 

Ah, back home again!

On my last day at the Royal Perth Show, a fellow came up to me and introduced himself as 'aussie', one of our Puppy-enthusiasts! There aren't many of us here in Perth, Western Australia, and this is my first encounter with another individual from our Puppy-forum. Nice guy, we had a pleasant chat about Puppy-related matters.

Okay, on to Puppy development... I'm just about to make up a to-do list for 3.01, and will of course post to this Blog as each item gets completed.

I went to the show, if I'd remembered that you were there I would have come and said hi, but I forgot.

Did you see the fireworks?

Most days I worked from 7.30am to 4.00pm, so I missed the fireworks.


I'm glad you enjoyed participating in the show. Too bad for you they had to cut out the horses.

In case you missed my reports about it in the forum, the Save icon in multisession Puppy quit working in 3.00. Puppy still saves when it shuts down but nothing happens when I click the icon on the desktop.

Good to hear you're home from a "break".

I tested version 3.00 on a Compaq Presario laptop with SATA, and the trick is simply to add acpi=off at boot time.

Nvidia drivers, alternative Pmount, PPPOE working 

Nvidia video cards can be difficult, and the good news is that forum-member 'gray' has compiled drivers for Puppy 3.00. See forum thread:

'zigbert' is one of our most prolific Puppy-programmers and has created some wonderful little apps -- little in the sense that they are very small, but big in their capabilities. He has now created an alternative Pmount, our drive mounter/unmounter. The version in 3.00 is created by me with help from various people, and there has been discussion about how the user interface can be improved. Dougal came up with a tabbed interface awhile back (search the forum to find it) and now zigbert has created a table interface. See this thread:

As you can see from recent posts in this Blog, Roaring Penguin PPPOE in Puppy 3.00 does not work. The great news is that 'Leon' has fixed it by compiling the latest version. He has created a PET package -- just click on it to install, or download then click on it to install. Forum thread:

I fixed some typos, also added a a few extra notes, to the 3.00 release page:

Hey Barry...Could you update your developer pages...???
(when you get a chance; of course)

How Puppy works -- overview of the underlying architecture
How to compile kernel drivers for Puppy
Puppy From Scratch -- compiling Puppy from source
Puppy Unleashed -- creating custom Puppies from binary packages
My News Blog -- follow Puppy's evolution day-by-day
Package management -- how the package management system works
PET packages -- our new unified package format
Dialup Internet: how it works -- our new automatic setup for modems

I attempted to compile the NVidia drivers on 3.0 Final and got the following message -

ERROR: You do not appear to have libc header files installed on your system. Please install your distribution's libc development package.

I did not have this problem in previous Puppy's up to the 3.0 beta. Just thought you could/should look into it.

Otherwise, great (and always getting better) distro!


did murgaLua get taken out of 3.00 cause i can't find it and was wanting to tinker with it a little... downloading version 5.5 now..


The new Slackware compatibility is great success. I installed kirk's gslapt_puppy-0.3.18.pet.


I tried it with installing Bluefish 1.7 and it works perfectly.

With Slackware compatibility Puppy is definitely becoming big distro and staying small in size and even quicker at the same time.

Hi Barry.

Kirk has done the same for some ATi drivers too.

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

I've tried it and it works fine "out of the box".


JB, the Nvidia drivers are already compiled. Kirk compiled them in Puppy3 without any problems.

cb88, murgaLua is currently not in the live-CD. It is a PET package, just run the PETget package manager.

CD orders catch-up 

I have processed about half of the Puppy Unleashed CD orders that I have been holding pending release of 3.00. I'll post them in the morning, and process the rest in the evening after work.

I am sending two CDs, 2.17.1 and 3.00 Unleashed, so recipients have the choice of using whichever they like best. The extra CD is a gift from me for being so patient.

I must say it is really cool of you send out both 2.17.1 and 3.00 guess I'll have to start buying puppy unleashed cd's when I have a cash flow LOL

Anyhow have you considered an unleashed DVD say at the end of each puppy series with all unleashed packages and accelrated divers and the best of the community .pets and .pups and of course bugfixes to the unleashed system...

come to think of it that might make a great CE project say around puppy 3.6 make puppy unleashed dvd with unleashed packages for the entire 2 and 3 series I think that would be doable even on a 4.7 GB dvd

BTW I was able to make an unleashed puppy almost like I wan't but don't have the time to get it just right... for example flash didn't work

my blog show easy step for puppy linux usage, which easy for new puppylinux user

I'm on the home-run! It's 5:30am Friday here and I'll be off to work soon. Saturday is the last day, then Sunday morning I drive home.

I have processed all CD orders, everyone gets two CDs, and I'll keep doing that for awhile.

I have 4-5 emails that I have not replied to. My apologies, I'll catch up with the backlog after I get home.

Forum links for Puppy 3.00 

Here is a link for bug reports:

Tempestuous has been creating some extra drivers and utilities for 3.00:

Regarding bugs, it seems that the most serious is Roaring Penguin pppoe not working. I don't use rp-pppoe and on previous occasions when it had a bug, someone else such as GuestTwo fixed it. If someone can do the same again, that would be great!

Please be sure to read the feedback before deciding whether to upgrade.


I wrote: ". . I simply installed the current Seamonkey 1.1.4 from the Mozilla site into /usr/lib/ and deleted things labeled 1.0.8 and 1.1.4 and all is well seemingly, except that 1.1.4 apparently takes up more space than Barry's 1.1.2, which is probably why it works with the add-on."

"labeled 1.0.8 and 1.1.4" of course should read 1.0.8 and 1.1.2.

I did not try to unrpm the PCLinuxOS package because it has several additional dependencies, and so looked potentially complicated.

Perhaps the simpler way would be to tgz2pet the downloaded seamonkey-1.1.4.en-US.linux-i686.installer.tar.gz ?
This looks easy, and I would like to do the installation right. I tried:

# cd /mnt/hda2/download
# pwd
# tgz2pet seamonkey-1.1.4.en-US.linux-i686.installer.tar.gz

When I clicked on the resulting seamonkey-1.1.4.en-US.linux-i686.installer.pet I got this message:

There was an error expanding package seamonkey-1.1.4.en-US.linux-i686.installer.tar.gz.
Either the file is corrupted, or has not expanded into its own directory with
name of seamonkey-1.1.4.en-US.linux-i686.installer/ (which is how most packages expand).
You will have to go into /root/.packages/ directory and manually clean it up.
This script will now exit...

What next? Maybe this dot.pet is available elsewhere?

Many thanks, Henry

SORRY, my last post was misplaced, Henry


Sorry for posting this here but the community forum unavailable (Critical Error Could not connect to the database).
I reported in the beta2 bugs forum, that I couldn't install for example the Adblock Plus extension for Seamonkey 1.1.2. Now I upgraded my 2.17 frugal install to 3.00final. Interestingly the upgrade process kept my seamonkey1.0.8 folder untouched in /usr/lib (not the binaries but my extensions). It contained the Adblock Plus files in different folders and I simply copied these files to the same locations in the Seamonkey1.1.2 folder.

Files were:

As you can see I also copied the chrome.rdf file which contains the path for the installed extensions. Now I have a working Adblock Plus filter. I don't think its a bug cause we all use different extensions. On the other hand AdblockPlus is a very popular extension, so the upgrade process my scan for it.


murga forum doesnt work, says "Critical Error Could not connect to the database"

here is a bug, if it is not correct place, please remove it.
I got 2.17 installed on old laptop. I try to boot from cd with 3.0 with pfix=ram.... Couldnt boot : error messages :

mount: /dev/hdc is write-protected, mounting read-only
mount: mounting /dev/loop0 on /pup_ro2 failed

kernel log
end_request: I/O error, dev hdc, sector 160100
Buffer I/O error on device hdc, logical block 40025
SQUASHFS error: sb_bread failed reading block 0x133c0
SQUASHFS error: unabe to read uid/gid table

Pausing for 60 seconds...
Setup the Unionfs layered filesystem...
Perform a 'switch_root' to the new Unionfs filesystem...Kernel panic - not syncing: Attempted to kill init!

I get a critical error when accessing the forum.


(c) Copyright Barry Kauler 2008, all rights reserved. http://puppylinux.com/