EFI boot entry or no?

[trawglodyte]

I'm a newb and struggled, but somehow prevailed and got three pups installed to NVMe SSD GPT disk. The same disk has partitions for Ubuntu, MX Linux, and Windows 10. What worked for me, after much difficulty, was adding entries to Ubuntu's /etc/grub.d/40_custom script. My question is since this script adds the entries to Ubuntu's grub menu, and tells it where to find vmlinuz and initrd.gz for each Pup, did I even need to do the Boot setup part of FrugalPup install?? Do the files it created in the EFI partition need to be there for this to work, or no?

EDIT - gyrog shared a much easier way to create these menuentry's and make sure they'll work. Following his advice, I opened a terminal in one of my pups and did 'bootentry /mnt/home/' to get the following, Suitable to be copy/pasted into the /etc/grub.d/40_custom file on the OS controlling your grub menu.

Code: Select all

menuentry "Puppy bionicpup64 8.0" {
    search --no-floppy --fs-uuid --set  4f87f60c-d808-4ac5-93da-c613d3103188
    echo "Loading vmlinuz"
    linux /BionicPup_8.0/vmlinuz pmedia=atahd pdrv=Puppy psubdir=/BionicPup_8.0 pfix=fsck,fsckp,trim TZ=CST6CDT,M3.2.0,M11.1.0
    echo "Loading initrd.gz"
    initrd /BionicPup_8.0/initrd.gz
}
menuentry "Puppy dpup 10.0.3" {
    search --no-floppy --fs-uuid --set  4f87f60c-d808-4ac5-93da-c613d3103188
    echo "Loading vmlinuz"
    linux /BookwormPup64_10.0.3/vmlinuz acpi_osi=Linux libata.noacpi=1 net.ifnames=0 pmedia=atahd pdrv=Puppy psubdir=/BookwormPup64_10.0.3 pfix=nocopy,trim TZ=CST6CDT,M3.2.0,M11.1.0
    echo "Loading initrd.gz"
    initrd /BookwormPup64_10.0.3/initrd.gz
}
menuentry "Puppy fossapup64 9.6" {
    search --no-floppy --fs-uuid --set  4f87f60c-d808-4ac5-93da-c613d3103188
    echo "Loading vmlinuz"
    linux /F96-CE_4/vmlinuz acpi_osi=Linux libata.noacpi=1 net.ifnames=0 pmedia=atahd pdrv=Puppy psubdir=/F96-CE_4 pfix=trim TZ=CST6CDT,M3.2.0,M11.1.0
    echo "Loading initrd.gz"
    initrd /F96-CE_4/initrd.gz
}
menuentry "Puppy fossapup64 9.5" {
    search --no-floppy --fs-uuid --set  4f87f60c-d808-4ac5-93da-c613d3103188
    echo "Loading vmlinuz"
    linux /FossaPup64_9.5/vmlinuz acpi_osi=Linux libata.noacpi=1 net.ifnames=0 pmedia=atahd pdrv=Puppy psubdir=/FossaPup64_9.5 pfix=trim TZ=CST6CDT,M3.2.0,M11.1.0
    echo "Loading initrd.gz"
    initrd /FossaPup64_9.5/initrd.gz
}

Here are the menuentry's I originally made before I learned about 'bootentry' command. Keep in mind I'm a newb, all I can tell you is it's working. There are other ways to make these menuentry's that may be better!

Code: Select all

menuentry "FossaPup64_9.5 (on /dev/nvme0n1p4/FossaPup64_9.5)" --class gnu-linux --class gnu --class os  {
    insmod part_gpt
    insmod ext2
    search --no-floppy --fs-uuid --set=root 4f87f60c-d808-4ac5-93da-c613d3103188
    echo "Loading vmlinuz"
    linux /FossaPup64_9.5/vmlinuz root=UUID=4f87f60c-d808-4ac5-93da-c613d3103188 acpi_osi=Linux libata.noacpi=1 net.ifnames=0 pmedia=atahd pdrv=Puppy psubdir=/FossaPup64_9.5 psubok=TRUE pfix=trim TZ=CST6CDT,M3.2.0,M11.1.0
    echo "Loading initrd.gz"
    initrd /FossaPup64_9.5/initrd.gz
}

menuentry "F96-CE_4 (on /dev/nvme0n1p4/F96-CE_4)"  --class gnu-linux --class gnu --class os {
    insmod part_gpt
    insmod ext2
    search --no-floppy --fs-uuid --set=root 4f87f60c-d808-4ac5-93da-c613d3103188
    echo "Loading vmlinuz"
    linux /F96-CE_4/vmlinuz root=UUID=4f87f60c-d808-4ac5-93da-c613d3103188 acpi_osi=Linux libata.noacpi=1 net.ifnames=0 pmedia=atahd pdrv=Puppy psubdir=/F96-CE_4 psubok=TRUE pfix=trim TZ=CST6CDT,M3.2.0,M11.1.0
    echo "Loading initrd.gz"
    initrd /F96-CE_4/initrd.gz
}

menuentry "BionicPup_8.0 (on /dev/nvme0n1p4/BionicPup_8.0)" --class gnu-linux --class gnu --class os {
    insmod part_gpt
    insmod ext2
    search --no-floppy --fs-uuid --set=root 4f87f60c-d808-4ac5-93da-c613d3103188
    echo "Loading vmlinuz"
    linux /BionicPup_8.0/vmlinuz root=UUID=4f87f60c-d808-4ac5-93da-c613d3103188 acpi_osi=Linux libata.noacpi=1 net.ifnames=0 pmedia=atahd pdrv=Puppy psubdir=/BionicPup_8.0 psubok=TRUE pfix=trim TZ=CST6CDT,M3.2.0,M11.1.0
    echo "Loading initrd.gz"
    initrd /BionicPup_8.0/initrd.gz
}

[wizard]

did I even need to do the Boot setup part of FrugalPup install?? Do the files it created in the EFI partition need to be there for this to work, or no?

no

wizard

[trawglodyte]

no

wizard

Thanks!!

[bigpup]

You did the correct thing.

In your setup, the boot loader Ubuntu installed, is being used.

Let me guess, Ubuntu was the last operating system(OS) you installed before installing Puppy versions?
So it's boot loader is in control of booting.

When you are mixing it up with a bunch of different OS's installed.
Getting boot loader entries for Puppy Linux, usually does turn into you manually making entries, to boot them.
None of the other OS's boot loader installers know how to make an entry to boot Puppy or even see the Puppy version installed.

Frugalpup Installer is good for doing installs, but it's boot loader installer is not setup to go look for any other OS's except Puppy Linux and only makes entries for them.
Very good if only Puppy Linux versions are installed on the drive.

You do have some items in the menu entries that I am not sure what they do and some that you really should not need.
But if they work.
If it works, do not try to fix it, is a good rule to follow!

---

This is a Puppy Linux boot loader installer program that tries to find every OS that is there to find and make a boot loader entry for each one.
Grub2config
viewtopic.php?t=3360

This does need to be run in a Puppy Linux version operating the computer.

But even it does not know how to for every possible OS you may install.
Not sure it would do correct entry for MX Linux.

[mikeslr]

Ditto what bigpup wrote, especially about not fixing things which aren't broken. But, going against that advice see this post, https://www.forum.puppylinux.com/viewto ... 183#p97183

As written, the pmedia=atahd argument in your boot-stanza has Puppy operating under PupMode 12: Changes you make --including errors and junk you didn't know you picked up while surfing-- is automatically written to your SaveFile/Folder. You may want to edit that to read pmedia=ataflash so that Puppy operates under PupMode 13. See the above post for "How to Change". But remember, under PupMode 13 you have to manually execute a Save --there'll be an icon on your desktop and you'll be asked at shutdown/reboot. Otherwise nothing is Saved. Safer; but some find it inconvenient. In practice not much different if you've set up your Applications to write datafiles to external folders rather than --for example, root/my-documents. Not storing documents in your SaveFile/Folder is faster and safer. And with 3 Puppys, the external datafolders are easily usable by each.

[gyrog]

menuentry "FossaPup64_9.5 (on /dev/nvme0n1p4/FossaPup64_9.5)" --class gnu-linux --class gnu --class os {
insmod part_gpt
insmod ext2
search --no-floppy --fs-uuid --set=root 4f87f60c-d808-4ac5-93da-c613d3103188
echo "Loading vmlinuz"
linux /FossaPup64_9.5/vmlinuz root=UUID=4f87f60c-d808-4ac5-93da-c613d3103188 acpi_osi=Linux libata.noacpi=1 net.ifnames=0 pmedia=atahd pdrv=Puppy psubdir=/FossaPup64_9.5 psubok=TRUE pfix=trim TZ=CST6CDT,M3.2.0,M11.1.0
echo "Loading initrd.gz"
initrd /FossaPup64_9.5/initrd.gz
}

The current woof-ce 'init' script in 'initrd.gz' does not handle "root=UUID=" boot parameters.
But your "pdrv=Puppy" parameter defines the partition where Puppy is installed, anyway.
So you probably could do without the "root=UUID=" parameter.

The "acpi_osi=Linux libata.noacpi=1 net.ifnames=0" parameters are used by the kernel itself and not passed on to Puppy.

I have not seen a "psubok=TRUE" boot parameter before. I know the 'init' script does not process it.

But following on from @bigpup's comment about not "fixing" something that works:
Extra parameters on the "linux" line are simply ignored.

[mikewalsh]

@gyrog / @bigpup :-

Couldn't agree more, guys. If it works, no point in trying to "fix" it.....simply to satisfy some arcane notion that one layout is more aesthetically (and technically) 'proper' than another. There IS no totally 'right' or 'wrong' way for anything in Linux; just varying degrees of effectiveness.

Leave the bugger alone!

Mike.

@trawglodyte :-

to the "kennels", mate!

[gyrog]

Generating Puppy grub2 boot entries:

The FrugalPup utilities include a CLI called 'bootentry'.
This will generate a "rich" grub2 bootentry, and write it to STDOUT.
The bootentry supports optional loading of 'ucode.cpio' and 'local-initrd.gz' on the "initrd" line.

For usage information enter the following terminal command:

Code: Select all

bootentry

[williwaw]

The current woof-ce 'init' script in 'initrd.gz' does not handle "root=UUID=" boot parameters.
But your "pdrv=Puppy" parameter defines the partition where Puppy is installed, anyway.
So you probably could do without the "root=UUID=" parameter.

The "acpi_osi=Linux libata.noacpi=1 net.ifnames=0" parameters are used by the kernel itself and not passed on to Puppy.

I have not seen a "psubok=TRUE" boot parameter before. I know the 'init' script does not process it.

https://wikka.puppylinux.com/BootParametersPuppy
shows the psubok= parameter
dunno if it has been depreciated or for that matter, how much else on that page has been depreciated.

trawgl,
puppy specific parameters can be found at
viewtopic.php?t=5484
and also in README.txt, (if it is included in your installs iso)

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

[trawglodyte]

I have not seen a "psubok=TRUE" boot parameter before. I know the 'init' script does not process it.

I'm not sure where I found psubok=TRUE. This was cobbled together based on other boot files and scripts. Some which the FrugalPup installer created and some for other OS's on my system. My understanding was psubok=TRUE is to look only in the specified subdirectory and look a few layers deep if need be. Since vmlinuz and initrd.gz are on the first layer and I already specified the subdirectory it is probably not necessary.

[trawglodyte]

As written, the pmedia=atahd argument in your boot-stanza has Puppy operating under PupMode 12: Changes you make --including errors and junk you didn't know you picked up while surfing-- is automatically written to your SaveFile/Folder. You may want to edit that to read pmedia=ataflash so that Puppy operates under PupMode 13.

I will read up on this. For some reason I thought PupMode 13 was more for running from USB and I wanted it to be PupMode 12, but I need to understand them better.

[bigpup]

In Puppy Linux, the save file/folder is written to, for storing any changes you make.

What pupmode is being used, controls how this writing is done, and when it is done.

Pupmode12 writes to the save exactly when something changes.

Pupmode 13 was developed for using Puppy installed on a USB flash drive, as a way to limit the number of writes to the drive, because USB flash drives, do have a limit on number of writes, before the drive will start going bad.
Years ago, this was not as much max writes as the drives now have. The ones now, are a very large number or writes, before they could start going bad.

But everyone soon realized, that pupmode13 operation gave you control of when and if, the save was written to.

Go to menu ->System ->Puppy Event Manager ->Save Session

Running in pupmode13 will allow these different save options to be select-able.

Pupmode13 does use some of the RAM as a saveramdisk, to store changes in, until you choose to write them to the actual save file/folder.
Never a real issue, if ram is 2GB or larger, and you do not install a very large amount of software, into a running Puppy, without choosing to put it into the save.

[trawglodyte]

Pupmode12 writes to the save exactly when something changes.

Pupmode 13 was developed for using Puppy installed on a USB flash drive, as a way to limit the number of writes to the drive, because USB flash drives, do have a limit on number of writes, before the drive will start going bad.
Years ago, this was not as much max writes as the drives now have. The ones now, are a very large number or writes, before they could start going bad.

But everyone soon realized, that pupmode13 operation gave you control of when and if, the save was written to.

I can see how Pupmode 13 is a handy option. I'm definitely going to use it on BookwormPup64 since I tend to screw things up in Debian. If I understand correctly I can just quit without saving and log back in to undo my screw-ups in Pupmode 13?

[williwaw]

I can just quit without saving and log back in to undo my screw-ups in Pupmode 13?

A reboot will do that, not just logging out as a user or logging in

when looking at new apps, I will download and install many candidates to test.
Shutdown without saving,
Reboot, but before doing anything else, install the preferred app then make a manual save so there is no need to save at exit.
I generally do not save after spending any time online, as cruft, bugs or malware could be saved inadverantly.

[bigpup]

Read the save options in Puppy Event Manger ->Save Session

To make sure pupmode13 save operation never auto saves.

Make sure to have selected "ask at shutdown whether to save session or not".

Have save interval set to 0. This controls auto saving never being done.