Puppy Commander - Puppy on its own partition with UEFI-friendly grub

[trawglodyte]

This didn't seem to belong in the Beginner's section, but I want to make clear I'm new to Puppy Linux and still trying to understand the layered filesystem and so forth. I should also make clear the concept I'm going to describe is experimental and I'm probably going about it all wrong. This isn't a guide. The purpose of this post is to see if anyone has interest in it and can give me some tips or perhaps tell me I'm barking up the wrong tree and should do this differently.

I recently learned how easy it can be to install and multi-boot with Puppy Linux on a UEFI system if you have an existing Linux distro. I think it could even be made into a script you could point at a puppy.iso which would install and add it to the grub menu, which would be a good learning project for me and something useful I could contribute.

I got to thinking maybe it would be nice to find the smallest Linux distro possible to control the grub menu. I was looking at Manjaro's minimal install, Modhi, and LinuxLite. All very capable.

But then I started thinking what would be even cooler would be a Puppy on it's own partition with UEFI-friendly grub that you could use to add or remove Puppy's on another partition easily and keep the grub menu updated to boot to any of them.

So that's what I'm playing with. I have a frugal install of BookwormPup64_10.0.4 on a 15G partition and I'm attempting to add the Debian packages I need (such as grub-efi and several others) so I can use it to frugal install/unistall other Puppy distros to a second partition.

If i understand correctly, any changes I make are only kept in my save file and do not change the main Bookworm.sfs or additional zdrv.sfs, adrv.sfs, etc.... files, is this right? And maybe that means this won't ever work? Also, I'm fundamentally de-Puppying my nice install of BookwormPup64_10.0.4 by adding these packages, right? And yes, I've already been warned about doing things the Debian/Ubuntu way instead of learning the Puppy way, but I think attempting stuff like this and accepting the risks will help me understand that.

The goal is really just to make it easier for people who want to try Puppy to do so. If I understand correctly, someone made a cool think called LICK at one point that let people try them from Windows. I think what I'm attempting to do is similar, but from a Linux distro.

I'd like the script to work on all Ubuntu/Debian based distros, but if I can also modify one Puppy to be the "Puppy Commander" installed on it's own partition to do it. That would be a bullseye for me.

Of course, I'm in way over my head. Which is where I like to be and where I learn the most.

[rockedge]

If i understand correctly, any changes I make are only kept in my save file and do not change the main Bookworm.sfs or additional zdrv.sfs, adrv.sfs, etc.... files, is this right?

Yes. Save folder or Save file contains the changes. The actual system is read-only. To modify the SFS file systems it would take decompressing the squash file, making modifications and then squashing it back again.

[wizard]

Looks like you have reached the "AH HA" moment where you've found some of the real power in Puppy Linux. Many of the forum members do exactly what you describe, MS Windows, big Linux versions, multiple Puppy's all living happily on the same computer. Kind of like magic.

I've found using a spare hard drive or computer to experiment on is a great learning tool.

wizard

[trawglodyte]

Looks like you have reached the "AH HA" moment where you've found some of the real power in Puppy Linux. Many of the forum members do exactly what you describe, MS Windows, big Linux versions, multiple Puppy's all living happily on the same computer. Kind of like magic.

I've found using a spare hard drive or computer to experiment on is a great learning tool.

wizard

I have two hard drives and that's what I'm doing right now. I realized I was making this way harder than it needs to be. I don't have to significantly change BookwormPup64_10.0.4 at all, or even put it on a seperate partition from the other pups. It's existing EFI grub will be just fine and I can add the other pups. I think I can add the Windows Boot Manager too, if someone with Windows wants to multi-boot from grub with a Puppy or two... or 6, 20, whatever.... (-;

[wizard]

I think I can add the Windows Boot Manager too

Not necessary. Here's an overview of how it can be done:
-create NTFS partition for Windows
-create Ext4 partition(s) for other Linux versions (can also be used for Puppy installs)
-create Ext3 or 4 partition for Puppy Linux versions

-install Widows
-install other Linux
-install all Puppy Linux

-use grub2config to install grub

You'll probably have to do some editing to your grub.cfg file, but this will get about 90% set up.

wizard

[williwaw]

The goal is really just to make it easier for people who want to try Puppy to do so. If I understand correctly, someone made a cool think called LICK at one point that let people try them from Windows. I think what I'm attempting to do is similar, but from a Linux distro.

wizard's suggestion is simple enough for someone who wants to install windows. if you mean windows as is it usually found preinstalled.... more hoops to jump thru.

but from a Linux distro.

would be a simpler case of course. Have you looked at viewtopic.php?t=644

a minimal debian dog that could be the basis for multiple frugals
rcrsn51 has alo developed some grub2 tools that generate menus (second post down)

[Jasper]

Looks like you have reached the "AH HA" moment

If your from the UK .......... Alan Partridge

[wizard]

Nope, from U.S., but really liked the video.

Thanks
wizard

[trawglodyte]

Not necessary. Here's an overview of how it can be done:
-create NTFS partition for Windows
-create Ext4 partition(s) for other Linux versions (can also be used for Puppy installs)
-create Ext3 or 4 partition for Puppy Linux versions

-install Widows
-install other Linux
-install all Puppy Linux

-use grub2config to install grub

I know you can multiboot Wiz.

I'm talking about a Puppy controlling the startup grub menu with all your OS's listed, including Windows if you have Windows.

Also talking about a script for that Puppy that you can hand a Puppy.iso and it makes a new folder on your puppy partition, installs the new Puppy to that folder, mounts the efi partition and adds the menuentry to grub.cfg. ba-da-bing. You just installed another puppy without needing a usb stick or even having to leave the OS you were in, and it's waiting to boot from your grub menu.

IDK, I need to make sure I can use a chainloader menuentry to boot Windows from a Puppy grub. That's what I'm going to try now.

[Jasper]

@trawglodyte

Would it be similar to Plop boot manager?

https://www.plop.at/en/bootmanagers.html

[trawglodyte]

Would it be similar to Plop boot manager?

https://www.plop.at/en/bootmanagers.html

Not exactly, but I bookmarked that and it might come in handy!! I'll have to try it out. Thank You!

[wizard]

Just for clarification, Plop boot manager can add CD or USB boot capability to a computer whose bios does not offer those options. Have used successfully for both.

wizard

[Clarity]

Hello @trawglodyte

@wizard offers ideas I am in complete agreement with. Its not just reasonable but rather simple.

I am going to offer you an even simpler solution which I recent setup with a student in a collegiate class. Its extremely simple and reducing much of the work seen in other ideas here in this thread and abound.

His Environment

• PC with 2 internal HDDs/SDDs
  8GB RAM

Scenario

• Convert 1 of the internal disk to a bootable Ventoy unit. The disk has

  1. Partition #1 by Ventoy setup

     • This partiton has ALL ISOs. In Puppy Linux, all forum distros can be booted from an arrangement already shared multiple times over the forum. Merely add a folder "/BOOTISOS" and place ALL ISO files within it.

     • It is hoped, by now, you know that a forum ISO is a complete self-contained frugal

     • That session files are the additions to the user determined use of the base frugal (aka 'the ISO')

  2. Partition #2 by Ventoy setup

     • Do not touch this as it has all needed to boot everything on your PC

  3. Partition #3 by Ventoy setup

     • All remaining disk space can be used for other things. In this case, it is labeled Persistence and he keeps ALL forum distro sessions within a folder named "/Sessions"

• On his 2nd disk, he's installed Windows with all the normal complements that attends to a manufacturer's installation for his PC.

He boots every ISO file to desktop either directly via Ventoy or via the enclosed SG2D ISO file in the BOOTISOS folder.

He operate without ANY of the hassles that normal frugals require in data movement, disk management and intricacies of things involvement boot menu setup changes to meet boot needs. And the layout works for almost all of the ISOs found on Distrowatch booting to each's desktop. He has distros that have Pipewire, distros that are Wayland based, distros that are Windows based (i.e. PEs), distros that are PUPs/FATDOGs/KLs found on this forum without issue. ... Just that he doesn't have to do any of the lifting work at all for a full frugal experience. ... None of it.

This is a no hassle system; merely download any ISO, and boot to its desktop. There is NO known downside to this arrangement as it boots just about everything thrown at it.

If you think this is of interest, post back here.

[trawglodyte]

He boots every ISO file to desktop either directly via Ventoy or via the enclosed SG2D ISO file in the BOOTISOS folder.

This is interesting. I'm familiar with Ventoy and have Ventoy on my hard drive right now. However, I have been unsuccessful in adding Ventoy to my grub menu so far. I'm a bit unclear on what happens on startup or reboot with what you're describing. Do you go into BIOS and choose to boot Ventoy?

What I like about copying the files contained in the .iso's to their own folders on a Puppy partition is I can then add the menuentry's which point to the vmlinuz and initrd.gz for each, adding them to the grub menu.

I know this is a little nit-picky, but I think it's important for a certain segment of people if they can install the OS as easily as possible from their existing OS, reboot, have it in their grub menu set up, ready to go, and boot into it.

I may not quite understand what you are describing though. Copying the .iso to a folder on a partition would be simpler than opening the .iso and copying the files in it to a folder on the partition.

What is a SG2D ISO file?

[williwaw]

I recently learned how easy it can be to install and multi-boot with Puppy Linux on a UEFI system if you have an existing Linux distro. I think it could even be made into a script you could point at a puppy.iso which would install and add it to the grub menu, which would be a good learning project for me and something useful I could contribute.

I got to thinking maybe it would be nice to find the smallest Linux distro possible to control the grub menu. I was looking at Manjaro's minimal install, Modhi, and LinuxLite. All very capable.

But then I started thinking what would be even cooler would be a Puppy on it's own partition with UEFI-friendly grub that you could use to add or remove Puppy's on another partition easily and keep the grub menu updated to boot to any of them.

Are you still thinking of a dedicated puppy with an app to generate and write grub.cfg
or
just the generate and write app that could be used with any puppy?

there are a few different puppy projects that generate grub2 stanzas, maybe only viewtopic.php?t=337 writes it out for a one step solution?

[trawglodyte]

Are you still thinking of a dedicated puppy with an app to generate and write grub.cfg
or
just the generate and write app that could be used with any puppy?

there are a few different puppy projects that generate grub2 stanzas, maybe only viewtopic.php?t=337 writes it out for a one step solution?

I need to experiment and test a little more, I ran into a strange little issue doing it from Ubuntu where after you first create a partition it does funny things when you try to write to it, even as "sudo" administrator. It gets into subsets of permissions beyond the usual drwxrwxrwx or 775 type. Really odd (at least to me) and could be resolved with a reboot, but I didn't want that so I found a workaround.

That part of it I really want to do, it would be a good learning project for me to put what I've learned into a small script or program, something like "Add-a-Pup" you could run from whatever Linux controls the grub menu. Assuming you have a partition for Puppy Linux frugal installs, and have them each in their own folder.

All the program should need is the file path to the puppy.iso that wishes to be installed, and selection from a list of partitions for the user to choose their Puppy partition. I could put an option for naming the folder and grub menu entry or just name it whatever the name of the .iso is.

I did see something called LICK someone made that did something like this, but from Windows. Not sure what happened with that, maybe it's still a thing, but I suspect problems with the secure boot b.s.

To be clear, the idea is for it to perform a frugal install and add a menuentry just by selecting the filepath to your puppy.iso and selecting your Puppy partition.

[Clarity]

... This is interesting. I'm familiar with Ventoy and have Ventoy on my hard drive right now. However, I have been unsuccessful in ...

You may be looking at this a little differently that the actual arrangement.

Ventoy creates a bootable craft where you select what you want to boot. When you boot a Ventoy disk, it does ALL the work for you. This means you dont need to modify GRUB menus as Ventoy does ALL the work for you with no need for you to make any changes.

Thus, once created, you boot the ventoy disk and it will list ALL ISOs it has for you to then select.
The instructions I provided indicates that you add all of your ISOs into a folder BOOTISOS on the Ventoy disk. Ventoy will, when the Ventoy disk is booted, list all of your ISOs. (you dont need to modify or do anything at all). When you boot your disk #1 it should arrive at the following desktop:

My Ventoy list as an example

Ventoy list example.jpg (16.46 KiB) Viewed 2145 times

Did you get that far?

... What is a SG2D ISO file?

This ISO is a ISO file list program and is an additional vehicle for booting some problem-matic WoofCE ISO files.

Ventoy and SG2D will ALSO boot any installed OSes that might be present in your system layout. For example in the student's case, he has Windows 11 installed on physical disk #2. In his case, he can use the UEFI to boot Windows OR he can use Ventoy to boot Windows, OR he can use SG2D to boot Windows if he chooses.

Ventoy disk becomes your ability to choose whichever path to desktop from both the ISOs it list and the OS you might have already installed.

This is NOT a complicated setup. Its simple and boots everything to desktop.

Again, I ask: You said you installed Ventoy on your physical disk #1. When you boot that disk, what does Ventoy show you?

Ask any questions and expect help as many other members on this forum have used Ventoy including myself.

[trawglodyte]

Ventoy creates a bootable craft where you select what you want to boot. When you boot a Ventoy disk, it does ALL the work for you. This means you dont need to modify GRUB menus as Ventoy does ALL the work for you with no need for you to make any changes.

I understand this, and if I go into BIOS I can boot to Ventoy and get that menu with 19 diferent .iso's right now. In fact, I am just about to do that because I'm installing Deepin Alpha 23. However, with BIOS set to boot VTOYEFII cannot boot any OS's I have installed on my hard drive and many of the .iso's I have on my Ventoy partition launch into an installation procedure, not a friendly OS like the Puppy.iso's.

What I've attempted to do is add VTOYEFI to the grub menu controlled previously by Ubuntu and now Debian and use a chainloader to boot to it from the grub. I think this is possible, I just haven't been successful yet and got sidetracked last time I was working on it. Sorry, my setup is kind of complicated. My goal is really to make things simple for other people who may only want a couple OS's and never change unless they have to, not just extreme distro-hoppers like me. But, in my unique case, in addition to a few Linux distro full installs and a 1/2 dozen Puppy frugal installs, I also have WIN10Pro and Win11Pro which I barely ever use but occasionally need to demonstrate something or make a video answering someone's question. My ASUS BIOS also has several settings regarding secure boot and maybe unique. All i can say is I have secure boot basically disabled but am still able to get into Win11 at this point. That may change some day, but right now it works.

Maybe this is nitpicky, but it is important to me to have a grub menu or something with all the OS's available on startup or reboot, rather than having to enter BIOS, change there, and reboot. I kind of forget how it worked but I did look at rEFIned one time when I was trying PopOS! It may have more options than Grub2, IDK.

If that's not complicated enough for you, I also have a Ventoy folder in my home directory right alongside Downloads Documents Pictures Videos Music. All of these folders are mounted to their own partitions so I can grab files and drop in .iso's from my other Linux OS's. Or wipe a Linux distro, install another in it's place and still have all my files, including the Ventoy .iso's.

But forget all that. Yes it is handy to have Ventoy on the hard drive, and that seems like a good way to boot Puppy's although I've never done that and kept a save file. I think you're telling me that you can boot Puppy.iso from Ventoy (either on hard drive or usb)and have it load with a save file? Or load your save.sfs after you're in there? That would be slick, and as soon as you drop another puppy.iso in the "Ventoy" partition it is there for you when you next boot VTOYEFI!! very cool.

This is part of the reason why I want to get the tech I need to screen capture while rebooting and going into grub. When you can SEE it, it makes sense so much easier than reading text of someone trying to explain it. At least for me.

Also, I hope some day I will understand it, but right now whatever is in that 34 mb VTOYEFI partition seems like magic to me.

[Clarity]

Hi @trawglodyte
OK, I am trying to envision what you are saying (I am a bit thick at times, so bear with me and we'll get this with helpful info beyond my comments).

First, Ventoy has a forum, like Puppy Linux and the members there respond quickly, too. It is located at "ventoy.net"

Next, this is an unwritten portion that even I need to better publish. This understanding is published on this Puppy Linux forum here. I think after your review, you have an idea of how this works with your BIOS-UEFI PC(s).

Let me know if that helps you see your ventoy disk in a better light.

BTW: You can rerun your ventoy script or its ISO file to 'update' your bootable ventoy while it'll keep you ISO folder of ISO files intact.

[trawglodyte]

@Clarity I know a bit about Ventoy, I just wanted to make sure I understood how you were using it. Here is the current state of my hard drives. See Ventoy and VTOYEFI?

I probably shouldn't have mentioned it, because it is kind of confusing. All I was saying is I can boot all my OS's, including whatever Pups are on the Puppy partition from my grub menu. What I'd like to do is add VTOYEFI to that grub menu rather than having to go into BIOS and change the boot order to launch Ventoy. I think I can do that, I just haven't figured it out yet.

[williwaw]

rather than having to go into BIOS and change the boot order to launch Ventoy. I think I can do that, I just haven't figured it out yet.

alternately, you can boot iso's directly from grub2

[Clarity]

Hi @williwaw. I think he means that his system is starting without booting the system from the 1st drive .... unless he goes into the UEFI to direct it. Yet, I agree with you on creating individual boot stanzas for ISO booting directly in GRUB2.

Hello @trawglodyte Nice disk arrangement; I like it.
I have 2 questions...assuming my message above is correct:

• is there a problem getting a Default setting in UEFI such that when the system starts, it is not going to the first drive?
  OR

• Are you saying that the UEFI default setting is launching something other than Ventoy at system start?

Need to know which of these is the correct view on my end.

I have noticed the 2 disk you have attached to your system. I am assuming they are created as GPT (usually done when installing Windows).

So your UEFI, when you enter, shows each of the available storage pathway to search toward a post-boot of the system.

Question, again
So, which is the normal, without entering UEFI, is the system defaulting to?

And all of this could mean that you want the flexibility, no matter which disk is booted to select and run Ventoy ...either disk.

Help

[trawglodyte]

alternately, you can boot iso's directly from grub2

Thanks, I didn't know this, or had seen it but didn't understand it. This may be the key to making the Puppy Commander concept even way easier than I imagined.

I though it was very easy to take an .iso, extract the files and move them into a folder on the Puppy partition (from another Linux fully installed, or the Puppy you delegate the commander). And add the menuentry to the appropriate file so you can boot into it from grub.

Oh, what's that? You probably don't even have to do that. You can just download the .iso into a folder in the Puppy Commander's directory and boot it from there? Store your save files somewhere else on the partition? Even easier!!

[williwaw]

Oh, what's that? You probably don't even have to do that. You can just download the .iso into a folder in the Puppy Commander's directory and boot it from there? Store your save files somewhere else on the partition? Even easier!!

with the save on the same partition......this works for me

Code: Select all

menuentry "vanilladpup-9.3.30.iso w/save " {
  echo "Booting ..."
  set uuid="feafedf8-8592-4052-adbb-4264819702e8"
  set isopath="/vanilladpup-9.3.30.iso"
  search --no-floppy --fs-uuid --set=root $uuid
  loopback loop $isopath
  set root=(loop)
  linux (loop)/vmlinuz find_iso=$isopath psave=feafedf8:/saves/vanilladpupsave-x
  initrd (loop)/initrd.gz
}

where the iso is in / of the partition and the save is in a subdirectory named "saves", and the full path (including the partition) to the save is specified on the kernel line with the psave= parameter as per....

README.txt (excerpt)

psave=<partition>:<path>/<filename> Specifies the save layer file.......

Where <partition> can be the name e.g sdb2, or a label e.g. Work, or a uuid
e.g. 0db94719-cdf1-44b7-9766-23db62fb85a5
When a label or uuid is used, only the beginning is required, enough to be unique on your system,
e.g "pupsfs=0db94719-cdf1"

A reading of the full README indicates one should be able to put the save on a different partition also, but I have not tested.

README.txt

Code: Select all

=========================================
                  /init
=========================================

The init script has been called the heart of Puppy Linux.
This is not because it implements a lot of Puppy stuff, but because this is where Puppy starts.
When init starts, the full-blown Puppy is still just a number of files on a storage device.
The job of init is to use those files to build a Puppy based in RAM and then hand over control to it.


Some significant files in the init world:
=========================================

vmlinuz:
   This is the Linux part of Puppy Linux, usually referred to as the Linux kernel.
   The boot process has already loaded this into memory and started running it before init starts.

initrd.gz:
   This contains the Puppy files that form the RAM based filesystem that is in place when init runs.
   The init script is one of these files.

The puppy sfs files, puppy...sfs, zdrv...sfs, fdrv...sfs, ydrv...sfs, adrv...sfs:
(Where ... is a particular puppy name and version, e.g. zdrv_slacko64_6.9.5.sfs)

puppy...sfs:
   This is the main Puppy file, containing most, if not all, the software that is in the current Puppy.
   This is the only sfs file that is required, if the init script cannot load it for any reason, the boot is abandoned.

zdrv...sfs:
   This contains kernel modules(device drivers), and firmware files matching the kernel in vmlinuz.
   Without this file, Puppy will usually still boot, but some devices will either not work or not work properly.

fdrv...sfs:
   This contains firmware files. It can be used to override the contents of zdrv...sfs.
   This file is present in only some Puppies.

bdrv...sfs:
   This contains a basic installation or skeleton of the compatible distro.
   With this file, more binary packages from the compatible distro repos are likely to work.
   It is usually not present.

ydrv...sfs:
   Notionally a patch file. It can be used to override the contents of puppy...sfs.
   It is usually not present.

adrv...sfs:
   Notionally an application file. It overrides the contents of all other sfs files.
   It is usually not present.


Overview of how it works:
=========================

* A typical frugal install of Puppy is a directory containing the above files.
* So init begins by establishing the location of this directory,
by looking for the puppy...sfs file.
* In the absence of any indication as to it's location, init searches throughout
the partitions of the system until it finds it.
* If it cannot locate the puppy...sfs file, it abandons the boot by dropping out to
a console with several error messages on the screen.
* Having located the puppy...sfs it proceeds to create a layered file system
from the sfs files in the directory.

* A layered filesystem consists of a stack of directories, most of these layers can be read-only,
but the top one is always read-write.
* The directory that contains the stack, appears to contain all the files from every layer.
* But if a file exists in more than one layer the one in the top-most layer is the one that is seen.
So the order of layers is significant.

* Init creates a stack containing only a directory in a RAM based tmpfs as the read-write layer.
* It then appends the puppy...sfs to this stack.
* It then processes the other sfs files, if they exist.
* It appends the fdrv...sfs.
* It appends the zdrv...sfs.
* It inserts the ydrv...sfs immediately below the read-write layer.
* It inserts the adrv...sfs immediately below the read-write layer.
* If all files are present we end up with a stack that looks like this:
tmpfs        read-write
adrv...sfs   read-only
ydrv...sfs   read-only
puppy...sfs  read-only
fdrv...sfs   read-only
zdrv...sfs   read-only

* If this is a first boot, the stack is ready to be made into the running system.
* But, this first boot stack contains no persistent storage.

* If you change any files in the running system they are written to the
read-write layer which only exists in RAM.

* The first time you reboot or shutdown, Puppy asks if you want to save the session.
* If you save the session you will be guided through a process to create a save layer,
to which Puppy will then copy any changed files.
* So, if this is not a first boot, init has to setup any save layer and insert it into the stack.

* Init attempts to sort out what type of save layer mechanism is being used, and make it available as a directory.
* If this attempt fails at any point, nothing extra will be done and the boot proceeds with the first boot stack.

* If the boot is considered to be from a "flash" device, the directory containing the save layer
is inserted as a read-only layer immediately below the read-write layer.
* Otherwise the tmpfs read-write layer is replaced with the directory
containing the save layer as the read-write layer.
* The stack is then made into the running system and init exits.

* If non-critical errors are detected by init it usually writes them to a file called bootinit.log
* bootinit.log also stores debug messages you might want to read.
* This file can be accessed in a running puppy as /initrd/tmp/bootinit.log


Things that provide input to init and change the things it does:
================================================================

DISTRO_SPECS:
   This is a file in initrd.gz that is created by the Puppy builder.
   It contains definitions of various information about a particular Puppy.
   DISTRO_FILE_PREFIX defines the name that occurs frequently in files that belong to it. e.g. 'slacko64'.
   DISTRO_VERSION defines the version number. e.g. '6.9.5'
   Very significant for init are DISTRO_PUPPYSFS, DISTRO_ZDRVSFS, DISTRO_FDRVSFS, DISTRO_YDRVSFS,
      DISTRO_ADRVSFS, which define the default filenames for each of the Puppy sfs files.


Boot parameters:
================

pmedia=<atahd|ataflash|usbhd|usbflash|cd> 
   Indicates the type of boot device.
   If it's "cd" then all partitions are searched for Puppy files and a save layer file.
   If the first 3 characters are "usb", then any searching is restricted to only usb devices.
   If the last 5 characters are "flash" the top layer in the stack remains the tmpfs in memory, otherwise any found save layer becomes the top layer in the stack.
   This boot parameter should always be provided.

psubdir=</path/to/install/directory>
   If the Puppy files are not in the root of a partition, but in a sub-directory, the path of this directory, relative to the partition root, must be specified with this parameter.
   e.g. If the sdb2 partition is mounted as /mnt/sdb2 and the Puppy files are in /mnt/sdb2/tahr64, then "psubdir=tahr64" or "psubdir=/tahr64" must be specified.
   This parameter can specify subdirectories at more that a single level, e.g. "psubdir=puppy/tahr64" or "psubdir=/puppy/tahr64".
   If a leading "/" is not provided, init will add it.
   This is the default path for locating any puppy file and any partition.

punionfs=<aufs|overlay>
   Overrides the union file system choice.
   The default is aufs, if the kernel is built with aufs support.
   Use with care, as aufs and overlay are incompatible with each other.
   To switch from aufs to overlay or vice versa, start with a fresh save layer (pfix=ram).

------------------------------------------------------------
pupsfs=<partition> Specifies the puppy...sfs partition
zdrv=<partition>   Specifies the zdrv...sfs  partition
fdrv=<partition>   Specifies the fdrv...sfs  partition
adrv=<partition>   Specifies the adrv...sfs  partition
ydrv=<partition>   Specifies the ydrv...sfs  partition
psave=<partition>  Specifies the save layer  partition

   Where <partition> can be the name e.g sdb2, or a label e.g. Work, or a uuid
       e.g. 0db94719-cdf1-44b7-9766-23db62fb85a5

   Specifying psave=<partition> can be quite useful in directing all save layers to a different partition.
       e.g. If your puppies reside on an ntfs partition,
       then you can get yourself a savefolder by creating a Linux partition on a usb stick or hd,
       and then specifying a psave=<the uuid of the Linux partition> boot parameter.
       If you forget to plug in the appropriate device, Puppy will simply do a first boot,
         no harm done, just insert the appropriate usb device and reboot.

ex: adrv=sdd6
ex: psave=Work
ex: pupsfs=0db94719-cdf1-44b7-9766-23db62fb85a5

----
pupsfs=<partition>:<path>/<filename> Specifies the puppy...sfs file.
zdrv=<partition>:<path>/<filename>   Specifies the zdrv...sfs file.
fdrv=<partition>:<path>/<filename>   Specifies the fdrv...sfs file.
adrv=<partition>:<path>/<filename>   Specifies the adrv...sfs file.
ydrv=<partition>:<path>/<filename>   Specifies the ydrv...sfs file.
psave=<partition>:<path>/<filename>  Specifies the save layer file.

   Where <partition> can be the name e.g sdb2, or a label e.g. Work, or a uuid
       e.g. 0db94719-cdf1-44b7-9766-23db62fb85a5
   When a label or uuid is used, only the beginning is required, enough to be unique on your system,
       e.g "pupsfs=0db94719-cdf1"

   Where <path> is the sub-directory within the partition.
       e.g. "pupsfs=sdb2:/path/to/" or "psave=:/path/to/"
   Any specified <path> is relative to the root of the partition, the same as "psubdir=".
   If <path> does not start with a "/" then a "/" is prepended to it.
   If no <path> is specified, the directory defined by "psubdir=" is used.

   Where <filename> is just a filename,
       e.g. "pupsfs=sdb2:/path/to/my-improved-puppy.sfs" or "psave=sdc2:my-improved-savefolder"
   If no <filename> is specified the default filename, as determined by the DISTRO_SPECS file, is used.

   For the purposes of the "psave=" specification a savefolder is considered to be just a file.
       The <path> specification defines the directory containing the savefolder,
           and the <filename> specification defines it's name.
       So, "psave=sdb4:/lxpupsc/mysave" says that the savefolder is on the sdb4 partition
           in the "/lxpupsc" directory, named "mysave".
       Whereas "psave=sdb4:/lxpupsc/mysave/" says that the savefolder is on the sdb4 partition
           in the "/lxpupsc/mysave" directory, with the default savefolder name for the puppy.

   It is not necessary to specify all elements,
       but if there is no ":" it is assumed to be a <partition> specification.
       e.g. "pupsfs=sdb2", specifies that the puppy...sfs file is on sdb2 in the default path with the default filename.
       "fdrv=:alternate-firmware.sfs", specifies that it's a file called alternate-firmware.sfs
       on the default partition in the default directory i.e. where the puppy...sfs is located.

   It is recommended that a pupsfs=<partition> always be specified.
   This enables init to go straight to that partition to find the Puppy files
       instead of searching through all partitions looking for puppy...sfs.

   ex: psave=sdc1:/path/to/tahrsave.4fs
   ex: psave=sdc1:tahrsave.4fs
   ex: zdrv=sdc1:/zz/myzz.sfs
   ex: adrv=sdd6:/puppy/drvs/custom/adrv.sfs
   ex: pupsfs=sdb2:/puppy/precise/puppy_precise_5.7.1.sfs

------------------------------------------------------------

pkeys=<keyboard layout specification> e.g de
   Used to setup the keyboard layout to be used by Puppy.

plang=<language specification> e.g. de_DE.UTF-8
   Specifies the language to be used by Puppy, including any messages displayed by init.
   If no pkeys parameter is provided the first 2 letters of this specification are used to set the keyboard layout.

pimod=<, separated list of kernel module names>
   On some computers the keyboard requires a kernel module to be loaded before they will work.
   The normal loading of kernel modules does not happen until after init has finished.
   But sometimes init needs to request input from the user via the keyboard.
   Specifying kernel modules in this parameter will cause init to load them before any possible keyboard interaction.

pfix=<ram, nox, nocopy, fsck, fsckp, rdsh, <number>>
   The pfix parameter is a ',' separated list of 1 or more of the above sub-parameters.
   ram:      run in ram only (do not load ${DISTRO_FILE_PREFIX}save).
   nox:      do not start X.
   copy:     copy .sfs files into ram
   nocopy:   do not copy .sfs files into ram (default is copy if ram > 1024 MB, while free ramdisk space is >= 64 MB).
   fsck:     do fsck of ${DISTRO_FILE_PREFIX}save.?fs file.
   fsckp:    do fsck before first mount of supported partitions.
   rdsh:     exit to shell in initial ramdisk.
   <number>: blacklist last <number> folders (multisession). e.g. pfix=3


Parameter files:
================

If they exist in the frugal install directory their contents are used to set some variables that otherwise could be set by boot parameters.

SAVEMARK
   Provides a means of specifying that the save layer file is on a different partition on the same
   device. It contains a single number. If the puppy...sfs is located in sdb2 and SAVEMARK
   contains 4, a save layer file is expected to be in sdb4.

initmodules.txt
   Contains a list of kernel modules that init loads before any keyboard interaction.
   Usually these are modules needed for the keyboard to work.

BOOT_SPECS
   This is a file that sets variables, like DISTRO_SPECS. But it is meant to be for the user to override the variables normally set by boot parameters.
   It can also be used to set other variables in init, e.g. "TZ='XXX-10'" sets the timezone in init to Queensland, Australia.
   The idea is that there is a copy of this file in user space, the user edits this file and then stores a copy of it in initrd.gz.
   This file could also be used instead of specific parameter files like initmodules.txt and even SAVEMARK.
   Part of this concept is to move the complication out of init into the running system.


#############################
    MORE TECHNICAL NOTES
#############################

How the script determines what pupsave to use
=============================================

If you haven't specified psave=<partition>:<filename> then init looks
for a file with this base name:

/DISTRO_SPECS -> DISTRO_FILE_PREFIX='...'

 ${DISTRO_FILE_PREFIX}save - is the fixed base name for all pupsave folders
 ${DISTRO_FILE_PREFIX}save.?fs - is the fixed base name for all pupsave files

viewtopic.php?p=94368#p94368
has some info about booting iso's directly using grub2

[Clarity]

... A reading of the full README indicates one should be able to put the save on a different partition also ...

Yes, in fact, via the PSAVE parm, I have been doing this and instructing this for years.

Scenario

1. All ISOs are kept of a booting device in a folder named "/BOOTISOS". All ISOs ever booted are in this folder.

2. a partition on the system's main drive is named 'Persistence'. Persistence has a folder named "/Sessions" where ALL sessions for ALL forum distros are kept

Example at boot for a WoofCE PUP

• On the Linux line, I add "... psave=Persistence:/Sessions/". The PUP will locate its session without issue. And if this is a pristine boot, it will insure placement of the session in that folder at shutdown.
  .
  As @williwaw shows in his example for "Session location" psave=<partition/label>:<path>/<filename> Specifies the folder where sessions reside. Thus in this case for any WoofCE PUP, my example breakdown is,
  <partition/label> = 'Persistence' <=== The label name of the partition for Sessions
  <path>/<filename> = '/Sessions/' <=== The name of the folder for keeping sessions
  allows the PUP to find the location for sessions.

For housekeeping, this is clean, flawless and organized such that at a glance I know what is where...all the time.

Hope this info is clear, easily understood, and useful.

[trawglodyte]

where the iso is in / of the partition and the save is in a subdirectory named "saves", and the full path (including the partition) to the save is specified on the kernel line with the psave= parameter as per....

Is that where the first save file defaults to? I don't see any problem with that. Probably even some advantages over putting some other folder on the partition outside of the Puppy Commander folder.

I have BookwormPup64_10.0.3 and BookwormPup64_10.0.4 freshly installed right now. I'm gonna experiment a bit. I think people are mostly familiar with grub, but I should probably take a look at rEFIned and systemd too.

I had rEFIned with an install of PopOS! and it was pretty slick. It also offered some boot options that grub2 doesn't.

I dunno about systemd, I see systemd folders in my directory on BookwormPup64_10.0.4 but that doesn't necessarily mean I can use a systemd bootloader, and if it's in any way difficult to setup I gotta make a bash script or get serious about python or something.

Bookworm having apt command line makes me feel very comfortable, but also will probably get me in trouble because I don't think it interacts with the repositories and packages exactly like the Debian/Ubuntu OS's I'm used to.

I'm not ruling out the existing grub either. Like I've never given it a serious chance, it maybe can work fine for this.

Also, I'm just using the phrase "Puppy Commander" as a concept. There's no need to rename BookwormPup or FossaPup or whatever is a good one to go with.

[williwaw]

Is that where the first save file defaults to?

when creating a save with the first-boot dialog, it would default to the frugal folder.

you can pretty much keep the frugal folders or the iso folder and the save folder(s)where ever you want. the psubdir and psave parameters in grub.cfg allow you to specify. puppy will search some at boot time, but the parameters provide for a more complex disk arrangement than the search is capable of resolving and eliminate the need for searching

[williwaw]

Bookworm having apt command line makes me feel very comfortable, but also will probably get me in trouble because I don't think it interacts with the repositories and packages exactly like the Debian/Ubuntu OS's I'm used to.

I'm not ruling out the existing grub either. Like I've never given it a serious chance, it maybe can work fine for this.

Also, I'm just using the phrase "Puppy Commander" as a concept. There's no need to rename BookwormPup or FossaPup or whatever is a good one to go with.

just curious if adding ventoy to the project for its menus and then switiching to refind to see ventoy is adding uneccessary complications

have you found any possible candidates for automating the writing of grub menus?
dont some linux projects do this already or do you always have to initiate a rewrite by editing a file before running grub-update