I'm going to be away for a few weeks, so this project will seem stagnant for a while.

From my todo list:

1) Re-do savefile technology as Linux-partition-file technology.
Treat the pseudo-partition as a partition, and specify it as a save partition. Process it when mounting the save partition.
Multiple puppies can store their savefolder in the pseudo-partition, just like a real Linux partition.

2) Re-do sfs handling.
Have 3 lists, ABOVE_SFS, MAIN_SFS, BELOW_SFS.
Default ABOVE_SFS is ":adrv...sfs,:ydrv...sfs".
Default MAIN_SFS is ":puppy...sfs,:fdrv...sfs,:zdrv...sfs"
Default BELOW_SFS is empty. Can be populated with extra sfs's.
Utility for managing these lists, similar to "extra_sfs".
The main point is that you can have as many sfs's in the ABOVE_SFS list as you want, just like the current extra sfs.
And It's easy to use sfs's with non-standard names.

3) Re-do booting from multi-session DVD to include BOOT_SPECS support.

At last, a new version.
Given that the partition to contian the savefolder can be specified, this version explores some extra possabilities of what might be done while mounting the specified "partition".

Changes:

1. pupmode=29 has gone. It's messy and provides little benefit.
There is a "pfix=nosave" facility for all pupmodes including pupmode=12.
Specifying a save partition on a seperate device that can either handle it, or can be sacrificed, is a simpler approach.

2. Support for a linux partition file to provide the "slackosave" and "slackowork" directories as the top layer ot the overlayfs stack.
This is the current "savefile" technology used in a different way.
Since an overlayfs stack requires 2 directories for it's rw layer, a mountpoint cannot be use as one of them. They need to be 2 sub-directories in a Linux filesystem in a block device.
So the currrent "savefile" concept cannot be simply transported to an overlayfs stack.
The approach here is to use a file containing a Linux filesystem and associated with a loop device by "losetup" as an alternative to a real partition.
So, when using the "setupconfig" utility to select a partition, you can create and/or select a Linux partition file instead, e.g. "/mnt/sdb2/spf/LinuxFS.4fs".
An interesting included methodology is; a Linux partition file is always created as 128MiB, on every boot, if the space left is less than 128MiB, it is extended by 128MiB. i.e. it starts small and automaticaly grows with use. The user is not provided with a method to specify it's size.
Another interesting included methodology is; the filesystem type is obtained by processing the output of a command like "blkid /dev/loop5", instead of the file name extension.
The pro is that the Linux partition file does not need to reside on a Linux partition.
The con is that it's more complicated that a simple real Linux partition.
An extra con is that I can't get "rc.shutdown" to cleanly "umount" the partition containing the Linux partition file.

3. Support for storing the savefolder in a Luks encrypted partition.
Like the previous feature, the extra processing is done when mounting the partition when a save folder has been specified via the "saveconfig" utility.
In "saveconfig", simply select the Luks partition instead of an ordinary Linux partition.
This facility provides encryption facilities for any savefolder.

4. The "ydrv_overlay.sfs" now includes both 32bit and 64bit "yad" binaries, and the utilities now use the appropriate binary.
This has been tested on xenial 7.0.8.6, LxPupSc 17.11.1 and slacko64 6.9.6.7.

5. The "init" script now uses "modprobe" to load kernel modules required by the keyboard.
"initmodules" has been significantly simplified and passes only module names to "init".

6. A new version of "wait4usb" is used that adds an extra second of wait time to cater for the possibility of using 2 usb drives.

Note1: To use Luks, your puppy must include "cryptsetup". Both xenial 7.0.8.6 and LxPupSc 17.11.1 do.

Note2: The "saveconfig" utility currently does not provide a faciltiy to create a Luks partition.
To do so:
1. run a command like "cryptsetup luksFormat /dev/sdc5", to format the device with Luks, this will destroy everyting in "/dev/sdc5".
2. run a command like "cryptsetup open /dev/sdc5 sdc5"
3. run a command like "mkfs.ext4 /dev/mapper/sdc5" to create a file system in the mapped block device.

Not sure whether the creation of a savefile without any user confirmation is "user-friendly" or not....think I would have liked to confirm its initial creation....

If you are referring to the automatic persistence, there is no real savefile created, "rc.shutdown" writes a tar of the pup_rw directory in RAM, then on boot "init" extracts the tar file into the new empty pup_rw directory in RAM.
The idea is to have persistence, and running all in RAM.

peebee wrote:

Got an "Error - waiting..." message after "Unmount Puppy partitions" or somesuch on reboot - flashed up for maybe 5secs then disappeared and reboot continued.

That's odd, this message is only supposed to show if an attempt to remount something as "ro" has a non zero exit status, and should be preceeded by the "mount" error message. It should also wait for 15 seconds so the error message can be read.

peebee wrote:

Is it time to build a system for people to test? ArtfulPupOV?

The project is still trying a number of different ideas, some of those tried are subsequently abandoned, and there are still a couple to go,
Yes, there will be a final "init" plus a few modified utilities at the end of this project, but this version is not it.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum