Puppy Linux Discussion Forum

KL/FirstRib-based distros have a lot in common; they are all booted with same FR initrd functionality and thus most system scripts they use are identical.

A major plus of FirstRib design is its ability to use either sfs addons, uncompressed addons, or a mixture of both and can store these in different partitions/disks if you really want to...

Also, when using skeleton FR initrd.gz, with a huge-kernel type vmlinuz, where modules are typically put at layer 00 (either in sfs or uncompressed dir form of course) and firmware at layer 01 we quite often might end up using same vmlinuz, 00 modules and 01 firmware along with that same skeleton initrd.gz as well as sometimes same KLgtkdialog sfs and more besides...

But you may not have realised that because FirstRib doesn't care what the addon filenames are (aside from their 2-digit number) no matter what KL/FR distro you are using, you can actually share most of these same components between your bootable KL distros with only the 07 main root filesystem (or whatever layer you are putting it at) different. Actually, you could even share that!!! for the case where you want to boot same distro but with a different upper_changes, for example... the mind boggles...

For example, attached is my KLV-Airedale bootfrom directory (which I am currently posting from in fact).

Note that everything is a symlink apart from the upper_changes folder...!!!

I have all the actual components in a different directory on the same partition. In fact with a suitable w_altNN= kernel line you could even symlink to components stored on totally different disks and partitions... including some parts on removable devices if you wish. There is really no limitation to this FR facility.

If you want to try the idea, for simplicity just create a directory in / directory of the bootfrom partition; I used the name "shared", but you can call it anything you like.
Then put all the main bootfrom components into that "shared" directory, and from terminal opened at say, KLV-Airedale bootfrom directory make the symlinks (or use rox to do it... In fact rox is really great for making this symlink-type structure though simple script to make it is much more convenient once written):

ln -s ../shared/vmlinuz vmlinuz
ln -s ../shared/initrd.gz initrd.gz
ln -s ../shared/00modules_whatevername.sfs 00.sfs  # note that only the 2-digit numeric (and the .sfs in this example case) is important in the filename here
ln -s ../shared/01fireware_whatevername.sfs 01.sfs
ln -s ../shared/07KLV-Airedale.sfs 07.sfs
ln -s ../shared/10KLgtkdialog_whatevername.sfs 10.sfs
ln -s ../shared/20pipewire.sfs 20.sfs

etc etc etc

Of course if the addon was instead an uncompressed directory, for example, ../shared/myaddonA, that could be linked in similarly but without the .sfs extension (since not an sfs...):

ln -s ../shared/myaddonA 24

# where in this example I am placing myaddonA at layer 24 (user-to-decide...)

Of course there is no reason to store them all in that single "shared" directory. Could store the different parts where you like. For example, a nice arrangement would be to store alternative huge-kernels in separate directories of their own - a simple frontend utility could be used to reconfigure/choose which components you actually want involved on boot...

So this is a huge advantage of a typical FirstRib-based frugal install compared to say booting from ISO with Ventoy and especially when using same huge-kernel to boot several KL distro variants such as KLA, KLV, KLU and whatever... You only thus need ONE copy of vmlinuz, initrd.gz, 00modules, 01firmware, 10KLgtkdialog, 20pipewire and so on!!! yet have all the KL distros able to boot using that!!! And even same KL distro if you want but with totally different upper_changes used with each. Now that is powerful and a true way to save distro storage size if that is really what concerns the user...!

EDIT: Note that you could make similar arrangements for using a multitude of KL distros (or variants with different upper_changes) for use with Qemu virtual machines and so on. I haven't tried this: but seems to me since lower layers are read-only it should be possible to share multiple components in parallel running Qemu distros as well. Of course each running virtual machine still needs its usual RAM allocation, but disk storage size can be minimised by this FirstRib shared-component ability.

Yes this is indeed interesting, as I do frugal installs on internal hard drives and have to be prudent with how much storage space I'm using.

So if I'm following this logic, basically all it requires is creating a boot stanza in the boot loader, and a directory where upper_changes can be created, while the rest of the files can be symlinked.

With that logic I can take a kernel/firmware/modules combination and store it somewhere and point to it, and then point to the rootfs. Essentially I can set up an experimental distro directory with one boot stanza, and switch out my experiments by linking files into it.

geo_c wrote: ↑Tue Sep 19, 2023 2:55 am

Yes this is indeed interesting, as I do frugal installs on internal hard drives and have to be prudent with how much storage space I'm using.

So if I'm following this logic, basically all it requires is creating a boot stanza in the boot loader, and a directory where upper_changes can be created, while the rest of the files can be symlinked.

With that logic I can take a kernel/firmware/modules combination and store it somewhere and point to it, and then point to the rootfs. Essentially I can set up an experimental distro directory with one boot stanza, and switch out my experiments by linking files into it.

Correct. It allows booting all your KL distros (no matter the type KLU, KLV, KLA etc) with same kernel and major addon components, you only need to store one copy of all of these. wd_grubconfig put in each bootfrom directory will work as usual to provide the exact usable grub stanza for each and every one of your distros thus arranged. Try that with a different distro type than KL/FirstRib; it can't usually be done since they require special/different filenames for their component parts including modules/firmware parts and so on and FR also doesn't care if addon is a simple folder (or squashed up) as long as given a 2-digit filename to signify layer you want it at.

Anytime you want to try something new it is simply a matter of creating an empty directory, giving it a 2-digit number and putting whatever files you want in it. That test addon can also be shared and tested in all you KL distros by this method.

It is simple. It is ultra-powerful both for dev experiments but also just for casual use by any user.

For those interested in Linux utility app writing as a useful to everyone hobby, just think of the frontend useful utilities (commandline and GUI) that could be created, but it is all very simple (trivial even) to arrange manually anyway.

In the past I provided a single script (weedogit) for converting a mainstream distro into a FR initrd bootable version of the same. Much of this also applies to such FR booted distros and also to my more recent KLfull2frugal creation. I'll get back to producing improved version of weedogit (albeit now renamed back to recognise original project as "firstribit") early next year.

Actually, FirstRib distros have been able to do this since the year of early FR initrd creation, which is 2019, but been too busy to use and describe all the possibilities, but now that there are many KL/FR variants you can see how powerful/useful this ability is I think.

Here is my current set up of 12 independently bootable KL distros using this powerful FirstRib facility.

Total size on disk of all of this is 3 GiB; that works out at 3/12 = 256MiB per distro each having their own upper_changes directory.

Each KLV-Airedale can, for example, be used for its own purpose and so on.

Not bad having twelve distros occupying such a small installation space hmmm? And these are not Puppies - these are full multi-user official package manager capable upstream compatible distros with all the usual FR initrd frugal install flexibility including leading edge Fedora Rawhide release:

save-on-demand persistence, run everything from RAM if you wish, up to 99 addon layers where each addon can be ordinary directory and/or a compressed sfs filesystem and so on and so forth. No extra space required to add hundreds of more of same varieties of distro (aside from empty directory size and so on and until you start filling up their individual upper_changes folders.

So could have, for example, a hundred such distros if you want to experiment like that in pretty much same 3 GiB total install size... And can use same/similar arrangement for Virtual Machine use with Qemu saving tons and tons of image storage space.

Almost SCARY eh, especially when can include uncompressed ordinary directory layer addons that can also symlink in other bits and pieces or be used/symlinked-in as some alternative individualised addon component (mind boggling yet simplicity itself at the same time)?!!!

Note that a single frontend build script could build this whole structure for you and as many clones of the structure you desire and on whatever boot media you wish. Could also be used with previous weedogit (now firstribit) style mainstream builds; could have single shared Linux Mint root filesystem, but used many times in same fashion with FR initrd layer addons (to provide gtkdialog, filemnt, whatever...) and own independent upper_changes folders for each (so totally independent Linux Mint distros in effect). All in much the same storage size as that one Linux Mint install (or whatever).

NOTE also, that you could also share rollback upper_changes folders (in compressed or uncompressed form or mix of these) for any specific distro type as long as you keep them in correct package manager database required sequence. Can still then have separate read/write upper_changes folder allowing thereafter the overall distros to be different from each other... So some such distros could be used in 'pristine' form, but others could share sequence of rollback changes folders (or different but still in correct sequence rollback folders for earlier 'snapshots'). Of course read/write upper_changes folders can grow huge if you add to them a lot, but a shared read-only NNupper_changes folders can be used by many compatible distro variety without overall storage size increase. Most things we tend to want to experiment with tend to be quite small.

NOTE2: I do need to modify wd_grubconfig if building a subdir within subdir structure like this; the utility wasn't designed for that nested structure so manual adjustment to grub stanza needed at the moment here. EDIT: see here for new wd_grubconfig that may work for this 2 level subdir case and previous 1 level subdir case (not much tested): https://forum.puppylinux.com/viewtopic. ... 053#p99053

NOTE3: As I said in post above, multiple rox windows are great for making symlinks for this manually and once a set of symlinks has been created for example for first KLV-Airedale you can just use rox to copy the symlinks to second instance. Again, better is a dedicated script to create the structure but for a small number of such sharing distros manual construction is fine.

I understand the flexibiity you are showing on a well structured partition. I agree: NICE!

Now, a knowledgible user needs to create a bootable with

• a GRUB start partition,

• a partition with /boot/GRUB.cfg,

• and a partition that has a folder setup as you describe.

  

  Startable for KLs initial distro package

  KL_many_12distros.jpg (20.5 KiB) Viewed 2407 times

This 'could' be made and described as a "Startable for KLs" distro that boots with an offering to launch any one of the initial KLs on the disk. The "Startable for KLs" distro would be a model as it would contains these things; thus the user then has a working model to build upon this foundation described in this thread's OP.

Once the model is set, future efforts would merely add to the model and booted by a mere GRUB selection.

In fact the model could also contain a builder which when run could create a new folder of another of the KLs that would come down the pike.

Am I seeing this correctly?

Grub2

#

insmod part_acorn
insmod part_amiga
insmod part_apple
insmod part_bsd
insmod part_dfly
insmod part_dvh
insmod part_gpt
insmod part_msdos
insmod part_plan
insmod part_sun
insmod part_sunpc

set gfxmode=800x600,auto # 1280x1024,1024x768,800x600,640x480 possible value
set gfxpayload=keep

insmod efi_gop
insmod efi_uga

insmod all_video
insmod video_bochs
insmod video_cirrus
insmod gfxterm
insmod png
insmod jpeg
terminal_output gfxterm

insmod ext2
insmod f2fs
insmod ntfs
insmod exfat

insmod loopback
insmod iso9660
insmod udf

background_image /boot/splash.png

#selinux=0 KLF-Rawhide
set default=0
set timeout=5
set fallback=1

#https://help.ubuntu.com/community/Grub2/Displays
set menu_color_normal='light-gray/black'
set menu_color_highlight='black/cyan'
#text no sel/fond ecran
set color_normal='light-green/black' 

if [ $grub_platform = 'efi' ]; then
  loadfont /boot/grub/fonts/terminus-b18.pf2
  set gfxmode=auto
  terminal_output gfxterm
fi

menuentry "KLA-OT2baseCE-3.0 RAM2" {
  insmod ext2
  search --no-floppy --fs-uuid --set fbb65611-fb5c-4b0c-8f21-331dabc54d23
  linux /KLA-OT2baseCE-3.0/vmlinuz w_bootfrom=UUID=fbb65611-fb5c-4b0c-8f21-331dabc54d23=/KLA-OT2baseCE-3.0 w_changes=RAM2
  initrd /KLA-OT2baseCE-3.0/initrd.gz
}
menuentry "Puppy vanilladpup 9.2.20 - Copy SFS files to RAM" {
  insmod ext2
  search --no-floppy --fs-uuid --set=root fbb65611-fb5c-4b0c-8f21-331dabc54d23
  echo "Loading vmlinuz"
  linux /Puppy-vanilladpup-9.2.20/vmlinuz net.ifnames=0 pmedia=usbhd pdrv=fbb65611-fb5c-4b0c-8f21-331dabc54d23 psubdir=/Puppy-vanilladpup-9.2.20 pfix=fsck,fsckp TZ=MSK-3
  echo "Loading initrd.gz"
  initrd /Puppy-vanilladpup-9.2.20/initrd.gz
}
menuentry "Vanilla Dpup 10.0.27-xwayland - Copy SFS files to RAM" {
  insmod ext2
  search --no-floppy --fs-uuid --set=root fbb65611-fb5c-4b0c-8f21-331dabc54d23
  echo "Loading vmlinuz"
  linux /Vanilladpup-10.0.27-xwayland/vmlinuz net.ifnames=0 pmedia=usbhd pdrv=fbb65611-fb5c-4b0c-8f21-331dabc54d23 psubdir=/Vanilladpup-10.0.27-xwayland pfix=fsck,fsckp TZ=MSK-3
  echo "Loading initrd.gz"
  initrd /Vanilladpup-10.0.27-xwayland/initrd.gz
}
menuentry "KLV-Bspwm RAM2" {
  insmod ext2
  search --no-floppy --fs-uuid --set fbb65611-fb5c-4b0c-8f21-331dabc54d23
  linux /KLV-Bspwm/vmlinuz w_bootfrom=UUID=fbb65611-fb5c-4b0c-8f21-331dabc54d23=/KLV-Bspwm w_changes=RAM2 
  initrd /KLV-Bspwm/initrd.gz
}
menuentry "KLV-Bspwm-1.4 RAM2" {
  insmod ext2
  search --no-floppy --fs-uuid --set fbb65611-fb5c-4b0c-8f21-331dabc54d23
  linux /KLV-Bspwm-1.4/vmlinuz w_bootfrom=UUID=fbb65611-fb5c-4b0c-8f21-331dabc54d23=/KLV-Bspwm-1.4 w_changes=RAM2 
  initrd /KLV-Bspwm-1.4/initrd.gz
}
menuentry "KLF-Rawhide-CE RAM2" {
  insmod ext2
  search --no-floppy --fs-uuid --set fbb65611-fb5c-4b0c-8f21-331dabc54d23
  linux /KLF-Rawhide-CE/vmlinuz w_bootfrom=UUID=fbb65611-fb5c-4b0c-8f21-331dabc54d23=/KLF-Rawhide-CE w_changes=RAM2 selinux=0
  initrd /KLF-Rawhide-CE/initrd.gz
}
menuentry "KLV-Airedale-sr5" {
  insmod ext2
  search --no-floppy --fs-uuid --set fbb65611-fb5c-4b0c-8f21-331dabc54d23
  linux /KLV-Airedale-sr5/vmlinuz w_bootfrom=UUID=fbb65611-fb5c-4b0c-8f21-331dabc54d23=/KLV-Airedale-sr5 w_changes=RAM2
  initrd /KLV-Airedale-sr5/initrd.gz
}
menuentry "Bookworm Pup64 10.0.2 - Copy SFS files to RAM" {
  insmod ext2
  search --no-floppy --fs-uuid --set=root fbb65611-fb5c-4b0c-8f21-331dabc54d23
  echo "Loading vmlinuz"
  linux /BookwormPup64/vmlinuz net.ifnames=0 pmedia=usbhd pdrv=fbb65611-fb5c-4b0c-8f21-331dabc54d23 psubdir=/BookwormPup64 pfix=fsck,fsckp TZ=MSK-3
  echo "Loading initrd.gz"
  initrd /BookwormPup64/initrd.gz
}
menuentry "F96-CE_4 - Copy SFS files to RAM" {
  insmod ext2
  search --no-floppy --fs-uuid --set=root fbb65611-fb5c-4b0c-8f21-331dabc54d23
  echo "Loading vmlinuz"
  linux /F96-CE_4/vmlinuz net.ifnames=0 pmedia=usbhd pdrv=fbb65611-fb5c-4b0c-8f21-331dabc54d23 psubdir=/F96-CE_4 pfix=fsck,fsckp TZ=MSK-3
  echo "Loading initrd.gz"
  initrd /F96-CE_4/initrd.gz
}
menuentry "F96CE_XFCE_FUSILLI - Copy SFS files to RAM" {
  insmod ext2
  search --no-floppy --fs-uuid --set=root fbb65611-fb5c-4b0c-8f21-331dabc54d23
  echo "Loading vmlinuz"
  linux /F96CE_XFCE_FUSILLI/vmlinuz net.ifnames=0 pmedia=usbhd pdrv=fbb65611-fb5c-4b0c-8f21-331dabc54d23 psubdir=/F96CE_XFCE_FUSILLI pfix=fsck,fsckp TZ=MSK-3
  echo "Loading initrd.gz"
  initrd /F96CE_XFCE_FUSILLI/initrd.gz
}
menuentry "KLV_sway_pipewire-1" {
  insmod ext2
  search --no-floppy --fs-uuid --set fbb65611-fb5c-4b0c-8f21-331dabc54d23
  linux /KLV_sway_pipewire-1/vmlinuz w_bootfrom=UUID=fbb65611-fb5c-4b0c-8f21-331dabc54d23=/KLV_sway_pipewire-1 w_changes=RAM2
  initrd /KLV_sway_pipewire-1/initrd.gz
}
if [ $grub_platform = 'efi' ]; then
  menuentry "System BIOS setup" {
    fwsetup
  }
fi
menuentry "Shutdown computer" {
  halt
}
menuentry "Reboot computer" {
  reboot
}

EDIT: ignore posts below about errors in new wd_grubconfig. I 'think' all fixed now in the newest.

I've now made a new version (please test) of wd_grubconfig that I've quickly modified to also work with a bootdir that is a subdir of a subdir (i.e. 2 levels down on partition as in my KL_many arrangement in post above). Also seems fine for previous single subdir bootdir use. I haven't tested this much but the grub stanza seemed to be correct when I tried it and the distro was correctly then found and booted when using the exact stanza this new wd_grubconfig (version 2.0.0 -rc2) provided.

Fetch new wd_grubconfig using:

wget -c https://gitlab.com/firstrib/firstrib/-/raw/master/latest/build_system/wd_grubconfig && chmod +x wd_grubconfig

Once tested further I'll adopt it if no issues reported. wd_grubconfig is one of my favourite FR utilities since saves me thinking...!

NOTE that I'm using this new wd_grubconfig as a "shared' utility in above KL/FR distro sharing structure too.

For new multi-level mode help enter command:

./wd_grubconfig --help
Run this script from your FirstRib distro installation directory with command:
./wd_grubconfig  # if bootdir is of the form /dir1
or as
./wd_grubconfig 2  # if bootdir is of the form /dir1/dir2
or as
./wd_grubconfig 3  # if bootdir is of the form /dir1/dir2/dir3

For example, you might have the KL frugal installed to: /many_KL/group01/KLV-Airedale for a /dir1/dir2/dir3 type structure

In my /dir1/dir2 type structure shown earlier in this thread, I'd use command:

./wd_grubconfig 2

which would result in grub stanzas involving the likes of /KLV_many/KLV-Airedale01 and so on...

KLV-Airedale01, and so on, booted fine once I update-grub my computer grub2 install (which on my machine was installed by my Linux Mint full installation).

It didn’t boot for me because it signs the extra ( /sda2 )

menuentry "sda2/KLV-Bspwm-1.4" {
  insmod ext2
  search --no-floppy --fs-uuid --set fbb65611-fb5c-4b0c-8f21-331dabc54d23
  linux /sda2/KLV-Bspwm-1.4/vmlinuz w_bootfrom=UUID=fbb65611-fb5c-4b0c-8f21-331dabc54d23=/sda2/KLV-Bspwm-1.4 w_changes=RAM2
  initrd /sda2/KLV-Bspwm-1.4/initrd.gz
}

the one I have, it doesn’t sign and everything loads

menuentry "KLV-Bspwm-1.4" {
  insmod ext2
  search --no-floppy --fs-uuid --set fbb65611-fb5c-4b0c-8f21-331dabc54d23
  linux /KLV-Bspwm-1.4/vmlinuz w_bootfrom=UUID=fbb65611-fb5c-4b0c-8f21-331dabc54d23=/KLV-Bspwm-1.4 w_changes=RAM2
  initrd /KLV-Bspwm-1.4/initrd.gz
}

Sofiya wrote: ↑Tue Sep 19, 2023 7:14 am

It didn’t boot for me because it signs the extra “/sda2”

Code: Select all

menuentry "sda2/KLV-Bspwm-1.4" {
  insmod ext2
  search --no-floppy --label  --set
  linux /sda2/KLV-Bspwm-1.4/vmlinuz w_bootfrom=LABEL==/sda2/KLV-Bspwm-1.4 w_changes=RAM2
  initrd /sda2/KLV-Bspwm-1.4/initrd.gz
}

ah... it worked for me with UUID method. I'll have to look into it further, but no time tonight... Thanks for the report.

Hmmm... strange... it seems to be working for me. Are you using bash?

wiak wrote: ↑Tue Sep 19, 2023 7:16 am

Sofiya wrote: ↑Tue Sep 19, 2023 7:14 am

It didn’t boot for me because it signs the extra “/sda2”

Code: Select all

menuentry "sda2/KLV-Bspwm-1.4" {
  insmod ext2
  search --no-floppy --label  --set
  linux /sda2/KLV-Bspwm-1.4/vmlinuz w_bootfrom=LABEL==/sda2/KLV-Bspwm-1.4 w_changes=RAM2
  initrd /sda2/KLV-Bspwm-1.4/initrd.gz
}

ah... it worked for me with UUID method. I'll have to look into it further, but no time tonight... Thanks for the report.

Hmmm... strange... it seems to be working for me. Are you using bash?

I find it difficult to answer bash or zsh . most likely bash

wiak wrote: ↑Tue Sep 19, 2023 7:44 am

Okay, I see the issue. Somehow or other you are mounting the sda1 partition as /mnt/sda1. None of the systems I'm using do that (and nor does my wd_mount sda1 program; at least not the latest version when used on KLV-Airedale. If you happen to be using wd_mount you could check you have most recent version:

cat /usr/local/bin/wd_mount

Should say: #!/bin/sh
# wd_mount: Simple... mount tool by wiak. Licence MIT. Created 12Apr2020. Rev 0.0.3 31Jan2023

Then again you may not be using that to mount your partition anyway? Old version of wd_mount certainly would have mounted to /mnt/sda1 whereas new version mounts to /media/root/sda1 and then the new wd_grubconfig utility also works! However, I'll try and amend the code so works for /mnt/sda1 case too...

Yes, this is the problem for that case: partition_level1=`dirname "$HERE"`
The next line: level1=`basename $partition_level1`
then picks up the sda1, which is not what is wanted... sigh
I will change that logic.

KLV-Airedale also superfluous ( /sda2 )

menuentry "sda2/KLV-Airedale-sr5" {
  insmod ext2
  search --no-floppy --fs-uuid --set fbb65611-fb5c-4b0c-8f21-331dabc54d23
  linux /sda2/KLV-Airedale-sr5/vmlinuz w_bootfrom=UUID=fbb65611-fb5c-4b0c-8f21-331dabc54d23=/sda2/KLV-Airedale-sr5 w_changes=RAM2
  initrd /sda2/KLV-Airedale-sr5/initrd.gz
}

wiak wrote: ↑Tue Sep 19, 2023 8:10 am

Re-hacked and re-uploaded wd_grubconfig. Try again please. Let me know if I'm lucky...

I'm hoping works for normal one subdir case such as /mnt/sda1/KLV

and also subdir within subdir case such as:

/mnt/sda1/many_isos/KLV

or indeed the more typical (if newest wd_mount or Thunar being used on the likes of Linux Mint...):

/media/root/KLV

or

/media/root/many_isos/KLV

everything is great now

menuentry "KLV-Airedale-sr5" {
  insmod ext2
  search --no-floppy --fs-uuid --set fbb65611-fb5c-4b0c-8f21-331dabc54d23
  linux /KLV-Airedale-sr5/vmlinuz w_bootfrom=UUID=fbb65611-fb5c-4b0c-8f21-331dabc54d23=/KLV-Airedale-sr5 w_changes=RAM2
  initrd /KLV-Airedale-sr5/initrd.gz
}

wiak wrote: ↑Tue Sep 19, 2023 8:25 am

Sofiya wrote: ↑Tue Sep 19, 2023 8:20 am

everything is great now

Yes, on your system hahaha, but not quite on mine. I have to combine a couple of ideas to make it work properly in all cases...

wiak wrote: ↑Tue Sep 19, 2023 7:27 am

... I have a usb stick with LABEL Ventoy so I just made a directory KLV-Bspwm-1.4 on that and c...

Aha! A universal boot disk that boots various formats to desktop...Very Clever, INDEED!

wiak wrote: ↑Tue Sep 19, 2023 8:40 am

Sofiya, how are you mounting your sda1 partition? Is it done automatically or what utility are you using or are you doing it manually to /mnt?

on (sda1) I have Grub2

I don't mount anything, it's mounted by itself this is KLV-Airedale-sr5

@Sofiya
Okay, I've uploaded to gitlab the latest and greatest (multi-level) wd_grubconfig utility. Was a bit tricky to make reasonably general purpose no matter how the partition was being mounted, but I think the mechanism I've adopted works quite well and backward compatible with older (single level bootfrom dir) wd_grubconfig.

Time will tell. Please test.

For explanation and download see post: https://forum.puppylinux.com/viewtopic. ... 053#p99053

Removed some of my previous above posts since irrelevant at this stage and just cluttering this 'Sharing KL/FirstRib' thread

wiak wrote: ↑Tue Sep 19, 2023 11:23 am

@Sofiya
Okay, I've uploaded to gitlab the latest and greatest (multi-level) wd_grubconfig utility. Was a bit tricky to make reasonably general purpose no matter how the partition was being mounted, but I think the mechanism I've adopted works quite well and backward compatible with older (single level bootfrom dir) wd_grubconfig.

Time will tell. Please test.

For explanation and download see post: https://forum.puppylinux.com/viewtopic. ... 053#p99053

Removed some of my previous above posts since irrelevant at this stage and just cluttering this 'Sharing KL/FirstRib' thread

@wiak
Yes it works

@Sofiya@geo_c@fredx181@williwaw@Clarity@rockedge and anyone interested in experimenting with multiple KL distros... Yes, I am happy with the following:

So I decided whilst it was foremost in my mind to put 'theory' aided by manual testing into full easy auto-build practice. Not only did I want to make a multi-distro multi-instance build of as many distro instances (for multiple isos all at once) as I wanted, but to save having to run wd_grubconfig in each of their instance frugal install bootable directories I wanted to auto-create the grub_config.txt with exact immediate-to-use grub stanzas... This was a tall order and proved a bit tricky to actually script. However, with the help of my existing scripts weedogit (now firstribit), latest wd_grubconfig contents, and paper and pen and careful organised planning, I seem to have managed.

I will publish wd_multi (the creation script shortly), but right now attached is a DEMO result.

What I did for this demo is that I:

1. Created an empty directory that I named /KL_multi (the name is irrelevant)
2. Copied my wd_multi executable script into it
3. Copied in three KL isos I happened to have stored on my system: KLA-OT2baseCE-2.9.iso, KLU-jam-XFCEbase-1.0.iso, and KLV-Airedale-sr5.iso
4. And then ran my wd_multi instances creator script with argument 100 to make 100 frugal boot instances of each in their subdirectories (named with iso filename minus the .iso part):

./wd_multi 100

The result is one hundred (!!!!) independent frugal installs of each of the above isos automatically created in a few seconds with appropriate grub stanzas to boot any of their instances. They each have their own upper_changes folders so can be configured and added to individually as much as wanted.

For example, the /KL_multi/KLA-OT2baseCE-2.9/instance0 directory contains the actual extracted-from-that-iso files. All the other 99 instances (up to instance99) contain symlinks to these instance0 components per the explanation of operation I explained in post one of this thread. The attached jpeg shows the 100 KLV-Airedale instance frugal install folders.

The whole 300 frugal installs (100 for each iso) take up a total disk space of... drums roll... only 2.3GiB.

So average distro frugal install instance size is only 2.3GiB/300 which is less than 8 MiB each (yes Mega not Giga each)... I could have thousands of them even on a usb stick (until I start adding tons to their individual upper_changes folders, but can boot them all with w_changes=RAM2 save on demand mode so user is totally in control.

wd_multi script and explanation of use will follow shorty. Well, explanation of use is exactly as above in fact...

At exact moment, I'm posting from /KL_multi/KLV-Airedale-sr5/instance53

Now made 3000 (three thousand) frugal installs; 1000 each of 3 isos. Posting right now from instance: /KL_multi/KLU-jam-XFCEbase-1.0/instance754

Download info of wd_multi here: https://forum.puppylinux.com/viewtopic. ... 154#p99154

That's amazing! So are the iso's unpacked, files copied, or still in iso format?

geo_c wrote: ↑Wed Sep 20, 2023 12:40 pm

That's amazing! So are the iso's unpacked, files copied, or still in iso format?

All unpacked, normal frugal installs - all with provided grub_config.txt file containing exact working grub stanzas ready to boot. As many hundred or thousands as you may like...

wiak wrote: ↑Wed Sep 20, 2023 12:46 pm

geo_c wrote: ↑Wed Sep 20, 2023 12:40 pm

That's amazing! So are the iso's unpacked, files copied, or still in iso format?

All unpacked, normal frugal installs - all with provided grub_config.txt file containing exact working grub stanzas ready to boot. As many hundred or thousands as you may like...

And all that's being stored in the instance directories are the upper_changes I presume.

geo_c wrote: ↑Wed Sep 20, 2023 12:55 pm

wiak wrote: ↑Wed Sep 20, 2023 12:46 pm

geo_c wrote: ↑Wed Sep 20, 2023 12:40 pm

That's amazing! So are the iso's unpacked, files copied, or still in iso format?

All unpacked, normal frugal installs - all with provided grub_config.txt file containing exact working grub stanzas ready to boot. As many hundred or thousands as you may like...

And all that's being stored in the instance directories are the upper_changes I presume.

Yes, other than symlinks. Just try it - only takes a minute to build multi frugal install system from a few KL distro isos dropped in.

Could also use this to make such a build in a Qemu qcow2 disk so could quickly boot to alternative install/configurations of any of the various 'distro instances'. Easy enough in fact to just use a quick sed command to change a grub.cfg to boot alternative instances without bothering to add too many actual grub stanzas in.

It's also much more flexible than the likes of rollbacks to try out alternative app installs/configurations/desktop managers and so on.

Or just to give you a satisfied feeling, comfort glow, in knowing you have hundreds or thousands of immediately bootable frugal installed 'distros' (distro instances) sitting on your wee computer ready for action... taking up hardly any disk space. If you 'break' one, just use a different instance.

wiak wrote:

Could also use this to make such a build in a Qemu qcow2 disk so could quickly boot to alternative install/configurations of any of the various 'distro instances'

This ability is of interest for sure. I find myself in testing often in situations where quick frugal multi-installed systems created on the virtual hard drive would present a complete palette of distro systems ready to go booting from the qcow2 virtual hard drive.

Or a bunch of individual user instances each with a strong password that the user only types once instead of the standard linux security model with a bunch of users sharing one instance with a weak password they have to type over and over again.

dancytron wrote: ↑Sun Jan 07, 2024 4:46 am

Or a bunch of individual user instances each with a strong password that the user only types once instead of the standard linux security model with a bunch of users sharing one instance with a weak password they have to type over and over again.

Yes, that's an interesting scenario concentrating as it does on multi-instances for individual user rather than one instance for multi-users, which I agree seems significantly less secure in concept.

The comment about 'strong' more secure password (and thereafter no sudo passwd type usage required) also makes me think about some kind of integration of stored certificates as a high-security key for individual access. Whilst we are all used to the relative simplicity of easily forgotten passwords... secure key technology is become default in most entry to resources scenarios (including on git-related sites). I'm not particularly used to the technology, so new tricks appear painful at first, but reality is such mechanisms are probably much more convenient in the end, once established and efficiently implemented, and tons more secure of course.

"Something that you know, something that you have, and something that you are" are each a layer of security. Typing my initials over and over again is just a pia.