@01micko,
I just tested a patched "change_kernels" script and it worked fine.
I setup a directory containig the files from the release xenialpup 7.5 iso.
I then patched it's "change_kernels" script with your diff and added it as a ydrv.
I then installed these files to a usb stick using "install2usb".
After rebooting the usb stick into pupmode=13, I ran the patched "change_kernels" script, to upgrade to my 32bit PAE 4.9.86 kernel.
On reboot everything worked fine, using the new kernel.
gyro
Another re-write of the "init" script - using OverlayFs?
@01micko,
I have a slight concern with your patch to "change_kernels":
Could it cope with a device that contains multiple Puppies, each in their own PSUBDIR, but with files split between sdx1 and sdx2 a bit like "install2usb" except that "vmlinuz" and "initrd.gz" are in their own PSUBDIR on sdx1, (so sdx1 can cope with multiple Puppies)?
I'm assuming that this "install2usb' will become the "standard" installer for usb sticks.
And then some folk might use it's file layout as a template to setup a multiple Puppy usb HD.
PS: This instller should be seen as the upcomming "standard" installer for usb sticks, and have it's own forum topic.
gyo
I have a slight concern with your patch to "change_kernels":
Could it cope with a device that contains multiple Puppies, each in their own PSUBDIR, but with files split between sdx1 and sdx2 a bit like "install2usb" except that "vmlinuz" and "initrd.gz" are in their own PSUBDIR on sdx1, (so sdx1 can cope with multiple Puppies)?
I'm assuming that this "install2usb' will become the "standard" installer for usb sticks.
And then some folk might use it's file layout as a template to setup a multiple Puppy usb HD.
PS: This instller should be seen as the upcomming "standard" installer for usb sticks, and have it's own forum topic.
gyo
Not multiple. It is only searching for 'vmlinuz'. However, as you previously mentioned, it would be ideal to place the boot files (vmlinuz, initrd.gz) in a PSUBDIR at the root of the vfat partition. That way, the 'change_kernels' script could search for $PSUBDIR/vmlinuz. Much neater if one does want to have multiple installs to a USB device.gyro wrote:@01micko,
I have a slight concern with your patch to "change_kernels":
Could it cope with a device that contains multiple Puppies, each in their own PSUBDIR, but with files split between sdx1 and sdx2 a bit like "install2usb" except that "vmlinuz" and "initrd.gz" are in their own PSUBDIR on sdx1, (so sdx1 can cope with multiple Puppies)?
Well there is no reason why it shouldn't be the 'standard', but I think I would still like to include single partition installs for ext[2,3,4] when UEFI is not wanted/not an option. ALL files should go to the PSUBDIR in their respective partitions.gyro wrote:I'm assuming that this "install2usb' will become the "standard" installer for usb sticks.
And then some folk might use it's file layout as a template to setup a multiple Puppy usb HD.
PS: This instller should be seen as the upcomming "standard" installer for usb sticks, and have it's own forum topic.
gyo
I'll tidy that up next and then create a thread for 'install2usb' (which may have a name change.. something like 'pupinstall2usb'
? - open to suggestions)Puppy Linux Blog - contact me for access
@01micko,
I have another suggestion concerning the "hidden" "vmlinuz" issue.
When running "install2usb" on the host Puppy, the location of "vmlinuz" is known. So how can we communicate this information to "change_kernels" in the runnng target Puppy?
In "install2usb", a "pvmlinuzpart" boot parameter is added for the target Puppy, whose value is the LABEL or UUID of the vfat partition.
The "init" script is modified so that it picks-up "pvmlinuzpart" and writes it to PUPSTATE as "PVMLINUZPART", (also add support for "pvmlinuzdir" for completeness). This is a fairly trivial patch to "init", so it could be applied to any "init" script.
In "change_kernels", if "PVMLINUZPART" is empty then use "PDEV1".
It looks complicated, but none of the modifications are difficult, and the result is very flexible, and it's all setup by the process that "knows".
"change_kernels" doesn't have to "guess".
I'll upload an "overlay_init-0.5b.tar" containg a patched "init" script.
gyro
I have another suggestion concerning the "hidden" "vmlinuz" issue.
When running "install2usb" on the host Puppy, the location of "vmlinuz" is known. So how can we communicate this information to "change_kernels" in the runnng target Puppy?
In "install2usb", a "pvmlinuzpart" boot parameter is added for the target Puppy, whose value is the LABEL or UUID of the vfat partition.
The "init" script is modified so that it picks-up "pvmlinuzpart" and writes it to PUPSTATE as "PVMLINUZPART", (also add support for "pvmlinuzdir" for completeness). This is a fairly trivial patch to "init", so it could be applied to any "init" script.
In "change_kernels", if "PVMLINUZPART" is empty then use "PDEV1".
It looks complicated, but none of the modifications are difficult, and the result is very flexible, and it's all setup by the process that "knows".
"change_kernels" doesn't have to "guess".
I'll upload an "overlay_init-0.5b.tar" containg a patched "init" script.
gyro
How about 'pupinstall2usbstick'.01micko wrote:I'll tidy that up next and then create a thread for 'install2usb' (which may have a name change.. something like 'pupinstall2usb'
Unless it is also targeted to support multiple frugal installs to a usb HD, i.e. an option to skip partitioning.
Then 'pupinstall2usb'.
gyro
Release of overlay_init-0.5b
This is a testing version with a modified "init" script to support 2 new boot parameters, "pbootpart" and "pbootdir".
The "init" scipt doesn't actually use them, it just publishes them in the PUPSTATE file as "PBOOTPART" and "PBOOTDIR", although it does decode "PBOOTPART" from a label or uuid into a partition name.
They are meant to support situations where the "vmlinuz" and "initrd.gz" files are in a different partition from the "puppy...sfs", like a "install2usb" install.
The idea is that an installer like "install2usb" could add a "pbootpart" boot parameter that specifies the label or uuid of the vfat partition.
Then a script in the running target Puppy, like"change_kernels", can pickup the partition name corresponding to this value from "PBOOTPART" in the PUPSTATE file.
Please note the name change from my previous post.
Download from http://www.fishprogs.software/puppy/ini ... t-0.5b.tar.
gyro
The "init" scipt doesn't actually use them, it just publishes them in the PUPSTATE file as "PBOOTPART" and "PBOOTDIR", although it does decode "PBOOTPART" from a label or uuid into a partition name.
They are meant to support situations where the "vmlinuz" and "initrd.gz" files are in a different partition from the "puppy...sfs", like a "install2usb" install.
The idea is that an installer like "install2usb" could add a "pbootpart" boot parameter that specifies the label or uuid of the vfat partition.
Then a script in the running target Puppy, like"change_kernels", can pickup the partition name corresponding to this value from "PBOOTPART" in the PUPSTATE file.
Please note the name change from my previous post.
Download from http://www.fishprogs.software/puppy/ini ... t-0.5b.tar.
gyro
01micko's install2usb - latest hack
I have attached "overlay_installers-0.6.sfs".
This sfs is meant to be loaded as an extra sfs in a "normal" Puppy.
It contains my latest hack of "install2usb" which will install both "normal" and "overlay" Puppies.
It should appear in the "Setup" menu as "USB Installer - Flash Drives".
When run via this sfs, it will run on "normal" Puppies.
The sfs also contains "overlay-setup-frugal", which will run on "normal" Puppies via this sfs.
I have also attached "change_kernels".
This has been patched to support "PBOOTPART" and "PBOOTDIR', but will work without them.
It shoud run on both "normal" and "overlay" Puppies.
I have not included "change_kernels" in the sfs becasue being in an extra sfs, it would be "covered" by the installed "change_kernels".
Note on "pbootpart" and "pbootdir" boot parameters:
This "install2usb" always specifies them so they can be used if the "init" script in the target Puppy supports them.
If the "init" script in the target Puppy does not support them, they will simply be ignored.
gyro
This sfs is meant to be loaded as an extra sfs in a "normal" Puppy.
It contains my latest hack of "install2usb" which will install both "normal" and "overlay" Puppies.
It should appear in the "Setup" menu as "USB Installer - Flash Drives".
When run via this sfs, it will run on "normal" Puppies.
The sfs also contains "overlay-setup-frugal", which will run on "normal" Puppies via this sfs.
I have also attached "change_kernels".
This has been patched to support "PBOOTPART" and "PBOOTDIR', but will work without them.
It shoud run on both "normal" and "overlay" Puppies.
I have not included "change_kernels" in the sfs becasue being in an extra sfs, it would be "covered" by the installed "change_kernels".
Note on "pbootpart" and "pbootdir" boot parameters:
This "install2usb" always specifies them so they can be used if the "init" script in the target Puppy supports them.
If the "init" script in the target Puppy does not support them, they will simply be ignored.
gyro
- Attachments
-
- change_kernels.gz
- gunzip to produce "change_kernels"
- (4.38 KiB) Downloaded 257 times
-
- overlay_installers-0.6.sfs.gz
- gunzip to produce "overlay_installers-0.6.sfs"
- (10.02 KiB) Downloaded 262 times
Release of overlay_init-0.6
Release of overlay_init-0.6
This release is to fully support my latest hack of "install2usb".
Download from http://www.fishprogs.software/puppy/ini ... it-0.6.tar.
There are also deltas for:
artfulpup-17.11+16.iso http://www.fishprogs.software/puppy/ini ... .iso.delta
LxPupSc-18.04T-k64.iso http://www.fishprogs.software/puppy/ini ... .iso.delta
slacko64-6.9.9.9-uefi_r6048.iso http://www.fishprogs.software/puppy/ini ... .iso.delta
xenialpup-7.5-uefi.iso http://www.fishprogs.software/puppy/ini ... .iso.delta
Note: The delta's are mostly about 2MiB, but the xenialpup one is about 37MiB beacuse it contains an updated kernel (4.9.92) and zdrv, as well.
Changes for this version:
1. Includes my latest hacks of "install2usb" and "change_kernels" scripts.
2. "Overlay init setup" utility now includes a "Squash" button if you are running in pupmode=21, and "pfix=nocopy" is not set.
On the following shutdown, the savefolder will be split into an sfs file and a minimial archive file.
Subsequent boots will load the the sfs file at the top of the stack.
After the next boot, the the sfs file will be trimmed of any files added to the savefolder by the boot.
Subsequent shutdowns will revert to the normal "archive" process.
The idea is that this can be used when the archive file is becomming large, containing many files that don't change, e.g. after installing a few pets.
3. The "init" script now aborts if it can't find any kernel modules after loading the "MAIN" sfs list.
Using:
The preferred way is to generate an iso from one of the provided delta files.
Then use "install2usb" (see "overlay_installers-0.6.sfs" in post above), to install to a usb stick.
Or do a manual frugal install from the iso.
Using an iso is preferred because "/usr/local/pup_event" has been changing, and the "/usr/local/pup_event/frontend_funcs" in "overlay_init-0.6.tar" is a patched version from xenialpup 7.5,
whereas the iso files each contain a patched version of the "/usr/local/pup_event/frontend_funcs" from their parent iso.
gyro
This release is to fully support my latest hack of "install2usb".
Download from http://www.fishprogs.software/puppy/ini ... it-0.6.tar.
There are also deltas for:
artfulpup-17.11+16.iso http://www.fishprogs.software/puppy/ini ... .iso.delta
LxPupSc-18.04T-k64.iso http://www.fishprogs.software/puppy/ini ... .iso.delta
slacko64-6.9.9.9-uefi_r6048.iso http://www.fishprogs.software/puppy/ini ... .iso.delta
xenialpup-7.5-uefi.iso http://www.fishprogs.software/puppy/ini ... .iso.delta
Note: The delta's are mostly about 2MiB, but the xenialpup one is about 37MiB beacuse it contains an updated kernel (4.9.92) and zdrv, as well.
Changes for this version:
1. Includes my latest hacks of "install2usb" and "change_kernels" scripts.
2. "Overlay init setup" utility now includes a "Squash" button if you are running in pupmode=21, and "pfix=nocopy" is not set.
On the following shutdown, the savefolder will be split into an sfs file and a minimial archive file.
Subsequent boots will load the the sfs file at the top of the stack.
After the next boot, the the sfs file will be trimmed of any files added to the savefolder by the boot.
Subsequent shutdowns will revert to the normal "archive" process.
The idea is that this can be used when the archive file is becomming large, containing many files that don't change, e.g. after installing a few pets.
3. The "init" script now aborts if it can't find any kernel modules after loading the "MAIN" sfs list.
Using:
The preferred way is to generate an iso from one of the provided delta files.
Then use "install2usb" (see "overlay_installers-0.6.sfs" in post above), to install to a usb stick.
Or do a manual frugal install from the iso.
Using an iso is preferred because "/usr/local/pup_event" has been changing, and the "/usr/local/pup_event/frontend_funcs" in "overlay_init-0.6.tar" is a patched version from xenialpup 7.5,
whereas the iso files each contain a patched version of the "/usr/local/pup_event/frontend_funcs" from their parent iso.
gyro
I've uploaded new versions of:
LxPupSc-18.04T-k64.iso http://www.fishprogs.software/puppy/ini ... .iso.delta
slacko64-6.9.9.9-uefi_r6048.iso http://www.fishprogs.software/puppy/ini ... .iso.delta
They now contain the appropriate "rc.update".
gyro
LxPupSc-18.04T-k64.iso http://www.fishprogs.software/puppy/ini ... .iso.delta
slacko64-6.9.9.9-uefi_r6048.iso http://www.fishprogs.software/puppy/ini ... .iso.delta
They now contain the appropriate "rc.update".
gyro
patch files for "install2usb" and "change_kernels"
I should have done this sooner.
I have attached "install2usb.diff" and "change_kernels.diff".
These are the hacks I have done to produce the utilities as released above.
Except that in the "install2usb.diff" the version is changed to "0.4.2" wheras the released code still has version "0.4.1".
gyro
I have attached "install2usb.diff" and "change_kernels.diff".
These are the hacks I have done to produce the utilities as released above.
Except that in the "install2usb.diff" the version is changed to "0.4.2" wheras the released code still has version "0.4.1".
gyro
- Attachments
-
- install2usb.diff.gz
- gunzip to produce install2usb.zip
- (2.23 KiB) Downloaded 237 times
-
- change_kernels.diff.gz
- gunzip to produce change_kernels.diff
- (1.84 KiB) Downloaded 247 times
Last edited by gyro on Sun 15 Apr 2018, 01:46, edited 1 time in total.
Compatible Puppy utilities
I've uploaded several pets for various Puppies.
These contain patched versions of /etc/rc.d/rc.shutdown, /etc/rc.d/rc.update, /usr/local/petget/installmodes.sh and /usr/local/pup_event/frontend_funcs.
They are patched to be compatible with both "overlay" and "normal" Puppies.
I have published these pets so that these can be tested in "normal" Puppies.
When installed in the corresponding "normal" Puppy they should make absolutely no difference.
Download:
for artfulpup-17.11+16.iso http://www.fishprogs.software/puppy/ini ... ul-0.1.pet.
for LxPupSc-18.04T-k64 http://www.fishprogs.software/puppy/ini ... sc-0.1.pet.
for slacko-700-RC3_k4.4.70-PAE_2018-04-05 http://www.fishprogs.software/puppy/ini ... ko-0.1.pet.
for slacko64-6.9.9.9-uefi_r6048 http://www.fishprogs.software/puppy/ini ... 64-0.1.pet.
for Upup_Bionic_Beaver-18.04+5 http://www.fishprogs.software/puppy/ini ... bb-0.1.pet.
for xenialpup-7.5-uefi http://www.fishprogs.software/puppy/ini ... al-0.1.pet.
I've also uploaded my proposed patches against the current 'testing' branch as a set of diff files.
Download http://www.fishprogs.software/puppy/ini ... ffs.tar.gz.
gyro
These contain patched versions of /etc/rc.d/rc.shutdown, /etc/rc.d/rc.update, /usr/local/petget/installmodes.sh and /usr/local/pup_event/frontend_funcs.
They are patched to be compatible with both "overlay" and "normal" Puppies.
I have published these pets so that these can be tested in "normal" Puppies.
When installed in the corresponding "normal" Puppy they should make absolutely no difference.
Download:
for artfulpup-17.11+16.iso http://www.fishprogs.software/puppy/ini ... ul-0.1.pet.
for LxPupSc-18.04T-k64 http://www.fishprogs.software/puppy/ini ... sc-0.1.pet.
for slacko-700-RC3_k4.4.70-PAE_2018-04-05 http://www.fishprogs.software/puppy/ini ... ko-0.1.pet.
for slacko64-6.9.9.9-uefi_r6048 http://www.fishprogs.software/puppy/ini ... 64-0.1.pet.
for Upup_Bionic_Beaver-18.04+5 http://www.fishprogs.software/puppy/ini ... bb-0.1.pet.
for xenialpup-7.5-uefi http://www.fishprogs.software/puppy/ini ... al-0.1.pet.
I've also uploaded my proposed patches against the current 'testing' branch as a set of diff files.
Download http://www.fishprogs.software/puppy/ini ... ffs.tar.gz.
gyro
I have attached "install2usb3.diff".
Changes from previous patch:
1. It only writes "pboot" boot parameters if there are 2 partitions.
2. Bump the version to "0.4.3"
gyro
Changes from previous patch:
1. It only writes "pboot" boot parameters if there are 2 partitions.
2. Bump the version to "0.4.3"
gyro
- Attachments
-
- install2usb3.diff.gz
- gunzip to produce install2usb3.diff
- (2.38 KiB) Downloaded 214 times
FYI
I've recently installed an "overlay" Puppy to a slow usb stick using "install2usb", and choosing "vfat" so I end up with just a single vfat partition on the usb stick.
I found the installed Puppy to be quite responsive when run with the "Archive" save mechanism.
gyro
I found the installed Puppy to be quite responsive when run with the "Archive" save mechanism.
gyro
I have attached "overlay_installers-0.7.sfs".
This contains my latest hack of 01micko's "install2usb".
If the target "initrd.gz" does not contain "OVERLAY_SPECS" then it appends a "TZ=" boot parameter representing the current timezone of the host Puppy.
I've realised that the current "init" in the woof-ce 'testing', will set the timezone if "TZ" is set.
So the "TZ=" boot parameter will correctly set the time during the execution of the target "init" and so avoid any possibility of fsck reporting mount time errors.
I have also attached "install2usb4.diff", which is the current patch to 01micko's code to produce my hack.
gyro
This contains my latest hack of 01micko's "install2usb".
If the target "initrd.gz" does not contain "OVERLAY_SPECS" then it appends a "TZ=" boot parameter representing the current timezone of the host Puppy.
I've realised that the current "init" in the woof-ce 'testing', will set the timezone if "TZ" is set.
So the "TZ=" boot parameter will correctly set the time during the execution of the target "init" and so avoid any possibility of fsck reporting mount time errors.
I have also attached "install2usb4.diff", which is the current patch to 01micko's code to produce my hack.
gyro
- Attachments
-
- overlay_installers-0.7.sfs.gz
- gunzip to produce overlay_installers-0.7.sfs
- (9.72 KiB) Downloaded 221 times
-
- install2usb4.diff.gz
- gunzip to produce install2usb4.diff
- (2.43 KiB) Downloaded 222 times
I have attached a further hacked version of the "change_kernels" script.
The previous version sometimes tried to "umount" a busy partition that it had not mounted, this version does not.
I have also attached "change_kernels2.diff", this patch is supposed to change 01micko's released version to my current hacked version.
gyro
The previous version sometimes tried to "umount" a busy partition that it had not mounted, this version does not.
I have also attached "change_kernels2.diff", this patch is supposed to change 01micko's released version to my current hacked version.
gyro
- Attachments
-
- change_kernels.gz
- gunzip to produce "change_kernels"
- (4.4 KiB) Downloaded 230 times
-
- change_kernels2.diff.gz
- gunzip to produce "change_kernels2.diff"
- (1.87 KiB) Downloaded 224 times
A simple fix to "install2usb", change:to"-r" is the default in recent versions of "fsck.vfat" but not in older versions.
I tested "install2usb" on Tahr 6.0.6 and the vfat partition was not fixed, until I made this change.
The changed code still works in recent versions.
gyro
Code: Select all
printf "1\ny\n"| fsck.vfat $FIXFATPARTCode: Select all
printf "1\ny\n"| fsck.vfat -r $FIXFATPARTI tested "install2usb" on Tahr 6.0.6 and the vfat partition was not fixed, until I made this change.
The changed code still works in recent versions.
gyro
Indicating that vmlinuz is in differnt partition
I'm having second thoughts about how installers like "install2usb" should indicate that "vmlinuz" is on a partition other than the one containing the frugal install directory with the sfs files.
The problem is that while the boot parameter method works fine in the running target Puppy, it does not help a script that's running on a host Puppy, but trying to update the frugal install directory of a target Puppy, e.g. "overlay-setup-frugal".
My alternative would be for the installer to write a file called "pbootlocation.txt" (or "puppyboot.txt") in the frugal install directory alongside the sfs files.
This file would contain something like the following:Where 'VFAT' is the label assigned to the vfat partition, and '/xenialpup-7.5' is the sub-directory of that partition containing "vmlinuz".
This approach should work for any script processing the frugal install directory, simplifies the code in the installer, and does not involve changing "init" or "PUPSTATE".
The aim of either approach is to support not only the "install2usb" script, but also setups where the the boot partition is a usb device but the Puppy frugal install directories reside on a different device, e.g. a Linux partition on an internal HD.
gyro
The problem is that while the boot parameter method works fine in the running target Puppy, it does not help a script that's running on a host Puppy, but trying to update the frugal install directory of a target Puppy, e.g. "overlay-setup-frugal".
My alternative would be for the installer to write a file called "pbootlocation.txt" (or "puppyboot.txt") in the frugal install directory alongside the sfs files.
This file would contain something like the following:
Code: Select all
BOOTPART='VFAT'
BOOTDIR='/xenialpup-7.5'This approach should work for any script processing the frugal install directory, simplifies the code in the installer, and does not involve changing "init" or "PUPSTATE".
The aim of either approach is to support not only the "install2usb" script, but also setups where the the boot partition is a usb device but the Puppy frugal install directories reside on a different device, e.g. a Linux partition on an internal HD.
gyro
"vmlinuz" not in frugal install directory issue
"vmlinuz" not in frugal install directory issue:
There is a simpler way.
"install2usb" doesn't do anything about the the issue.
"change_kernels" looks for "vmlinuz" in the frugal install directory, if it doesn't find it, it opens a "select file" dialog, so the user can locate it.
Silimarly, if it doesn't find a "zdrv...sfs" in the frugal install, it opens a "select file" dialog so the user can locate it.
This approach can even cope with the situation where the user has "specified" the "zdrv...sfs" to be a file with a different name, e.g. "/mnt/sdc7/kernels/kernel_modules-4.9.92.sfs".
But if the frugal install directory is "normal", then things proceed as before.
gyro
There is a simpler way.
"install2usb" doesn't do anything about the the issue.
"change_kernels" looks for "vmlinuz" in the frugal install directory, if it doesn't find it, it opens a "select file" dialog, so the user can locate it.
Silimarly, if it doesn't find a "zdrv...sfs" in the frugal install, it opens a "select file" dialog so the user can locate it.
This approach can even cope with the situation where the user has "specified" the "zdrv...sfs" to be a file with a different name, e.g. "/mnt/sdc7/kernels/kernel_modules-4.9.92.sfs".
But if the frugal install directory is "normal", then things proceed as before.
gyro
I have attached:
"overlay_installers-0.9.sfs", which includes my latest hack of 01micko's "install2usb", and "overlay-setup-frugal".
This "install2usb" does nothing about the "vmlinuz" in a different partition issue.
"change_kernels" the corresponding hack of this script.
If it can't find "vmlinuz" in the frugal install directory and it's a usb device, it also looks in PSUBDIR on the 1 partition of the device.
Otherwise it opens a file selction dialog for the user to specify the location of the appropriate "vmlinuz".
"install2usb9.diff" my patch to "install2usb".
"change_kernels9.diff" my patch to "change_kernels"
gyro
"overlay_installers-0.9.sfs", which includes my latest hack of 01micko's "install2usb", and "overlay-setup-frugal".
This "install2usb" does nothing about the "vmlinuz" in a different partition issue.
"change_kernels" the corresponding hack of this script.
If it can't find "vmlinuz" in the frugal install directory and it's a usb device, it also looks in PSUBDIR on the 1 partition of the device.
Otherwise it opens a file selction dialog for the user to specify the location of the appropriate "vmlinuz".
"install2usb9.diff" my patch to "install2usb".
"change_kernels9.diff" my patch to "change_kernels"
gyro
- Attachments
-
- overlay_installers-0.9.sfs.gz
- gunzip to produce "overlay_installers-0.9.sfs"
- (9.86 KiB) Downloaded 484 times
-
- change_kernels.gz
- gunzip to produce "change_kernels" script
- (4.53 KiB) Downloaded 461 times
-
- install2usb9.diff.gz
- gunzip to produce "install2usb9.diff"
- (2 KiB) Downloaded 483 times
-
- change_kernels9.diff.gz
- gunzip to produce "change_kernels9.diff"
- (2.04 KiB) Downloaded 479 times
Release of overlay_init-0.9
Release of overlay_init-0.9
The version jump to 0.9 is to indicate that this project is almost done.
I don't expect the "init" script to get any more significant changes.
The utilities are now pretty much functionally complete.
Unfortunately this project has become a little muddied by some of the existing Puppy files that it replaces, changing in woof-ce 'testing'.
To ensure that the patched version in this project properly reflects the version in the parent Puppy, there are multiple releases, each for a particular Puppy.
This issue will be resolved when/if I can get compatible versions of these files into woof-ce 'testing', and then they can be removed from "overlay_init-1.0.tar".
Downloads:
for artfulpup-17.11+16 http://www.fishprogs.software/puppy/ini ... ul-0.9.tar.
for LxPupSc-18.04+3T-k64 http://www.fishprogs.software/puppy/ini ... sc-0.9.tar.
for slacko-700-RC3_k4.4.70-PAE_2018-04-05_d553a8c-patched http://www.fishprogs.software/puppy/ini ... ko-0.9.tar.
for slacko64-6.9.9.9-uefi_r6048 http://www.fishprogs.software/puppy/ini ... 64-0.9.tar.
for Upup_Bionic_Beaver-18.04+7 http://www.fishprogs.software/puppy/ini ... bb-0.9.tar.
for xenialpup-7.5-uefi http://www.fishprogs.software/puppy/ini ... al-0.9.tar.
Deltas:
for artfulpup-17.11+16.iso http://www.fishprogs.software/puppy/ini ... .iso.delta.
for LxPupSc-18.04+3T-k64.iso http://www.fishprogs.software/puppy/ini ... .iso.delta.
for slacko-700-RC3_k4.4.70-PAE_2018-04-05_d553a8c-patched.iso http://www.fishprogs.software/puppy/ini ... .iso.delta.
for slacko64-6.9.9.9-uefi_r6048.iso http://www.fishprogs.software/puppy/ini ... .iso.delta.
for Upup_Bionic_Beaver-18.04+7.iso http://www.fishprogs.software/puppy/ini ... .iso.delta.
for xenialpup-7.5-uefi.iso http://www.fishprogs.software/puppy/ini ... .iso.delta.
Changes:
1. Simplified the "Squash" facility in "Overlay init setup".
This used to consist of a "split" process on shutdown, and a "purge" process after the next boot.
The "split" process has been optimised so that the gain from a "purge" process is not worth the complication, so the "purge" process had been eliminated.
The "Squash" process used to produce an update by "rc.update", this is now skipped.
2. Re-versioned all the untilities to 0.9
3. Removed "/usr/sbin/bootmanager" from most versions because the modification is now part of woof-ce 'testing'.
4. Removed support for "pbootpart" and "pbootdir" boot parameters from "init" script.
5. Renamed "OVERLAY_SPECS" to "initrdBOOTspecs".
6. Fixed bug, multisession DVD not saving when using "Archive" save mechanism.
Usage:
1. Download a delta file for a Puppy iso file that you already have, and use it to produce an "overlay" iso file.
Do a manual frugal install using this "overlay" iso,
or
install it on a usb stick using 01micko's "install2usb", see "overlay_installers-0.9.sfs.gz" in a previous post.
or
if you don't require UEFI boot, use rcrsn51's ISObooter, but answer "n" in response to it's "splash screen" question.
2. Download one of the tar files into a fresh frugal install of the appropriate Puppy,
run "overlay-setup-frugal", see "overlay_installers-0.9.sfs.gz" in a previous post.
Review, what's so interesting about this package:
1. It uses "overlayfs" not "aufs" to build the union stack.
This is suppoosed to be good because "overlayfs" is in the kernel, and so has a future,
"aufs" is not, and is never likely to be, so some predict that it will die.
"overlayfs" is supposed to be efficient, since all reading and writing of files goes directly to the actual files.
2. It contains a new facility called "bootspecs", this consists of a file that creates a mechanism for the running Puppy to communicate with the "init" script.
This means that the "init" script can more truly be said to "only do what it's told".
This facility includes scripts that make it very easy for any utility in the running system, to communicate with "init", e.g. "initmodules".
3. The complicated boot parameters for specifying what system sfs files to load, are gone.
Instead, in the running Puppy, the "Overlay init setup" GUI utility is used to "slelect" the sfs files to load and their order in 2 system sfs lists.
The "ABOVE" list (defult adrv,ydrv) that gets mounted in the stack above the "MAIN" list (default puppy,fdrv,zdrv).
These lists can contain virtually any number of sfs files with any name and with any location.
The sfs lists facility relies on the "bootspecs" facility.
4. While there is support for "psavepart" (or it's alias "psave") and "psavedir" boot parameters, these are only very rarely needed.
The "saveconfig" utility, (accessed via "Overlay init setup") can be run at any time to "select" the save mode and "select" the location where the save is stored.
So you can copy your savefolder to a different location, or change your save mechanism from "Folder" to "Archive".
The "saveconfig" utility is run automatically on first shutdown.
On first shutdown, if your are not certain that you have a suitable Linux partition for your savefolder, simply choose the "Archive" save mechanism.
When you have sorted your Linux partition, run "Overlay init setup", "Saveconfig", choose "Folder" and "Select" a directory in your Linux partition.
Again, the relevant information is communicated to "init" via the "bootspecs" facility.
And when you choose a savefolder, you always get a proper pupmode=12, never a fiddly pupmode=13.
5. To avoid any chance that Puppy will boot a different copy of the same Puppy version,
the "psfspart" boot parameter (or one of it's aliases, "pdev1", "pupsfs", "pdrv") is required.
And if the Puppy sfs files are stored in a sub-directory of the defined partition, "psfsdir" (or it's alias "psubdir") is required.
Note, that it does not care where the "vmlinuz" and "initrd.gz" files reside, these are already loaded into memory before "init" starts.
The only exception is if you are booting an iso or DVD, i.e. with "pmedia=cd" in which case the "iso9660" partition is chosen.
6. The "saveconfig" utility supports the creation and use of a Luks encrypted partition to contain savefolders.
Instead of having a Luks savefile for a single Puppy, you have a real Luks partition, that can be used to contain the savefolders of many Puppies.
7. The "Archive" save mechanism provides a means of having your cake and eating it too,
i.e having Puppy running totally in RAM, but having changes saved on shutdown and restored on boot.
Good for a limited use Puppy on a cheap usb stick.
8. Multisession DVD support has been enhanced to include the facilities provided by "Overlay init setup", including the selection of sfs file.
So, it's possible to "upgrade" a multisession DVD by writing a replacement sfs file to it,
and then using "Overlay init setup" to select the new sfs file instead of the old sfs file in the appropriate list.
Or you can simply select sfs files located anywhere on a HD, or select a savefolder location on a HD.
The "Archive" save mechanism is implemented for a multisession DVD, each archive file is appended to the DVD at shutdown.
9. "Overlay init setup" also contains a facility to specify some of the "pfix=" boot flags.
This includes a "nosave" facility that works with all save mechanisms, including what we are used to calling "pupmode=12".
10. The "Extra-SFS manager" supports the "Extra" sfs file list, that gets loaded into the stack below the "MAIN" list.
Again, you can select almost any sfs file, to be included in this list.
Unfortunately, extra sfs files are not loaded immediately, they are loaded by "init" because with "overlayfs", the stack cannot be modified after it is mounted.
11. Replacing an sfs file with another of the same name, now leads to "rc.update" displaying the dreaded "next boot will be faster" message.
The information passed from "init" to "rc.update" has been enhanced to include a modification time stamp.
The updating mechanism in "rc.update" has also been enhanced to be a lot more selective to do only what the contents of the "changed" sfs file suggests is needed.
12. Data security is enhanced by "init" always preforming an fsck on a partition before it's first mount.
This is the default behaviour, it can be disabled by booting with "pfix=nofsckp".
13. The timezone that applies during "init" and the subsequent running system can now be specified in "initrd.gz".
When an "overlay_init" Puppy is installed to a usb stick via the "install2usb" script, this is done automatically.
It is also done automatically when "overlay-setup-frugal" is used to convert a "normal" Puppy to an "overlay" Puppy.
14. A read-only stack is mounted as "/initrd/pup_sfs", this contains all the sfs's.
So it's easy to determine if a file exists in any of the loaded sfs's, and if so, read it.
Limitations imposed by "overlayfs":
1. Layers can neither be added to, nor removed from, an "overlayfs" stack.
This means the "sfs_load" as we know it, cannot be supported.
2. The directories that makeup the "overlayfs" stack, cannot be modified directly.
This means there can be no "snapmergepuppy", nor can "PPM" install directly tp "pup_ro1".
3. A read/write "overlayfs" stack, requires 2 directories on the same filesystem for it's top layer.
I have implemented this requirement by always having a "work" directory beside the "save" directory.
This means we can't use a mount point as the top directory, it would have to be 2 directories inside the mount point directory.
So, a "savefile" mechanism could not be implemented in the same manner as current.
Also using a partition as a save layer is not possible.
A note on not "searching":
Whenever there is "searching", there is the chance that more than 1 file exists that matches the search critera,
and the "found" file, might not be the one expected.
There is an advantage in avoiding "searching" if at all possible.
When you install a Puppy, you must know exactly where you installed it.
So to avoid any chance of surprises, why not tell "init" exactly where you installed it.
This "init" insists that you do.
When you select where your changed files should be saved, this "saveconfig" tells "init" exactly where it is saved, via "bootspecs".
gyro
The version jump to 0.9 is to indicate that this project is almost done.
I don't expect the "init" script to get any more significant changes.
The utilities are now pretty much functionally complete.
Unfortunately this project has become a little muddied by some of the existing Puppy files that it replaces, changing in woof-ce 'testing'.
To ensure that the patched version in this project properly reflects the version in the parent Puppy, there are multiple releases, each for a particular Puppy.
This issue will be resolved when/if I can get compatible versions of these files into woof-ce 'testing', and then they can be removed from "overlay_init-1.0.tar".
Downloads:
for artfulpup-17.11+16 http://www.fishprogs.software/puppy/ini ... ul-0.9.tar.
for LxPupSc-18.04+3T-k64 http://www.fishprogs.software/puppy/ini ... sc-0.9.tar.
for slacko-700-RC3_k4.4.70-PAE_2018-04-05_d553a8c-patched http://www.fishprogs.software/puppy/ini ... ko-0.9.tar.
for slacko64-6.9.9.9-uefi_r6048 http://www.fishprogs.software/puppy/ini ... 64-0.9.tar.
for Upup_Bionic_Beaver-18.04+7 http://www.fishprogs.software/puppy/ini ... bb-0.9.tar.
for xenialpup-7.5-uefi http://www.fishprogs.software/puppy/ini ... al-0.9.tar.
Deltas:
for artfulpup-17.11+16.iso http://www.fishprogs.software/puppy/ini ... .iso.delta.
for LxPupSc-18.04+3T-k64.iso http://www.fishprogs.software/puppy/ini ... .iso.delta.
for slacko-700-RC3_k4.4.70-PAE_2018-04-05_d553a8c-patched.iso http://www.fishprogs.software/puppy/ini ... .iso.delta.
for slacko64-6.9.9.9-uefi_r6048.iso http://www.fishprogs.software/puppy/ini ... .iso.delta.
for Upup_Bionic_Beaver-18.04+7.iso http://www.fishprogs.software/puppy/ini ... .iso.delta.
for xenialpup-7.5-uefi.iso http://www.fishprogs.software/puppy/ini ... .iso.delta.
Changes:
1. Simplified the "Squash" facility in "Overlay init setup".
This used to consist of a "split" process on shutdown, and a "purge" process after the next boot.
The "split" process has been optimised so that the gain from a "purge" process is not worth the complication, so the "purge" process had been eliminated.
The "Squash" process used to produce an update by "rc.update", this is now skipped.
2. Re-versioned all the untilities to 0.9
3. Removed "/usr/sbin/bootmanager" from most versions because the modification is now part of woof-ce 'testing'.
4. Removed support for "pbootpart" and "pbootdir" boot parameters from "init" script.
5. Renamed "OVERLAY_SPECS" to "initrdBOOTspecs".
6. Fixed bug, multisession DVD not saving when using "Archive" save mechanism.
Usage:
1. Download a delta file for a Puppy iso file that you already have, and use it to produce an "overlay" iso file.
Do a manual frugal install using this "overlay" iso,
or
install it on a usb stick using 01micko's "install2usb", see "overlay_installers-0.9.sfs.gz" in a previous post.
or
if you don't require UEFI boot, use rcrsn51's ISObooter, but answer "n" in response to it's "splash screen" question.
2. Download one of the tar files into a fresh frugal install of the appropriate Puppy,
run "overlay-setup-frugal", see "overlay_installers-0.9.sfs.gz" in a previous post.
Review, what's so interesting about this package:
1. It uses "overlayfs" not "aufs" to build the union stack.
This is suppoosed to be good because "overlayfs" is in the kernel, and so has a future,
"aufs" is not, and is never likely to be, so some predict that it will die.
"overlayfs" is supposed to be efficient, since all reading and writing of files goes directly to the actual files.
2. It contains a new facility called "bootspecs", this consists of a file that creates a mechanism for the running Puppy to communicate with the "init" script.
This means that the "init" script can more truly be said to "only do what it's told".
This facility includes scripts that make it very easy for any utility in the running system, to communicate with "init", e.g. "initmodules".
3. The complicated boot parameters for specifying what system sfs files to load, are gone.
Instead, in the running Puppy, the "Overlay init setup" GUI utility is used to "slelect" the sfs files to load and their order in 2 system sfs lists.
The "ABOVE" list (defult adrv,ydrv) that gets mounted in the stack above the "MAIN" list (default puppy,fdrv,zdrv).
These lists can contain virtually any number of sfs files with any name and with any location.
The sfs lists facility relies on the "bootspecs" facility.
4. While there is support for "psavepart" (or it's alias "psave") and "psavedir" boot parameters, these are only very rarely needed.
The "saveconfig" utility, (accessed via "Overlay init setup") can be run at any time to "select" the save mode and "select" the location where the save is stored.
So you can copy your savefolder to a different location, or change your save mechanism from "Folder" to "Archive".
The "saveconfig" utility is run automatically on first shutdown.
On first shutdown, if your are not certain that you have a suitable Linux partition for your savefolder, simply choose the "Archive" save mechanism.
When you have sorted your Linux partition, run "Overlay init setup", "Saveconfig", choose "Folder" and "Select" a directory in your Linux partition.
Again, the relevant information is communicated to "init" via the "bootspecs" facility.
And when you choose a savefolder, you always get a proper pupmode=12, never a fiddly pupmode=13.
5. To avoid any chance that Puppy will boot a different copy of the same Puppy version,
the "psfspart" boot parameter (or one of it's aliases, "pdev1", "pupsfs", "pdrv") is required.
And if the Puppy sfs files are stored in a sub-directory of the defined partition, "psfsdir" (or it's alias "psubdir") is required.
Note, that it does not care where the "vmlinuz" and "initrd.gz" files reside, these are already loaded into memory before "init" starts.
The only exception is if you are booting an iso or DVD, i.e. with "pmedia=cd" in which case the "iso9660" partition is chosen.
6. The "saveconfig" utility supports the creation and use of a Luks encrypted partition to contain savefolders.
Instead of having a Luks savefile for a single Puppy, you have a real Luks partition, that can be used to contain the savefolders of many Puppies.
7. The "Archive" save mechanism provides a means of having your cake and eating it too,
i.e having Puppy running totally in RAM, but having changes saved on shutdown and restored on boot.
Good for a limited use Puppy on a cheap usb stick.
8. Multisession DVD support has been enhanced to include the facilities provided by "Overlay init setup", including the selection of sfs file.
So, it's possible to "upgrade" a multisession DVD by writing a replacement sfs file to it,
and then using "Overlay init setup" to select the new sfs file instead of the old sfs file in the appropriate list.
Or you can simply select sfs files located anywhere on a HD, or select a savefolder location on a HD.
The "Archive" save mechanism is implemented for a multisession DVD, each archive file is appended to the DVD at shutdown.
9. "Overlay init setup" also contains a facility to specify some of the "pfix=" boot flags.
This includes a "nosave" facility that works with all save mechanisms, including what we are used to calling "pupmode=12".
10. The "Extra-SFS manager" supports the "Extra" sfs file list, that gets loaded into the stack below the "MAIN" list.
Again, you can select almost any sfs file, to be included in this list.
Unfortunately, extra sfs files are not loaded immediately, they are loaded by "init" because with "overlayfs", the stack cannot be modified after it is mounted.
11. Replacing an sfs file with another of the same name, now leads to "rc.update" displaying the dreaded "next boot will be faster" message.
The information passed from "init" to "rc.update" has been enhanced to include a modification time stamp.
The updating mechanism in "rc.update" has also been enhanced to be a lot more selective to do only what the contents of the "changed" sfs file suggests is needed.
12. Data security is enhanced by "init" always preforming an fsck on a partition before it's first mount.
This is the default behaviour, it can be disabled by booting with "pfix=nofsckp".
13. The timezone that applies during "init" and the subsequent running system can now be specified in "initrd.gz".
When an "overlay_init" Puppy is installed to a usb stick via the "install2usb" script, this is done automatically.
It is also done automatically when "overlay-setup-frugal" is used to convert a "normal" Puppy to an "overlay" Puppy.
14. A read-only stack is mounted as "/initrd/pup_sfs", this contains all the sfs's.
So it's easy to determine if a file exists in any of the loaded sfs's, and if so, read it.
Limitations imposed by "overlayfs":
1. Layers can neither be added to, nor removed from, an "overlayfs" stack.
This means the "sfs_load" as we know it, cannot be supported.
2. The directories that makeup the "overlayfs" stack, cannot be modified directly.
This means there can be no "snapmergepuppy", nor can "PPM" install directly tp "pup_ro1".
3. A read/write "overlayfs" stack, requires 2 directories on the same filesystem for it's top layer.
I have implemented this requirement by always having a "work" directory beside the "save" directory.
This means we can't use a mount point as the top directory, it would have to be 2 directories inside the mount point directory.
So, a "savefile" mechanism could not be implemented in the same manner as current.
Also using a partition as a save layer is not possible.
A note on not "searching":
Whenever there is "searching", there is the chance that more than 1 file exists that matches the search critera,
and the "found" file, might not be the one expected.
There is an advantage in avoiding "searching" if at all possible.
When you install a Puppy, you must know exactly where you installed it.
So to avoid any chance of surprises, why not tell "init" exactly where you installed it.
This "init" insists that you do.
When you select where your changed files should be saved, this "saveconfig" tells "init" exactly where it is saved, via "bootspecs".
gyro