RC7 (STABLE) WeeDogLinux Arch 64 now released

[wiak]

If you look at the isomaster script in my firstrib00.plug that pulls down the source code for isomaster and compiles that. Not a great example, but works. I also remove gcc and make afterwards as once compiled they're no longer needed (in the clearxbpscache script).

It is a useful example that one though. Both techniques could be rewarding though of course I also want to learn the xbps-src approach.

wiak

[wiak]

In that zramctl line the --find has it find and use the next available free device (so that will be /dev/zram0), the streams sets the number of compression streams the device is allocated which typically you want to set to the number of cores you have; The size sets the size of the virtual device and the algorithm sets the compression method to use.

Nice report on zram performance etc, thanks.

Yes, as you know, you can alternatively adjust all the zram parameters via /sys/block/zramX files as described:

https://www.kernel.org/doc/html/latest/ ... /zram.html

Note that zram uses about 0.1% of the size of the disk when not in use so a huge zram is wasteful.

However, zramctl is part of util-linux and since that is usually installed as part of main root filesystem anyway, that becomes a much more convenient method of adjustinging zram operation.

Like I mentioned, when using copy2ram the files copied in also get temp stored in cache/buffers (which system later frees up automatically or can be released immediately with command: sync && echo 3 >/proc/sys/vm/drop_caches).

EDIT: I notice that there is a void linux template for managing zram swap space (once util-linux and several other dependencies are installed):

https://github.com/atweiden/zramen

Related bash script: https://github.com/atweiden/zramen/blob/master/zramen

Installation:

Code: Select all

xbps-install zramen

wiak

[wiak]

Since Void is a rolling distro, I feel that most firstrib00.plug files for FirstRib void builds would sensibly:

Code: Select all

rm -rf "/var/cache/xbps/*" 2>/dev/null

to save some space since most cached install files will grow old as Void updates. In fact the whole of /var/cache/* could likely be safely removed.

Okay, relaxing evening so just opening browser page...: https://wiki.voidlinux.org/Xbps-src

EDIT: I'm planning to follow how to use xbps-src from within a chroot of firstrib_rootfs (via ./mount_chrootverXXX.sh) that contains install of base-devel template, and git, amongst other base bits and pieces.

I presume no bugs have been discovered as yet in the newest build_weedog_initramfs05 script? It has worked fine on all I have tried, but I only tried a few of the option combinations (one thing I'm not sure of, since not looked/tried that for a long time) is the hybrid builds code (i.e. using say BionicPup kernel and 00firstrib_firmware_modules.sfs) - not so important for me since I prefer using default Void components but I'd still like to have that option available since handy for making smaller systems (since Puppy kernels have so many module drivers inbuilt).

wiak

[rockedge]

I presume no bugs have been discovered as yet in the newest build_weedog_initramfs05 script?

ran it multiple times testing my firstrib00.plug and booted fine and ran almost 100% the build zoneminder script as well.

I am seeing good overall performance and low cpu loads and temps....

my latest version of the desktop includes retrovol and pmcputemp which really gives the desktop a familiar look. These I am downloading from my host server prepared as tar.gz from the PET file versions with wget

-

[rufwoof]

Hitting problems with building a void kernel based build. Looks like for whatever reason its pulling down two kernels, both a 4 series and a 5 series. build_weedog.... script then fails around the kernel1 test line as that does a ls for firstrib/boot/vmlinuz* and then tests existence of that, but is comparing a ls output of two files ... and fails.

EDIT: Ah! Looks like the 5 series is now the voidlinux --current, and I was specifically xbps-install linux4.19 as part of my build script. Changing that to just linux (meta package) should fix it.

[wiak]

Hitting problems with building a void kernel based build. Looks like for whatever reason its pulling down two kernels, both a 4 series and a 5 series. build_weedog.... script then fails around the kernel1 test line as that does a ls for firstrib/boot/vmlinuz* and then tests existence of that, but is comparing a ls output of two files ... and fails.

EDIT: Ah! Looks like the 5 series is now the voidlinux --current, and I was specifically xbps-install linux4.19 as part of my build script. Changing that to just linux (meta package) should fix it.

Yes, as I posted some time back, you maybe missed it and I should draw more attention to the case:

http://www.murga-linux.com/puppy/viewto ... 45#1034845

I then tried:

./build_firstrib_initramfs04_s102.sh kernel=void

and it refuses to do it saying:

firstrib_rootfs needs to at least include xbps-install:\nlinuxX.XX, ncurses-base, and linux-firmware-network

But, I know why... there are now two kernels in my firstrib_rootfs: 4.19 (since I had that from before) and 4.14. So I just renamed (mv) the vmlinuz4.19 one to NOvmlinuz4.19 and tried build initramfs kernel=void again, and it has now copied out the 4.14 kernel (as it should) and created the initramfs04.gz for that. I'll try to boot it now and report back...

I could put an extra check in to allow user to chose which kernel they wish to use if more than one. I'll think about that later.

wiak

[rufwoof]

Did miss that Thanks wiak.

I've just move my firstrib00.plug over to google as its grown to a 5MB filesize as I'm including the source code (and binary) for a ncurses front end for tilda. Along with being able to cut and paste easily and click to follow links when using tilda (and navigate using the mouse within mc), that ncurses menu helps pull it together better. That along with skippy and xlunch and the learning curve is relatively light (mostly mc takes the effort to learn). Good for whether you are predominately mouse or predominately keyboard. Once you're familiar with mc its great as its commonly available on servers so 'feels' much the same whether you're running it locally or remotely.

F1 to show/hide toggle tilda
alt-space - show programs (launcher i.e. xlunch) or mouse into top left corner.
win-space - show windows (skippy-xy) or mouse into bottom left corner.
When in mc use mouse (double clicks to open/execute) or keyboard.
In both xlunch or skippy-xd arrow keys to move around, enter to select, or use the mouse and click items.
If you add additional programs, then /etc/xlunch/entries.dsv is the file to edit, three semicolon separated entries per line (program), description (text underneath icon);image file for icon;command to run when selected.

I've stripped down the firstrib00.plug to remove libreoffice, audacity, kdenlive ..etc. as they're easily installed if desired using xbps-install. Having seen how they work now making it optional whether they're installed or not. If you boot and then install, running save.sh adds whatever you install as a 02 (03, 04 ...etc) changes.sfs file. Which is nice as you can opt to load or not those sfs's simply by renaming without the NN numerical prefix filename digits.

In tilda, running demoapp.sh shows the ncurses menu system. That's still a work in progress. Within firstrib00.plug if you extract the scripts then the source for demoapp is contained within a folder alongside the scripts.

As you say, as/when each firstrib00.plug matures, a separate dedicated Puppy forum thread will be appropriate.

[rockedge]

some more improvements to the firstrib00.plug creating a WeeDog with the latest Void Linux kernel with jwm and rox --pinboard supplying the desktop window and file manager.

firstrib00.plug is here ->
http://murga-linux.com/puppy/viewtopic. ... 69#1035969

[AndresC2]

Hi wiak

build with will haley manual
dell gx240 512 mg ram

run in fat 32

syslinux.cfg

LABEL Debian Buster Runit 4.19.0-5-686
kernel /Buster-runit/live/vmlinuz-4.19.0-5-686
append initrd=/Buster-runit/live/initrd.img-4.19.0-5-686 noprompt boot=live live-media-path=/Buster-runit/live/ union= init=/sbin/runit vga=791 quiet

apt-get install apt-utils whiptail dbus procps --yes && \
dbus-uuidgen > /var/lib/dbus/machine-id

apt-get install linux-image-4.19.0-5-686 --yes

apt-get install live-boot init runit runit-init udhcpc --yes

initrd.img size 23 mb

boot # OK
udhcpc -i eth0 # OK

Buster run Fine

**************************************************************

Important NO live-boot

dell gx240 512 mg ram

./build_firstrib_rootfs_101.sh debian buster i386 firstrib00.plug
./build_weedog_initramfs05_s101.sh debian

firstrib00.plug:

apt-get install apt-utils whiptail dbus procps --yes && \
dbus-uuidgen > /var/lib/dbus/machine-id

apt-get install linux-image-4.19.0-5-686 --yes

apt-get install init runit runit-init busybox udhcpc --yes

run in fat 32

syslinux.cfg

LABEL WeeDog Debian 4.19.0-5-686
kernel /WeeDog/vmlinuz-4.19.0-5-686 usbwait=15 bootfrom=/mnt/sdb1/WeeDog changes=RAM
initrd /WeeDog/initramfs05.gz

vmlinuz-4.19.0-5-686 # OK
initramfs05.gz # Ok but size is huge 50 mb and slow loading

boot Kernel panic! after usbwait=15

I try several times usbwait=60 but Kernel panic!

maybe initramfs05.gz 50 mb fill all my 512 ram

Please try the same in fat 32 with debian buster

very cool Projects Wiak

thanks!

[wiak]

vmlinuz-4.19.0-5-686 # OK
initramfs05.gz # Ok but size is huge 50 mb and slow loading

boot Kernel panic! after usbwait=15

I try several times usbwait=60 but Kernel panic!

maybe initramfs05.gz 50 mb fill all my 512 ram

Please try the same in fat 32 with debian buster

very cool Projects Wiak

thanks!

Hi AndresC2, nice and interesting attempt. I've lost touch with debian, and busy with Void Linux since that's my main interest at the moment, but good you tried this, despite not working on your system. I will keep this example in mind and try it sometime though. In debiandogs (which is all I know about Debian-wise) the initramfs is only smaller (I've looked) because the modules are internally not 'individually' compressed at all but the whole set of them are then heavily compressed resulting in quite a small initramfs. That heavy compression doesn't work if the individual modules are themselves already compressed.

However, that DD-type small initramfs all has to be uncompressed into space reserved by kernel anyway, so I'm surprised it is any quicker loading in (well...not really surprises since slow disk I/O might be the issue on your machine so small initramfs better speedwise - otherwise, not a major issue) and actually in RAM I'd expect it to take up more space than any WeeDog-created one (since WeeDog keeps any individually compressed modules compressed in RAM whereas, DD method stored them uncompressed in RAM). Anyway, your will haley methods may result in difference I don't know about until testing myself sometime. Or maybe someone else will make WeeDog Buster build attempt beyond what I have started with. You've certainly tempted me to try

and also I'm thinking of producing an example stripped down Void version (i.e. stripped libs, removing docs/man pages/locales etc - just to see how small the end-result actually could be; nice for copy2ram use, but having said that, original iso-size is not particularly important for me and updates will soon bloat system again (though continually stripping docs/man-pages/locales could still be auto-done of course, as in DD).

Yes, I'll try it sometime.

EDIT: Okay, I'm too curious. No one has really tried the Debian build before you Andres (aside from my early check) so I'll give your example a go on my machine using WeeDog method.

EDIT2: Building now. Off the top of my head I'm wondering if this is the problem for you (can maybe solve if so, but have to check):

USB: The GX240 uses the Intel 845 chipset (no additional letters). It only has 1.1 support

Cheers,

wiak

[wiak]

Hello AndresC2

My machine is HP elitebook 2530p and I currently have 4GB RAM in it (its usb ports are version usb2).
So best I could do was use mem=512M kernel boot parameter to try and simulate 512MB system (but that method is not foolproof...). System booted with WeeDog Debian Buster OK. You will see results from free, uname -a, cat /etc/debian_version, and mount | head -n3, taken after booting below.

Code: Select all

# free
              total        used        free      shared  buff/cache   available
Mem:         507584       32936      384572         904       90076      461032
Swap:             0           0           0

# uname -a
Linux (none) 4.19.0-6-686 #1 SMP Debian 4.19.67-2 (2019-08-28) i686 GNU/Linux

# cat /etc/debian_version
10.1

# mount | head -n3
inram on /mnt/layers/RAM type tmpfs (rw,nosuid,nodev,relatime,size=507584k)
/dev/sdb1 on /mnt/sdb1 type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)
overlay_result on / type overlay (rw,relatime,lowerdir=01,upperdir=/mnt/layers/RAM/upper_changes,workdir=/mnt/layers/RAM/work)

As you can see from mount command above, I used usb stick type vfat (fat32) /dev/sdb1.

I also booted using syslinux with syslinux.cfg stanza:

Code: Select all

label WeeDog
kernel /WeeDog/vmlinuz
append initrd=/WeeDog/initramfs05.gz bootfrom=/mnt/sdb1/WeeDog usbwait=12 inram_sz=100% rdsh3 changes=RAM mem=512M

NOTE WELL:

I used latest: build_weedog_initramfs05_s103u.sh to create the initramfs05.gz (which needs that inram_sz=100% put in the syslinux.cfg line as shown). Please always use latest scripts when sending in results if you can. Notice from above syslinux.cfg that I put in a temporary shell break at rdsh3 just so I could check things at that point in the initramfs/init script (exit from there to complete the boot up).

To build the system I used:

Code: Select all

./build_firstrib_rootfs_101.sh debian buster i386 firstrib00.plug

where firstrib00.plug contained:

Code: Select all

apt-get install apt-utils whiptail dbus procps --yes && \
dbus-uuidgen > /var/lib/dbus/machine-id

apt-get install linux-image-4.19.0-6-686 --yes

apt-get install init runit runit-init udhcpc --yes

Note that Debian has changed the kernel revision number.

I forgot to try and set root password in there, so I used ./mount_chrootver007.sh to allow me to use "passwd root" command in that chroot, followed by exit and ./umount_chrootver007.sh.

I then created the initramfs05.gz using command:

Code: Select all

./build_weedog_initramfs05_s103u.sh debian

Once vmlinuz4.19xxxxxx was created I renamed it to vmlinuz (to save me some typing...) and
then copied the three files: vmlinuz, initramfs05.gz and 01firstrib_rootfs.sfs to /mnt/sdb1/WeeDog directory, which as I said had been formatted fat32 and had syslinux put onto it.

Maybe you could try another build with that exact syslinux label and if it reaches the rdsh3 break point okay that will tell us that the initramfs has successfully loaded into RAM. In any case I can then try and help you to get it all to boot successfully, as it has done in my own test above.

I have an older laptop, with around 512MB RAM, lying 'somewhere' gathering dust. I'll try and find it and if I manage I'll check to see if it will boot with same usb stick.

Cheers

wiak

[wiak]

Hello again AndresC2,

If the problem is that your laptop only uses usb1.1 protocol it may be that you need to add a module to the big list at line 48 in build_weedog_initramfs05_s103u.sh script, which ends with:

Code: Select all

ehci-pci ohci-hcd uhci-hcd xhci-pci xhci-hcd usb-storage xts uas;do

anywhere in there put in module name: ohci-pci

and modify line 289 from:

Code: Select all

	modprobe -r `lsmod | cut -d' ' -f1 | grep -Ev 'ehci|xhci|sdhci|uas|usbhid'` 2>/dev/null  # keep ehci,xhci,sdhci,uas,usbhid

to

Code: Select all

	modprobe -r `lsmod | cut -d' ' -f1 | grep -Ev 'ehci|xhci|sdhci|uas|usbhid|ohci'` 2>/dev/null

(i.e. added |ohci to the list of modules not to remove).

and then do a new run of ./build_weedog_initramfs05_s103u.sh debian

Note that if this work, you can save some RAM in the end by rebuilding again later but removing ehci|xhci|uas and probably usbhid from that modules remove list since these modules probably aren't needed for usb1.1 (I'd have to check)

Cheers, wiak

[AndresC2]

HI wiak

rdsh3 load fine

bootfrom is /mnt/sdb1/WeeDog etc...

then tipe exit but kernel panic

later try your fix ohci-pci in new build

but kernel panic

my pc dell gx240 usb1.1 year 2000, too old i guess.

thank you wiak for all

see you

[wiak]

HI wiak

rdsh3 load fine

bootfrom is /mnt/sdb1/WeeDog etc...

then tipe exit but kernel panic

later try your fix ohci-pci in new build

but kernel panic

my pc dell gx240 usb1.1 year 2000, too old i guess

Well, no, AndresC2... since rdsh3 loaded fine that means initramfs/init started fine and kernel thus loaded fine. Only issue is the real root filesystem not loading correctly at the switch_root. Since you said will haley install did boot fine, then so should WeeDog - almost sure to simply be a module still needing loaded since boots fine on my own system so everything else (runit etc) working fine.

One last thing I suggest to try, if you wish, is to simply create a blank file called modules_remove.plug and put that in directory /mnt/sdb1/WeeDog and then try booting again. The effect of that blank file is that it tells the WeeDog initramfs/init script not to remove ANY of the early-loaded modules, hence if module missing is in the initramfs/init list then it will be loaded. If that works can later find out which module needs kept (since loading them all does use more RAM). But certainly, from you report about will haley method then WeeDog would certainly work on your old Dell (and work well since it uses less RAM and runs more efficiently than most alternative systems I've tested against.

Anyway, I'll run it on an old machine of my own (older than yours probably) and report back once I've tried that - personally I'm sure I can get it to work okay.

EDIT: Actually, when it is booted with will haley tutorial method, if you open a terminal and type command lsmod, you should be able to see which modules (relating to usb boot) that are being used, and then you just need to make sure same is available and loading in WeeDog. Anyway, up to you what you want to try or not! The other thing to try, from your will haley configured boot are the commands: lsusb and lspci -v (not the busybox ones but util-linux (I think) ones - they will tell you what kernel drivers are being used/needed by your usb port. By the way, rdsh3 breakpoint should include message that is the result of the following initramfs/init script code:

Code: Select all

echo -e "\e[95mbootfrom is $bootfrom\e[0m" >/dev/console
echo -e "\e[95mmountfrom is $mountfrom\e[0m" >/dev/console
echo -e "\e[95mlower is $lower\e[0m" >/dev/console
echo -e "\e[95mupper_work is ${upper_work:-readonly}\e[0m" >/dev/console

If all is well at that stage, you should see message:

bootfrom is /mnt/sdb1/WeeDog
mountfrom is /mnt/sdb1/WeeDog

and most important:

lower is 01

and check that there is no error message about init not being able to mount something. If all the above is fine, then should be easy to fix. If the 01 is missing then the initramfs/init hasn't been able to find 01firstrib_rootfs.sfs and the overlay merged result won't be correct so kernel panic will definitely happen... that would be the case if module to see the usb stick isn't loaded...

EDIT2: I think the module you need is probably the old module uhci-hcd, that is already in the main module list (hence your boot gets to rdsh3 okay) but then it gets auto-removed thereafter (hence kernel panic at switch-root). You can fix by adding uhci to the modprobe -r line as follows:

Code: Select all

modprobe -r `lsmod | cut -d' ' -f1 | grep -Ev 'ehci|xhci|sdhci|uas|usbhid|ohci|uhci'` 2>/dev/null

But you don't need to rebuild. That line can just be put in the file modules_remove.plug since whatever is in there gets used instead of what the buildscript puts into initramfs/init. So first try an empty modules_remove.plug as I previously suggested, and if that works, try putting the above line in there, and rebooting. If that works, you can save further RAM probably by shortening it to not include modules not needed, to:

Code: Select all

modprobe -r `lsmod | cut -d' ' -f1 | grep -Ev 'sdhci|uhci'` 2>/dev/null

And you only need sdhci if you are planning to boot from sd card as an alternative...

wiak

[AndresC2]

Hi Wiak

Can you see lsmod-lspci-lsusb.log first

and later I apply the fix

thanks wiak

[wiak]

Hi Wiak

Can you see lsmod-lspci-lsusb.log first

and later I apply the fix

thanks wiak

I doubt you need me for this analysis AndresC2

Note that I'm presuming this log is from your successful will haley boot and not from WeeDog at rdsh3 position, which would tell me nothing since I need the correct booting lsmod (not the lsmod you could take at rdsh3 in WeeDog since that loads all modules at that stage, not only the ones finally required once successful boot has been achieved).

Code: Select all

# cat lsmod-lspci-lsusb.log |  grep uhci
uhci_hcd               40960  0
usbcore               188416  4 usb_storage,ehci_hcd,uhci_hcd,uas
	Kernel driver in use: uhci_hcd
	Kernel modules: uhci_hcd
	Kernel driver in use: uhci_hcd
	Kernel modules: uhci_hcd

As you can see, the missing module is uhci_hcd (same as uhci-hcd as far as modprobe is concerned) so simply boot as I suggested with file modules_remove.plug in /mnt/sdb1/WeeDog at the time of booting containing only the following line exactly:

Code: Select all

modprobe -r `lsmod | cut -d' ' -f1 | grep -Ev 'ehci|xhci|sdhci|uas|usbhid|ohci|uhci'` 2>/dev/null

By, the way, why your log also shows, ehci_hcd and uas is a bit surprising, since these would normally be for usb2 and above I think. Anyway, if your WeeDog boots successfully with above fix you could reboot with the slimmed down suggestion attemp (i.e. simply edit modules_remove.plug to contain following)t:

Code: Select all

modprobe -r `lsmod | cut -d' ' -f1 | grep -Ev 'sdhci|uhci'` 2>/dev/null

If neither of the above work then simply use a completely empty modules_remove.plug. If that doesn't work then I have no further ideas (though the fact you say WeeDog boots okay as far as rdsh3 means above should work or something else wrong I don't know about on your system; for example, why you installing busybox on WeeDog attempt but not on will haley attempt?? Busybox not needed and maybe its init is over-writing runit??? I don't know, but do it without installing busybox in your firstrib_rootfs - I didn't install busybox in that myself and all worked fine - i.e. in your firstrib_rootfs you should absolutely 'make sure' /sbin/init ends up being a symlink to something to do with runit and NOT to busybox init, so best not to install busybox for test just in case that overwrites runit setup...).

Anyway, good luck Andres. Seems clear to me it can be solved since once it manages to reach rdsh3 any problems left should be relatively minor.

wiak

[rufwoof]

Any suggestions for the best way to setup/boot where the 01firstrib_rootfs.sfs is contained within initramfs05.gz? Which is more convenient for the likes of PXE and other boot choices (virtualbox ??). Haven't tried it yet, but imagine that would have to use bootfrom=/

My save and merge saves scripts would also have to be changed as they currently use the bootfrom parameter as the target of where to save/merge changes sfs files.

Current work in progress is I'm revising my firstrib00.plug so that is can be run as a script with a 'build' parameter, and when so it has wiaks build scripts contained within it, so it builds a vmlinuz, initramfs, 01firstrib_rootfs.sfs but where I'm looking to modify that so the 01firstrib_rootfs.sfs is moved into initramfs.gz. A nice and simple one script along with just needing to modify the first handful of lines in that script before running it i.e. for locale, root and user password setting, wireless ssid/password ...etc.

[AndresC2]

Hi Wiak : )

Thank you so much !!!!!

WeeDog run fast my friend more than normal debian buster.

modprobe -r `lsmod | cut -d' ' -f1 | grep -Ev 'ehci|xhci|sdhci|uas|usbhid|ohci|uhci'` 2>/dev/null # work fine

modprobe -r `lsmod | cut -d' ' -f1 | grep -Ev 'sdhci|uhci'` 2>/dev/null # much better

posting from Dillo right now

jwm,xfe.mc,xorg,busybox run very fine so far.

later testing more with another desktop.

thank you for your patience wiak.

[wiak]

Any suggestions for the best way to setup/boot where the 01firstrib_rootfs.sfs is contained within initramfs05.gz?

Hi rufwoof,

The original build initramfs did in fact create what I called a huge initramfs because it contained the whole of firstrib_rootfs inside it; that was the version that used chroot rather than switch_root. Admittedly, that early version was pretty basic compared to the present day FirstRib/WeeDog scripts. I think last of the chroot scripts which used a 'huge' initramfs is this one:

https://github.com/firstrib/firstrib/bl ... r008pre.sh

It wouldn't be particularly difficult to modify current WeeDog to produce a 'huge' initramfs version. I think in that old version I maybe did use / as lower dir (though I haven't checked and can't remember EDIT: since checked and yes that was the way I did it then). Maybe better would be to simply embed 01firstrib_rootfs inside the initramfs build followed by switch_root to it (well... I mean to the overlay merged result rather than the 01firstrib_rootfs.sfs lower layer) much as now really (aside from that sfs being embedded inside the initramfs). I've tried to keep the scripts simple so as to be relatively easy to modularise and put together in different ways (though it can be surprisingly difficult to avoid dreaded kernel panics when making even simple modifications to an initramfs/init...).

wiak

[wiak]

posting from Dillo right now

jwm,xfe.mc,xorg,busybox run very fine so far.

later testing more with another desktop.

That's good to hear, Andres, and I'm happy it is running fast for you. By the way, you could, I think, shorten it one more step to save tiny bit more RAM since sdhci is only needed if booting from sd card, which I gather you are not:

Code: Select all

modprobe -r `lsmod | cut -d' ' -f1 | grep -Ev 'uhci'` 2>/dev/null

Once you have created a firstrib00.plug that is simple but polished enough to be usefully used by others it would be great if you would post it on this thread for download (or in its own thread) and I'd make a link to it on the User Contributed plugins page:

http://www.murga-linux.com/puppy/viewto ... 29#1029029

It would be the first contributed firstrib00.plug for a debian-based WeeDog system.

wiak