Puppy Linux Discussion Forum

Phil_54 wrote: ↑Sun Aug 14, 2022 11:35 am

First, thank you for a very useful script to install lots of distros for trial. I've tried several, current favourite is KLV_Airedale v 14, which runs easily on my old chromebook 2Gb ram (on GalliumOS past 3 years) from SD card. However choice no. 1, vanilladpup-9.2.9-extra.tar, has not gone well. Downloaded ok, but realised line 249 needed '-extra' (I think?). Errors came up as below.

mv: cannot stat 'zdrv_vanilladpup_9.2.9-extra.sfs': No such file or directory
mv: cannot stat 'fdrv_vanilladpup_9.2.9-extra.sfs': No such file or directory
mv: cannot stat 'bdrv_vanilladpup_9.2.9-extra.sfs': No such file or directory
mv: cannot stat 'puppy_vanilladpup_9.2.9-extra.sfs': No such file or directory
mv: cannot stat 'adrv_vanilladpup_9.2.9-extra.sfs': No such file or directory
mv: cannot stat 'devx_vanilladpup_9.2.9-extra.sfs': No such file or directory
mv: cannot stat 'docx_vanilladpup_9.2.9-extra.sfs': No such file or directory
mv: cannot stat 'nlsx_vanilladpup_9.2.9-extra.sfs': No such file or directory

I edited weedogit.sh to include '-extra'. Got a bit further (docx, devx and nlsx files created).
I noticed github had iso and tar files, so downloaded the iso file and extracted these, apart from adrv (couldn't see it) and put these in folder, along with vmlinuz, which also hadn't appeared.
Edited menu.lst and rebooted. Seemed to start ok but stayed in black screen for a couple of minutes until I got bored.

I'd really like to try this version, so any help appreciated.
I have run many distros from usb and sd card over the years with little problem (sound, touch pad issues mainly). Chromebook is original Toshiba CB30-102.

Yes, I didn't check that one for any changes that would effect things, but I'll take a quick look tomorrow (and yes, does look like the -extra is needed where you said - I do use the tar and I'm surprised it didn't work after your change, but maybe other things about that distro have changed - will test). EDIT. My mis-reading - I believe it 'should be' zdrv_vanilladpup-9.2.9-extra.sfs not zdrv_vanilladpup_9.2.9-extra.sfs (not an underscore before 9.2.9) so something gone wrong there. No... underscore was how it used to be - maybe changed by vdpup creator? I'll need to have a look inside the tar to see what it should be now... For next version I'll likely make the code more robust so it finds the correct name more automatically even if it changes a bit between releases. It is also possible the distro could be changed so no longer works with WDL initrd, but your error messages above do indeed just suggest the names weedogit.sh script is using need fixed for the component parts.

EDIT: seems I need to use the iso version now. Will check shortly.

KLV-airdale up to ver beta16 (at least) now by the way, but you probably know that. Yes, it is fun to test them all out without needing to re-partition.

New version of weedogit script attached to first post of thread

viewtopic.php?p=50074#p50074

LATEST is progname="weedogit.sh"; version="017"; revision="-rc1" Revision Date: 15Aug2022

Changes:

# re-wrote KL_vdpup section such that it now works as a general purpose choice to weedog most any Pup (e.g. now somewhat old, fossapup) simply
# by changing URL01, distro01 name, and subdirectory01 name (see lines 20-24 for howto). Default is KL_vdpup since my only reason for
# including that originally was to avoid frugalify which didn't support frugal installs in subdirs nor some other traditional Puppy features.
# The weedogged pups are just for fun and experiment though. You would need to modify some small Puppy system scripts for better KL use.
# e.g. Currently KL_Pup shutdown process is a bit iffy - at final prompt, you sometimes need command: poweroff
# You can easily modify folder contents 09WDLfork_vdpup to fix the above (its higher layer than 08puppy... so replaces original script versions).
# As before also weedogs: linux-lite, bunsen-lithium, LXLE-Focal, 4MLinux NOW plus austrumi and Fedora Rawhide cmdline!
# tails-amd64 (part working only - ctrl-alt f2 to commandline login root:root; reboot -f to restart),
# Debian-live, Regata_OS (password is blank, can: sudo password root to user:pw root:root),
# Kodachi, SysLinuxOS (for passwords check distro websites or try user:pw weedog:weedog or root:root)

Been a lot of quick alterations so may be bugs. Also, as before I haven't checked any further existing distro download URLs. Please let me know anything you find.

@wiak

I appreciate for your hard work.

New version of weedogit script attached to first post of thread

viewtopic.php?p=50074#p50074

Changes:

LATEST: progname="weedogit.sh"; version="018"; revision="-rc1" Revision Date: 18Aug2022

# NEW: xubuntu, lubuntu

# linux-lite, bunsen-lithium LXLE-Focal,
# tails-amd64 (part working only - ctrl-alt f2 to commandline login root:root; reboot -f to restart),
# Debian-live, Regata_OS (password is blank, can: sudo password root to user:pw root:root),
# Kodachi, SysLinuxOS, 4Mlinux, austrumi
# Fedora Rawhide,
# FOR LOGINS user:passwords: check distro websites or try weedog:weedog or root:root

Previous also included:
# re-wrote KL_vdpup section such that it now works as a general purpose choice to weedog most any Pup simply
# by changing URL01, distro01 name, and subdirectory01 name (see lines 20-24 for howto). Default is KL_vdpup since my only reason for
# including that originally was to avoid frugalify which didn't support frugal installs in subdirs nor some other traditional Puppy features.
# The weedogged pups are just for fun and experiment though. You would need to modify some small Puppy system scripts for better KL use.
# e.g. Currently KL_Pup shutdown process is a bit iffy - at final prompt, you sometimes need command: poweroff
# You can easily modify folder contents 09WDLfork_vdpup to fix the above (its higher layer than 08puppy... so replaces original script versions).

If you running weedogit.sh script to build another distro that weedogit uses _set_passwords to set up weedog:weedog as normal user that mechanism sometimes fails if running weedogit.sh from some Puppy Linux distros.

Reason seems to be that some Puppy's don't like 'sudo' command (and don't need it since they run as root user anyway); weedogit.sh reports a PAM error with these Pups. Best solution would be if the Pups were modified to not mind that a linux command might start with the word sudo (which most distros might want). However, there is a quick alternative workaround - to make weedogit.sh work in most Pups anyway, just open the weedogit.sh script in say geany and look for the following (around line 133) and remove the word 'sudo' before the mount -t overlay -o \ command prior to attempting a build.

_set_passwords (){ # for root user and normal user weedog
  # So here is how to make a temporary overlay of ro X.sfs and rw upper_changes
  sudo mount -t overlay -o \
lowerdir=/tmp/weedogit/fsroot,\
upperdir=upper_changes,\
workdir=work \
overlay_result /tmp/weedogit/merged
...

After making the above alteration, I successfully just built a WDL_linlite (linux lite) whilst using VoidPup64 as a host, and then on reboot was able to successfully boot into that WDL_linlite distro using name: weedog with password: weedog. However, root:root doesn't work with that one (some distros resist root password being set via the method I try unfortunately). The solution to that for WDL_linlite is, after building it but prior to running it, modify the file upper_changes/etc/passwd and change the following line:

root:x:0:0:root:/root:/bin/bash

to

root::0:0:root:/root:/bin/bash

i.e. take out the x

Next time you boot WDL_linlite you should then also be able to login as root with no password (i.e. just hit enter).

What the set_passwords code did was to create an overlayfs of the 08filesystem.sfs and the upper_changes folder during its original build and in the results of useradd weedog and so on were added into that. When that mechanism failed (because of that sudo) the resultant upper_changes did not get the required new /etc/passwd information stored in it so you could not log in! But after above quick modification to weedogit.sh all should be fine on these Pups that baulk at sudo.

EDIT: the weedog:weedog just worked for me, but for some reason root:root still didn't (yet I managed that yesterday - I must have done something extra or different yesterday; I'll report back about that if I find what....
EDIT2: Did work after all... I had forgotten to take out the x in /etc/passwd for root user. Posting from WDL_linlite right now. Chrome needs --no-sandbox of course when running as root.

I know CLEAR Linux has not been tested with weedogit: And, I am aware of the discussions over the past week on PM across the Puppy Forum spectrum.

Yet, I wonder after seeing this reading, if there could be applicability of this as a test, here. There may be some insight to this as a testbed that 'may' prove useful in the community.

I feel like EasyOS would do better than Clear Linux, using a Docker container. EasyOS has been built from the ground up for operating containers and can run another complete instance of a Linux desktop OS in one.

I agree with EasyOS. But, its not as polished with enough examples and videos that have made it much more knowledgible across the Linux world and its multiple distros which include it. Same, of course, for MS's Hypervisor implementations.

The article talks about DistroBOX which does backend with the containers it mentions. I am not sure if EasyOS/its EasyOS containers would backend, similarly such that it would provide the easy of use functionality Distrobox intends.

In any event, it was a mere thought of whether there Clear was a viable choice for that and other reasons it is intending to give to INTEL CPU users of LInux (I do recognize it not limited as other x86-64 manufacturers, but, it is coming from Intel).

Find LATEST weedogit script to auto-build "weedogged" flexible frugal installs of many distros attached to the first thread post per usual

viewtopic.php?p=50074#p50074

Changes:

LATEST: progname="weedogit.sh"; version="020"; revision="-rc1" #Revision Date: 23Aug2022

THIS IS A MAJOR NEW VERSION RELEASE. Main change is that majority of upstream distro URLs are now auto-scraped from the web. This is experimental and the web-scraping is simplistic and could do with improvement. In practice, around one third of the current handled distros still need their download URLs manually updated (like previous weedogit releases) when required. I found these too difficult to quickly/reliably/easily auto-scrape. Feel free to provide scraping recipe if you can work some out for these... or improved scrape code for the others. If auto-scrape ever fails, you can still use manual URL assignment as per previous weedogit.sh releases.
# Currently the below following continue to need manual URL updates: Pop-os, Zorin, Garuda Sway,
# tinycorelinux, Ubuntu, Linux Mint, Linux Lite, Kodachi, 4MLinux, Xubuntu, Lubuntu

Also, the grub-config suggestions have been automated such that the suggested grub stanzas should work without alteration - the bootdir name (whatever you choose to use) of the directory you run weedogit.sh from should now be correctly auto-placed in the grub config stanza as should the actual UUID of the partition you have that bootdir stored in at time of the build.

I am considering request from forum member Clarity for possible optional/alternative use of LABEL in auto grub-config routine in future weedogit release.

I've got Clear Linux running with weedog. Very straightforward.

Find LATEST weedogit script to auto-build "weedogged" flexible frugal installs of many distros attached to the first thread post per usual

https://forum.puppylinux.com/viewtopic. ... 074#p50074

Changes:

LATEST: progname="weedogit.sh"; version="021"; revision="-rc1" #Revision Date: 24Aug2022

Now the automated grub_config.txt provided stanzas include option of using detected UUID or detected LABEL. Works fine in my tests with grub2 grub.cfg (label won't work if no label of course, and will confuse system if two fs with same label...), but don't know if the grub4dos menu.lst LABEL stanza works or not since I don't have grub4dos on my machine to test it.

02x IS A MAJOR NEW VERSION RELEASE. Main change is that majority of upstream distro URLs are now auto-scraped from the web. This is experimental and the web-scraping is simplistic and could do with improvement. In practice, around one third of the current handled distros still need their download URLs manually updated (like previous weedogit releases) when required. I found these too difficult to quickly/reliably/easily auto-scrape. Feel free to provide scraping recipe if you can work some out for these... or improved scrape code for the others. If auto-scrape ever fails, you can still use manual URL assignment as per previous weedogit.sh releases.
# Currently the below following continue to need manual URL updates: Pop-os, Zorin, Garuda Sway,
# tinycorelinux, Ubuntu, Linux Mint, Linux Lite, Kodachi, 4MLinux, Xubuntu, Lubuntu

Also, the grub-config suggestions have been automated such that the suggested grub stanzas should work without alteration - the bootdir name (whatever you choose to use) of the directory you run weedogit.sh from should now be correctly auto-placed in the grub config stanza as should the actual UUID of the partition you have that bootdir stored in at time of the build.

Note: latest weedogit vdpup ver 9.2.11 doesn't boot on my machine. A kernel-related issue (I notice it is a much smaller kernel btw) - I swapped kernel/modules/firmware with previous 9.2.10 version and then booted fine.

Following th latest release of weedogit.latest.sh, I saw Keef post he tried weedogged clear linux. I went to distrowatch to see what it's about. I didn't try it, as one of the latest update highlighted piqued my interest. A distro called Mabox, which is a Manjaro derivative with Openbox/Tint2. One of the release highligths, is a in-house configuration tool called Colorizer. One of the mentioned points is that this utility can automatically adjust colour schemes, for the in-built conky displays, to match the colour pallette of the selected wallpaper. There are 9 preconfigured scripts, which are all fairly simple, which range from a simple logo display to a basic, but nice sysinfo display. You get the Manjaro configuration, with the Mabox tools as a bonus. It runsa very nicely as a weedogged installation.

There was/is one issue which I have had to use a work around. For some reason the timezone change is not being retaied on a boot/reboot. I have checked the upper_changes /etc/localtime, from another running installation and it is correct, but on boot it has changed back to being a link to /usr/share/zoneinfo/Etc/UTC[/i]. To overcome this issue, I added 2 command to delete /etc/localtime and create the correct link to my timezone.

To add mabox to the weedogit-latest.sh, i downloaded the .iso and opened it to make the changes. It is structured like a manjaro image, I think they possibly used Manjaro xfce as their base. This is the extracted changes I added:

>
# The following distros still require their URLs manually updated
>
URL36="https://sourceforge.net/projects/mabox-linux/files/22.08/mabox-linux-22.08-Herbolth-220820-linux515.iso"

>
# --- NEW ---
>
distro36="Mabox";							subdirectory36="WDL_mabox"
>
Choose a distro to WeeDogIt

>
36 $distro36

>
case "$distro" in
>
### Inserted distro36 code to be last case, prior to printf statement  ### 
  36)	distro="mabox"
		subdir="$subdirectory36"
		if [ "$URL36" = "" ];then
			:
		fi
		wget -c --no-check-certificate "${URL36}"
		echo "Extracting large files from iso. Please wait patiently ..."
		sync;sync
		mount "${URL36##*/}" /tmp/weedogit/miso
		cp -a /tmp/weedogit/miso/manjaro/x86_64/rootfs.sfs 04rootfs.sfs
		cp -a /tmp/weedogit/miso/manjaro/x86_64/desktopfs.sfs 05desktopfs.sfs
		cp -a /tmp/weedogit/miso/manjaro/x86_64/mhwdfs.sfs 06mhwdfs.sfs
		cp -a /tmp/weedogit/miso/manjaro/x86_64/livefs.sfs 07livefs.sfs
		sync;sync
		mount 04rootfs.sfs /tmp/weedogit/fsroot
		cp -a /tmp/weedogit/fsroot/boot/vmlinuz* vmlinuz
		_get_WDL_initrd
		mv initrd.gz initrdSKEL.gz
		mkdir -p initrd_decompressed
		cd initrd_decompressed
		sync;sync
		zcat ../initrdSKEL.gz | cpio -idm
		cp -a /tmp/weedogit/fsroot/usr/lib/modules/* usr/lib/modules/		
		echo "Result being compressed. Please wait patiently ..."
		sync;sync
		find . | cpio -oH newc 2>/dev/null | gzip > ../initrd.gz 
		cd ..
#		_set_passwords
		;;	
	*)	printf "$progname ${version}${revision}\n"; exit 0;;
esac

Note: I have used the '>' sign to indicate blocks of removed code to show only my changes.

Edit: Having home internet issue following post. Currently posting from phone. Will attempt to repost screens hot later.

Edit 2: inserted a hosted image. Image has 4 conky displays active.

TerryH wrote: ↑Thu Aug 25, 2022 3:45 am

Following th latest release of weedogit.latest.sh, I saw Keef post he tried weedogged clear linux. I went to distrowatch to see what it's about. I didn't try it, as one of the latest update highlighted piqued my interest. A distro called Mabox, which is a Manjaro derivative with Openbox/Tint2. One of the release highligths, is a in-house configuration tool called Colorizer.

Yes, that one sounds nice. Being Openbox/tint2 is lighter than xfce of course (says uses just 300MB RAM on boot) - I like that, and it is another Arch Linux spin, which per WDL_Arch64 is my favourite upstream distro.

I've worked out download URL 'webscrape' for it's 'latest' release, which makes future update no issue, so will add it to weedogit.sh. But I'll also await any further comments from yourself @TerryH for any issues you come across to see (if possible) to address in weedogit additional code.

The only unfortunate thing about Arch-based distros is their poor (like none) support for secure boot, which wouldn't bother me were it not for this fussy Windows laptop I currently use (though personally never use the Windows install on it...). Otherwise, as far as I'm concerned, Arch is the best (well - if you like using a rolling constantly up-to-date distro, which 'might' occasionally break for a while...).

Mabox works better & much lighter compare to Manjaro.

I tested also sparky linux, but only root access.

esos wrote: ↑Thu Aug 25, 2022 2:57 pm

Mabox works better & much lighter compare to Manjaro.

I tested also sparky linux, but only root access.

Sparky is interesting too. Semi-rolling so up-to-date compared to most debian-based distros. Which desktop would be most useful? I'll try minimal gui I think.

TerryH wrote: ↑Thu Aug 25, 2022 3:45 am

There was/is one issue which I have had to use a work around. For some reason the timezone change is not being retaied on a boot/reboot. I have checked the upper_changes /etc/localtime, from another running installation and it is correct, but on boot it has changed back to being a link to /usr/share/zoneinfo/Etc/UTC[/i].

@TerryH
Ok, I just booted, set my timezone with the Mabox config gui app. I then opened /mnt/my_boot_dir in filemanager and looked inside upper_changes and all was correct. I then rebooted, and as you say, the link (which was correctly saved in upper_changes persistence folder) gets changed by Mabox itself on reboot...

I tracked it down: on boot the Mabox linux runs the script: /usr/bin/mabox-live and that calls another wee script called /usr/lib/manjaro-tools/util-live.sh and it is that latter script that resets timezone back to default live link, which isn't what we want.

What I did to stop that behaviour is that first I set up my timezone and everything else the way I liked it and then opened file /usr/bin/manjaro-live (whilst still on the running system) and commented out the line:

[[ -r ${LIBDIR}/util-live.sh ]] && source ${LIBDIR}/util-live.sh

NOTE that I did the above as root user from running Mabox system (either use sudo to open terminal or create root user and logout/login again as root prior to making the alteration).

Don't know if there will be any side-effects from disabling that call to util-live.sh, but seemed to work fine. At least you know where to look if any other issues relating to it being a live iso and having auto-change scripts...

Find LATEST weedogit script to auto-build "weedogged" flexible frugal installs of many distros attached to this first thread post per usual

https://forum.puppylinux.com/viewtopic. ... 074#p50074

Changes:

LATEST: progname="weedogit.sh"; version="021"; revision="-rc2" #Revision Date: 26Aug2022

# NEW: Mabox Linux, Sparky Linux (many variants)

See here for Mabox live fix: https://forum.puppylinux.com/viewtopic. ... 351#p65351
User/Pass for Sparky are root/root and weedog/weedog (root user login is a bit weird)

Now the automated grub_config.txt provided stanzas include option of using detected UUID or detected LABEL. Works fine in my tests with grub2 (label won't work if no label of course, and will confuse system if two fs with same label...), but don't know if the grub4dos menu.lst LABEL stanza works or not since I don't have grub4dos on my machine to test it.

02x IS A MAJOR NEW VERSION RELEASE. Main change is that majority of upstream distro URLs are now auto-scraped from the web. This is experimental and the web-scraping is simplistic and could do with improvement. In practice, around one third of the current handled distros still need their download URLs manually updated (like previous weedogit releases) when required. I found these too difficult to quickly/reliably/easily auto-scrape. Feel free to provide scraping recipe if you can work some out for these... or improved scrape code for the others. If auto-scrape ever fails, you can still use manual URL assignment as per previous weedogit.sh releases.
# Currently the below following continue to need manual URL updates: Pop-os, Zorin, Garuda Sway,
# tinycorelinux, Ubuntu, Linux Mint, Linux Lite, Kodachi, 4MLinux, Xubuntu, Lubuntu

Also, the grub-config suggestions have been automated such that the suggested grub stanzas should work without alteration - the bootdir name (whatever you choose to use) of the directory you run weedogit.sh from should now be correctly auto-placed in the grub config stanza as should the actual UUID of the partition you have that bootdir stored in at time of the build.

NOTE: Only did very quick test to see that Mabox booted and logged in okay (and manually fixed the timezone issue) and a quick build/login (user:pass of weedog:weedog) of Sparky minimalgui - haven't tested any of the other Sparky versions.

wiak wrote: ↑Fri Aug 26, 2022 12:21 pm

TerryH wrote: ↑Thu Aug 25, 2022 3:45 am

There was/is one issue which I have had to use a work around. For some reason the timezone change is not being retaied on a boot/reboot. I have checked the upper_changes /etc/localtime, from another running installation and it is correct, but on boot it has changed back to being a link to /usr/share/zoneinfo/Etc/UTC[/i].

@TerryH
Ok, I just booted, set my timezone with the Mabox config gui app. I then opened /mnt/my_boot_dir in filemanager and looked inside upper_changes and all was correct. I then rebooted, and as you say, the link (which was correctly saved in upper_changes persistence folder) gets changed by Mabox itself on reboot...

I tracked it down: on boot the Mabox linux runs the script: /usr/bin/mabox-live and that calls another wee script called /usr/lib/manjaro-tools/util-live.sh and it is that latter script that resets timezone back to default live link, which isn't what we want.

What I did to stop that behaviour is that first I set up my timezone and everything else the way I liked it and then opened file /usr/bin/manjaro-live and commented out the line:

[[ -r ${LIBDIR}/util-live.sh ]] && source ${LIBDIR}/util-live.sh

Don't know if there will be any side-effects from disabling that call to util-live.sh, but seemed to work fine. At least you know where to look if any other issues relating to it being a live iso and having auto-change scripts...

Thanks, I looked at the /usr/lib/manjaro-tools/util-live.sh and considered just commenting out the creation of the link for /etc.localtime. Then on reading further, decided that just not running it as you did is probably appropriate, as all that is is doing is setting up configs and such, which is already contained in the upper_changes perstistence, so I'm going to do as you have done and just not run that script. I'll have to remove the fix I put in the autostart to replace the link.

Once again thank you for this continued development.

@wiak I noticed elsewhere that you said you had received no feedback on pupit01.sh. So I take this opportunity to do so.
Thank you for providing this script, as although there are other ways to frugal install puppies, this convenienlty provides a selection to quickly try out, which is what I'm doing, slowly. The selection covers several I am interested in, but clearly there are many variants, not necessarily being maintained or developed. I've tried some, and some of the download links were not working, so found correct ones and updated the script and proceeded fine after that. If I get time, I'll document the new links as I find them, if that is useful for anyone.
As weedogit.sh has just got better and better for non puppies, I tend to get sucked in to the novelty of frugally installing other distros, thus neglecting puppy explorations.
Although I am really happy with KLV_Airedale (via weegogit.sh) I am looking for a quick loading small puppy (faster than galliumos) that just works without too much set up on my old machine, so trying out the range you provide is a way forward.
I know you'll have little time to maintain this script, particularly if little used, but wanted to say that your efforts are appreciated.

Quick question, can this script be adapted to work with dog house variants, e.g Fatdog?

Phil_54 wrote: ↑Mon Aug 29, 2022 9:45 am

As weedogit.sh has just got better and better for non puppies, I tend to get sucked in to the novelty of frugally installing other distros, thus neglecting puppy explorations.

This is a definite drawback! I too get a bit hooked trying out (using precious time) the upstream variants via this quick to frugal install method.

Phil_54 wrote: ↑Mon Aug 29, 2022 9:45 am

Quick question, can this script be adapted to work with dog house variants, e.g Fatdog?

I think I've done so in the past, but not published weedogging Fatdog. My view was that Fatdog had plenty good frugal install facilities of its own so no need (despite the growing weedogit quick-try convenience). Originally I only included one Pup in weedogit and that was Vdpup, because I wanted more than frugalify offered, and other Pups have flexible Puppy initrd anyway (same goes for DebianDogs, which are perfectly full-featured in their own right).
You may have been asking more about using pupit.sh to do standard Fatdog installs - I would think it could be tailored to do that - the result is pure Fatdog then of course - just an automated frugal install of it - different ways to install Fatdog though since I believe it has various initrd's of its own (including everything embedded in huge Fatdog initrd).

Yes, I'm short of time, so basically concentrate now on three things:

1. Development/maintenance of the WDL initrd, which is the heart of weedogged scripts (and also what KLV-airedale uses anyway).
2. Development/maintenance of weedogit (though that is secondary since WDL initrd is the core).
3. The 'build scripts' that can be used to build:
a. the WDL initrd
and
b. a user-plugin-based rootfilesystem used with WDL initrd (rockedge uses that build rootfilesystem script, with a big plugin for it that he designs himself, to create the core root filesystem for KLV-airedale, but then he add in with forum member contributions a lot of scripts from DebianDogs and Puppy Linux itself (from anywhere on the forum in fact... hence the Kennel Linux name, and Void since using upstream Void Linux package manager).

Adding to weedogit.sh has become easier and easier since lots now automatic, so I enjoy doing that despite the time it sometimes involves.
Working on WDL initrd development is complex, difficult, and tricky (easy to break what works); I am doing most work on that right now as it happens
The build scripts have suffered due to my time shortage - I occasionally do a bit of maintenance to them, but taking too long to finish them 'again' prior to getting round to publishing their next release.

Once I have done all of the above I intend sitting back and relaxing for a while. Pupit.sh is unlikely to be looked at again by myself for quite a while, but it was intended to be a simple script that users could easily keep working and with changed URLs - I could improve it a bit of course in line with a few of the improvements that ended up in weedogit.sh, which has proved very useful to myself personally whatever anyone else does with it (but yes, it is a real distraction/time-waster cos some of these upstream distros are really fascinating).

A new version of WDL initrd (ver 6.00-rc1) has just been released and will be automatically used in most all new weedogit.sh builds.

This is the first development of WDL initrd for over 5 months. Note that you do not need to download any new weedogit.sh script - that has not been changed for now - that current script will already auto-download the latest WDL initrd.gz anyway. And none of this post is important or applies to you if you continue to use weedogit.sh to build onto Linux-formatted partitions.

You can now store MOST weedogged distros on vfat (such as usb stick) or ntfs partitions via a savefile image for save persistence if you wish alternative to current save folder on Linux formatted partition, but you must still let weedogit.sh BUILD the distro on Linux format partition or in tmpfs RAM space (if you have enough RAM).

In practice, you don't need to do this. Building on Linux format partition works same as before and probably preferred usually anyway.

I had almost run out of Linux formatted space on my computer, but had tons of ntfs space left on my current business-machine, which is why I did the following WDL initrd development - adding savefile persistence support (which is a very simple but hopefully useful few-lines-of-extra-initrd-code addition):

Details of how the new savefile feature works (and how to use it) is given at following KLV-airedale related link, but applies to most any of the weedogit-created distros to a large extent too: https://forum.puppylinux.com/viewtopic. ... 746#p65746

As you probably know and understand, the weedogit process is able to make most any upstream distro and/or most any pre-created root filesystem able to be booted as a frugal install. That capability is thanks to the special general purpose WeeDog (WDL) initrd, which was designed to work with most any root filesystems (and some other distro rootfilesystems via a few 'tweaks' to make them work in a more general-purpose manner). The end result is a frugal installed distro that has all the sfs load and RAM mode capabilities of any WeeDogLinux distro.

The new ver 6.00-rc1 WDL initrd includes support for savefile persistence method for the first time. Generally speaking, the long-supported save folder persistence method is to be preferred over savefile images for various reasons. However, you cannot use save folders when the underlying boot partition does not have a Linux format (such as ext4). Hence my reluctantly, finally, adding the small amount of extra code to the WDL initrd to alternatively allow savefile images since these can be used to provide save persistence when a frugal install is made to an ntfs partition or a vfat partition (such as a vfat formatted usb stick). NOTE WELL, however, that weedogit.sh still requires any build to be made to a Linux formatted partition (or tmpfs in RAM), but you can if you wish then move the whole frugal install folder of MOST, but not all, of weedogit created-frugal-installs, over to a vfat or ntfs partition if you wish, along with a pre-made savefile image named <anything>.ucimg (for example: upper_changes.ucimg).

But many of the weedogit builds will need a little bit of extra work prior to copying over to vfat or ntfs as explained (to the experts amongst you) here:

1. Neither vfat or ntfs support Linux-style symlinks/permissions in a directly weedog usable way, so the upper_changes folder created during weedogit.sh build will need to be copied into a suitable pre-made Linux formatted savefile PRIOR TO copying across the whole frugal install folder to vfat or ntfs partition

2. One or two of the weedogit-created distros include a special uncompressed 'tweak/fix folder' which may need to be converted into squashfs form prior to copy to vfat or ntfs format partition. There is a chance it will work as is, but I haven't tested that yet; depends if symlinks are involved and maybe permission issues, but I suspect might work anyway. Making it a numbered .sfs will work though, but not so easy to manually modify the tweak thereafter of course.

3. There may be a few other minor items I haven't thought about that need similar treatment, but I can't think of any. Main thing is to remember that single files are fine but symlinks within folders probably are not when installing onto vfat or ntfs partitions.

4. Weedogged distros savefile mechanism will not work if kernel is less than version 5.15 because I am relying on the new ntfs3 support in recent kernels (rather than having to put ntfs-3g into the initrd itself).

In practice, there is therefore hardly any manipulation (if any) involved. Just try a weedogged distro on a usb vfat stick or a ntfs partitioned disk if you wish and report back success or failures. You will need to adjust the UUID and similar information in your grub-related config file of course if you are booting from other than the original directory the weedogged distro was made in.

REMEMBER: the weedogit.sh script still needs to make its original build on a Linux formatted partition (or in RAM/tmpfs, e.g /tmp, if you have sufficient space for such a build there).

you had received no feedback on pupit01.sh

In my understanding the nature of pups/dogs is ready for frugal-boot with persistence saving (p-s) and run as root. EasyOS3.4.5 works fine also as frugal with p-s.
Why to convert?
I see fiew dogs capable to boot direct from ISO with p-s. It is something relative new.

The same think with weedogit, I will never convert
Mxlinux. It is already a complete package. FromISObooting/Frugalbooting with p-s.
Porteus5 is small and fast with special useful feature (changes-ro and extramod). Working FromISObooting/Frugalbooting with p-s.
Wifislax64-v3.0 Frugalbooting with p-s. Not solved yet how to boot it FromISO with p-s using internal HDD.

Weedoged Linux OS sofar:
- Spirallinux & LXLE
- 4Mlinux, very interesting, be ready with big HDD space.
- RegataOS, tested some games, Fullinstall is the best way.
- Kodachi, a lot of security features but too big and slow.
- Archman/Endeavour/Mabox, almost the same taste with some wifi problem.

A lot of problems, wifi connection is on/off after some minutes, some I can not solve it.
Sparky, wifi problem
Syslinux, slow shutdown/reboot (2-3 minutes) & wifi problem
Xubuntu & Linuxlite, very slow booting/shutdown/reboot
Tails, big & wifi problem
Manjaro, played less than 1 hour, upper-changes > 11 Gb, wifi problem
Makulu, slow & big, wifi problem
bunsen litium, wifi problem
Austrumi, EXEgnulinux, video resolution problem

Gecko. weedoged without success.

It would be nice if weedogit has a feature like porteus boot stanza "changes-ro" to stop p-s uncontrollable from growing.

weedogit.sh, which has proved very useful to myself personally whatever anyone else does with it (but yes, it is a real distraction/time-waster cos some of these upstream distros are really fascinating).

Yes very useful & fascinating especially for multiboot FromISO/Frugal with p-s (using internal HDD & still grub4dos sofar).

esos wrote: ↑Sun Sep 04, 2022 10:04 pm

you had received no feedback on pupit01.sh

In my understanding the nature of pups/dogs is ready for frugal-boot with persistence saving (p-s) and run as root. EasyOS3.4.5 works fine also as frugal with p-s.
Why to convert?

pupit.sh does not convert at all - it was just written as a convenience script to install pure Puppy Linux distros in a semi-automated manner. Nothing is weedogged in pupit.sh! As you say, Puppy Linux works fine in frugal install mode anyway, so no need to convert. Yes, weedogit.sh can convert Puppy to use weedog initrd instead of the standard puppy one, but no need to do that - just for fun, or if you happen to prefer weedog initrd overlayfs facilities. Different initramfs designs generally provide different more or less flexible save persistence facilities though, but certainly, overall, there is no real point to convert if happy with original.

Like everything in Linux, sometimes it is nice to have option of alternative components, including different initramfs - DebianDogs, for example, generally use modified Porteus boot initramfs for their layering facilities, but can also use initramfs (a couple of types I think) from Debian live.

In terms of install size. No attempt is made by weedogit to recompress core filesystem usually. It can be done (i.e. mksquashfs) - weedog initrd can use either uncompressed filesystems or squashed filesystems or a mix of these (which is a particular advantage of WDL initrd sometimes - in fact that is the only reason I'd weedog some distros that already can be frugal installed by their own initrd arrangement - they generally require all filesystems to be in squashfs format and WDL initrd does not have that requirement).

But weedog does not change the underlying root filesystem much if at all - so any wifi problems and so on are nothing to do with weedogit per se. Personally wifi worked fine on all the distros I've tested via weedogit - main issue for me has been the occasional login password not working! (because some distros official initramfs sets that up for them so weedogit has to do that instead).

There is a read-only changes mechanism in weedog (WDL initrd), but it is so long since I tested it I have no idea if it is working correctly at the moment or if at all anymore. It is w_changes mode:

w_changes=no_uc1

as far as I remember. If it no longer works, I'll look into fixing it some day - but low priority for me in long list of todos.

Aside from mksquashing their parts, save changes is always uncompressed on all distros so end size of persistence save folder nothing to do with weedogit actually, which is basically just providing a general purpose initramfs for flexible overlayfs frugal-style boot.
i
EDIT: quickly tried no_uc1 mode, and didn't boot properly - been so much work done on changes code in the initrd I must have broken it... later... well, maybe not broken - just read the code - X desktop probably couldn't work with it. Are you sure you are not looking for the RAM modes, main one being:

w_changes=RAM2

that loads up the save folder but does not write back to it (unless a special save2flash utility is used to do the rsync back - a utility for doing that with WDL initrd can be found in KLV-Airedale, but it is not included by weedogit.sh, however RAM2 load still works perfectly well - may be same thing as the porteus option you describe?)

what is porteus 'extramod' for, by the way. In weedog you can store addon sfs (or in uncompressed form) in many different places and they will all be found if so instructed: you can even store some sfs addons inside the initrd itself, or on other partition directory if you so wish. Again, I've not used these extra facilities much: w_altNN is for alternative addon locations (but initrd is searched automatically for sfs addons in there):

Optional w_copy2ram, to copy all NNsfs, NNdirs, w_rdshN.plug to RAM,
Optional w_changes=[option] where option can be (uc is upper_changes):
media for uc saved direct to media (such as hard disk),
RAM0 for uc in RAM but external media uc contents not included at all,
RAM1 for uc in RAM but external media uc contents copied in,
RAM2 for uc in RAM but external media uc highest layer RO loopmounted,
/mnt/partition/dir for alt direct to uc media location,
no_uc0 or no_uc1, are only for rare special cases - refer to main docs.
Optional w_altNN=path2dir for alternative location for NNsfs/dirs.

Thanks for the long explaination about pupit.

I agree the wifi problems 100% are nothing to do with weedogit. Just wondering, I have no wifi problem with pups/dogs/MX/Porteus/Wifislax etc. to connect to internet. Find the network name, enter the password and all set (nothing drop wifi connections or adjust something).

w_changes=RAM2 can be found in KLV-Airedale.
Yes I tested it a while ago. The problem is 10 seconds default save, if I miss it means saved junk files already somewhere and undo is not an option. It would be nice if I can change the default to UNSAVE that I can redo it anytime I want. I do not know yet save2flash function & how to use it.
EasyOS has the feature pupmode13 (savesession) but it is not for me due to video resolution problem.

w_changes=RAM1 is similar to change-ro, but RAM1 will delay the booting-process in very long time:
1. maybe the system can not find right away where is the upper_changes location.
2. upload time the upper_changes to ram
3. could be my G4D boot stanza is not correct.
Change_ro is flowless no delay at all.

Extramod is useful for direct booting from ISO to load extra modules anywhere outside the ISO.
It is similar to .sfs.

esos wrote: ↑Tue Sep 06, 2022 4:08 pm

[1]w_changes=RAM2 can be found in KLV-Airedale.
Yes I tested it a while ago. The problem is 10 seconds default save, if I miss it means saved junk files already somewhere and undo is not an option. It would be nice if I can change the default to UNSAVE that I can redo it anytime I want. I do not know yet save2flash function & how to use it.

[2]EasyOS has the feature pupmode13 (savesession) but it is not for me due to video resolution problem.

[3]w_changes=RAM1 is similar to change-ro, but RAM1 will delay the booting-process in very long time:
...

[4]Extramod is useful for direct booting from ISO to load extra modules anywhere outside the ISO.
It is similar to .sfs.

1 (and 2). That is news to me. w_changes=RAM2 effectively mounts your existing save folder and new session saves are all made to RAM when in that mode. I do not provide save2flash automatically as yet with weedogit builds, so it is only in KLV-Airedale (for WDL-based distros). However, fredx181 implemented the mechanism and I do not think he made it save at all unless you manually instruct it to via the save2flash command. i.e. I don't think KLV has any such 10 seconds default save - the save time is left entirely up to you; I think you are confusing things with Puppy Linux, which can I think provide a default save time. I may be wrong about KLV - but I just tried it and no default save2flash going on in my test.
w_changes=RAM2 with save2flash in KLV is pretty much same in result as Pupmode 13.

3. Yes. w_changes=RAM1 is only intended for use with very small save folders by design. It actually results in a physical copy of the media upper_changes save folder into RAM, and thus very slow method indeed if you save folder is allowed to become big at all. Generally not so useful therefore; instead use w_changes=RAM2 for the no save back situation you desire - it works on all weedogit distros (but as I said, no save2flash utility provided thus far except that already built in for KLV-Airedale only).

4. Like I tried to explain, WDL initrd (any weedogit distro) can use kernal argument w_altNN=path2sfs to always include extra addon sfs modules no matter where you wish to store them on your system - will work if booting from iso too.

esos wrote:

w_changes=RAM2 can be found in KLV-Airedale.
Yes I tested it a while ago. The problem is 10 seconds default save, if I miss it means saved junk files already somewhere and undo is not an option. It would be nice if I can change the default to UNSAVE that I can redo it anytime I want. I do not know yet save2flash function & how to use it.

For KLV-Airedale when booting with w_changes=RAM2 : To explain a little about the save2flash mechanism (save at shutdown or save on demand):
- Run save2flash to save session on demand (during a session) it's the /usr/bin/save2flash script.
- A dialog will appear at shutdown to choose between Save or No Save, waiting 10 seconds will save the session. It's the script /usr/local/bin/snap-ex .

If you want default "No Save" (waiting 10 sec. does NOT save), replace the content of /usr/local/bin/snap-ex with the following:

#!/bin/bash

if grep -q "w_changes=RAM2" /proc/cmdline || grep -q "w_changes1=RAM2" /proc/cmdline; then
    if [ "$(mount | grep /mnt/layers/uc_ro | grep /dev/)" ]; then
dialog --timeout 10 --no-label "SAVE" --yes-label "NO SAVE" --yesno "Press ENTER key to NOT save session...
Or, wait 10 seconds to not save the session...
Or, press TAB then ENTER to Save the session..." 0 0   >/dev/console
     [ $? -eq 1 ] || NOSAVE="yes"
    
  if [ "$NOSAVE" != "" ];then
echo 
echo "[1;31m""Session not saved""[0m"

  else
echo
echo "[1;32m""Saving session...""[0m" 
/usr/bin/snapmergepuppy 2> /dev/null   
  fi

    else
echo "[1;31m""Directory /mnt/layers/uc_ro not connected. Session cannot be saved""[0m"
    fi
fi