Another re-write of the "init" script - using OverlayFs?

Under development: PCMCIA, wireless, etc.
Post Reply
Message
Author
woodenshoe-wi
Posts: 109
Joined: Sat 29 Jul 2017, 03:16
Location: Wisconsin

#81 Post by woodenshoe-wi »

Ok, then it sounds like the best idea is for me to work on a separate ARM init.

Raspberry Pis don't normally boot from CD, so if it would be ok with you I would like to start with your init and then take it in my own direction.

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#82 Post by gyro »

@woodenshoe-wi

A few things:

1. Using a savefile rather than a savefolder does NOT necessitate running in pupmode=13(29 in this init) with the rw layer being in tmpfs and the savefile as the top of the ro stack.
Once a savefile is mounted it's mount point can be used in a normal pupmode=12 with the save directory as the top layer i.e. the rw directory of the stack.
This is true in the older init's and in this init.

2. All the kernel's I use are produced by the woorf-ce kernel kit, so they include support for aufs. This init simply chooses not to use it.

3. I have a mantra for myself:
"Windows filesystems for Windows, Linux filesystems for Linux."
It might be a lot easier if you just re-parttion your SD card to have a Linux partition on it and use the "psave=" boot parmeter to direct the savefolder to it.

4. Once I publish things (make them available on the net), I accept that folk have the capability of copying and using them in any way they see fit.
And I publish the stuff I produce in the chance that it may be useful to someone else in some way.
So, if you want to produce your own init based on my code, go for it.
Although you may want to wait for a little while yet till the dust settles. There are a couple of new things I intend to try, that could significantly restructure the current code.
I hope it works well for you.

gyro

woodenshoe-wi
Posts: 109
Joined: Sat 29 Jul 2017, 03:16
Location: Wisconsin

#83 Post by woodenshoe-wi »

Thanks. I'll gladly wait a while, there are plenty of other things that need working on to get them the way I want.

The reason I want to have pupmode=13 is to minimize writing to the SD card or USB stick. A Raspberry Pi doesn't usually have a hard drive, but a save file on a hard drive can be pupmode=12 and doesn't need snapmergepuppy.

I tried the kernel I cross compiled with kernel-kit and it boots so I can experiment with aufs, but I want to always be able to boot even if the kernel is one from Raspbian that doesn't have aufs.

I agree that NTFS in particular has no place in a linux only environment, but the Raspberry Pi boot loader needs the first partition of the SD card to be FAT. Currently the raspup woof-ce build makes an image file which is a full install in a second Linux partition. I think the only option to back up the SD card in Windows is to make an image of the whole SD card, being able to copy just a pupsave.2fs or pupsave.ram.sfs would be easier.

It helps a lot to be able to borrow from the work that others have done, but it is also easier to try things when you don't have to worry about breaking some functionality that you don't use but someone else needs, so I think I would be more comfortable working on a separate ARM init than making changes to the woof-ce init.

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

Updated version

#84 Post by gyro »

I've uploaded new versions to http://www.fishprogs.software/puppy/initrd/initrd.gz and http://www.fishprogs.software/puppy/ini ... verlay.sfs.
Both need to be downloaded, since the "ydrv_overlay.sfs" now contains an updated "extra_sfs", updated bootspecs utilities, and new "saveconfig" utility.

Changes in this 7 August version:

1. "init" now supports a new "PMODE" variable.
After first boot, puppy continues to reboot into pupmode=21, until PMODE is set in BOOT_SPECS.
This is done using a utility called "saveconfig". It's in the "Setup" menu.
Based on the answers provided it will set PMODE, PROSAVE and PSAVE, as necessary, in BOOT_SPECS, and create a savefolder.
PMODE is meant to specify only even pupmodes. PROSAVE='yes' upgrades the even pupmode to an odd pupmode.

2. The bootspecs utilities have been updated to include a "tmpbs2variable" utility that echos the value of a specified variable in BOOT_SPECS.
This means that calling uitlities can retrieve and set variables in BOOT_SPECS without regard for the underlying BOOT_SPECS facility.
They have also been updated to fully support the same location priorities as implemented in "init". i.e. if DISTRO_SPECS is in initrd.gz then BOOT_SPECS has to be there also, otherwise it's in the frugal install directory.

gyro

User avatar
peebee
Posts: 4370
Joined: Sun 21 Sep 2008, 12:31
Location: Worcestershire, UK
Contact:

#85 Post by peebee »

Hi gyro

Tried the new version....clicked on the new menu item Saveconfig and a save folder was created as expected but nothing was written in to it on reboot....BOOT_SPECS was not created....

Also tried to install an .sfs - selected it via Extra-SFS Manager but nothing happened - the .sfs wasn't added to the list but no error message appeared to suggest why not.....

The new implementation does not seem as intuitive (to me) as the previous version....do I have to know about PUPMODES ?? PUPSTATE is:

Code: Select all

PUPMODE=21
PDEV1='sda3'
DEV1FS='ext4'
PUPSFS='sda3,ext4,/devtest/puppy_LxPupSc_17.08.21.sfs'
PUPSAVE=''
PMEDIA='atahd'
#these directories are overlayfs layers in /initrd...
RW_LAYER=''
SAVE_LAYER=''
PUP_LAYER='/pup_ro2'
#The partition that has the tahrsave file is mounted here...
PUP_HOME=''
#(in /initrd) ...note, /mnt/home is a link to it.
#this file has extra kernel drivers and firmware...
ZDRV='sda3,ext4,/devtest/zdrv_LxPupSc_17.08.21.sfs'
FDRV='sda3,ext4,/devtest/fdrv_LxPupSc_17.08.21.sfs'
ADRV='sda3,ext4,/devtest/adrv_LxPupSc_17.08.21.sfs'
YDRV='sda3,ext4,/devtest/ydrv_LxPupSc_17.08.21.sfs'
PSUBDIR='/devtest'
PNOSAVE=''
PUNIONFS='overlay'
PSAVEPART='sda3'
PSAVEDIR='/devtest'
not sure where tahrsave comes from!!

Cheers
peebee
Attachments
Screenshot.png
(103.35 KiB) Downloaded 169 times
ImageLxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64

Rangan Masti
Posts: 37
Joined: Tue 01 Jan 2013, 19:23
Location: Germany, Berlin

#86 Post by Rangan Masti »

Hi, good evening. I just downladed your new initrd with ydrv. I do test this. Have fun in your work!!!.

Rangan

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#87 Post by gyro »

@peebee,

The "tahrsave" bit is easy, it's been hardcoded in this init code for quite some time. Fixed for next release.

I'll try another fresh install to see if I can reproduce your problems.

Edit:
It looks like the BOOT_SPECS file is not being created.
Both setting of a savefolder and adding an extra-sfs depend on stuff being stored in BOOT_SPECS.
I assume you did not push DISTRO_SPECS into the initrd.gz.

gyro
Last edited by gyro on Tue 08 Aug 2017, 05:54, edited 1 time in total.

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#88 Post by gyro »

I forgot to mention a few changes in the 7 August version:

3. "pfix=nosave" is now supported in pupmode=12.
On first boot after setting this, a backup is made of the savefolder to a ".tar.gz" file.
On subsequent boots the contents of the savefolder is repalced with the contents of this backup file.

4. The save to sfs in rc.shutdown now uses the mksquashfs "-ef" parameter to exclude some files.
The idea is to minimise this size of the sfs file, without using a slow compression method.

5. The POVERLAY='yes' parameter has been replaced with a PUNIONFS='overlay' in /etc/rc.d/PUPSTATE
My intention is to patch the woof-ce "init" to add a PUNIONFS='aufs' entry in /etc/rc.d/PUPSTATE
The point here is that utilities can then be easily patched or written to be unionfs aware.

6. A RW_LAYER parameter has also been added to /etc/rc.d/PUPSTATE.
Again, it's my intention to patch woof-ce "init" to do the same thing.
This is to provide a re-direction facility in /etc/rc.d/PUPSTATE that always provides the top(rw) layer of the stack, even in an odd pupmmode situation.
We introduce some future-proofing to our utilites when we use the variables in /etc/rc.d/PUPSTATE, rather than hard coding their current contents.
I think of the PUPSTATE file as a contract between "init" and the running puppy;
"init" has an obligation to produce an accurate, backwards compatible, PUPSTATE that contains all necessary information. It has no obligation to continue to fill those variables with the same content as current.
Programs and scripts in the running puppy have an obligation to trust the contents of the variables in PUPSTATE, and not try to second guess what those contents might be, based on their current content.

gyro

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#89 Post by gyro »

peebee wrote:Tried the new version....clicked on the new menu item Saveconfig and a save folder was created as expected but nothing was written in to it on reboot....BOOT_SPECS was not created....

Also tried to install an .sfs - selected it via Extra-SFS Manager but nothing happened - the .sfs wasn't added to the list but no error message appeared to suggest why not.....
I've been able to reproduce these, and fix them, so it now works for me.
The problem is that the line to create an empty BOOT_SPECS file if it doesn't exist, is missing from the current version of "bootspecs2tmpbs".

Hmm... my bad, a fairly obvious hole in my testing regime, I've been using a "YDRV=" line in "BOOT_SPECS" to load "ydrv_overlay.sfs", hence even doing a first boot, my testing usually had an existing "BOOT_SPECS".

I'll upload new versions to-night, hopefully. Just one little fix to "init" that needs a little more work.

gyro

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#90 Post by gyro »

I've uploaded new versions to http://www.fishprogs.software/puppy/initrd/initrd.gz and http://www.fishprogs.software/puppy/ini ... verlay.sfs.
Both need to be downloaded, since the "ydrv_overlay.sfs" contains updated bootspecs utilities.

This 8 August version simply fixes the bugs found by peebee.

gyro

User avatar
peebee
Posts: 4370
Joined: Sun 21 Sep 2008, 12:31
Location: Worcestershire, UK
Contact:

#91 Post by peebee »

gyro wrote:I've uploaded new versions to http://www.fishprogs.software/puppy/initrd/initrd.gz and http://www.fishprogs.software/puppy/ini ... verlay.sfs.
Both need to be downloaded, since the "ydrv_overlay.sfs" contains updated bootspecs utilities.

This 8 August version simply fixes the bugs found by peebee.
gyro
Thanks gyro
Now seems to be working correctly....
PUPSTATE:

Code: Select all

PUPMODE=12
PDEV1='sda3'
DEV1FS='ext4'
PUPSFS='sda3,ext4,/devtest/puppy_LxPupSc_17.08.21.sfs'
PUPSAVE='sda3,ext4,/devtest/LxPupScsave'
PMEDIA='atahd'
#these directories are overlayfs layers in /initrd...
RW_LAYER='/pup_rw'
SAVE_LAYER='/pup_rw'
PUP_LAYER='/pup_ro2'
#The partition that contains the LxPupScsave file is mounted here...
PUP_HOME='/mnt/sda3'
#(in /initrd) ...note, /mnt/home is a link to it.
#this file has extra kernel drivers and firmware...
ZDRV='sda3,ext4,/devtest/zdrv_LxPupSc_17.08.21.sfs'
FDRV='sda3,ext4,/devtest/fdrv_LxPupSc_17.08.21.sfs'
ADRV='sda3,ext4,/devtest/adrv_LxPupSc_17.08.21.sfs'
YDRV='sda3,ext4,/devtest/ydrv_LxPupSc_17.08.21.sfs'
PSUBDIR='/devtest'
PSAVEPART='sda3'
PSAVEDIR='/devtest'
PNOSAVE=''
PUNIONFS='overlay'
BOOT_SPECS:

Code: Select all

PMODE='12'
XTRA_SFS=':min_1.6.0_i386.sfs'
ImageLxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#92 Post by gyro »

peebee wrote:Now seems to be working correctly....
Great.
Thanks for reporting.
gyro

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#93 Post by gyro »

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.

gyro

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#94 Post by gyro »

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.

Usage:
As usual, download both http://www.fishprogs.software/puppy/initrd/initrd.gz and http://www.fishprogs.software/puppy/ini ... verlay.sfs.

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.

gyro

User avatar
peebee
Posts: 4370
Joined: Sun 21 Sep 2008, 12:31
Location: Worcestershire, UK
Contact:

#95 Post by peebee »

Hi gyro

Done some quick tests and looking good....

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....

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

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

Cheers
PeeBee
Attachments
Screenshot.png
(217.07 KiB) Downloaded 393 times
Screenshot.png
(160.8 KiB) Downloaded 383 times
ImageLxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#96 Post by gyro »

peebee wrote: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.

Thanks for testing.

gyro

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

Release of overlay_init-0.1

#97 Post by gyro »

At last, the release of overlay_init-0.1.
Unlike the previous versions in this project that were basically "proof of concept" trials of various facilities,
this version is meant to be an 'init' that can be used as a base for production.
Hence:
Like a normal Puppy, the DISTRO_SPECS file must now reside in "initrd.gz".
Like a normal Puppy, a wizard is run on first-shutdown to setup an appropriate "save" mechanism.


Main features, (apart from using overlayfs):

1. Freedom to use any sfs, stored anywhere, loaded both above and below the main puppy...sfs.
Gone is the concept of an "adrv", "ydrv", "fdrv" or "zdrv", there are now 3 sfs lists, SFS_ABOVE, SFS_MAIN and SFS_EXTRA.
These lists are added into the stack SFS_ABOVE on top, SFS_MAIN in the middle, and SFS_EXTRA at the bottom.
The only limitations are that the first sfs in the SFS_MAIN list is assumed to be the puppy...sfs and must load successfully, and if overlayfs support is a kernel module it must exist in the last sfs in the SFS_MAIN list.
So you can have as many sfs's above the puppy...sfs as you like, with any name you like.
e.g. SFS_ABOVE=':/puppy/overlay_mods.sfs,:adrv_artfulpup_17.11.sfs,:ydrv_artfulpup_17.11.sfs'
or SFS_MAIN=':puppy_xenial_7.0.8.6.sfs,:kernel_modules_4.9.71.sfs'
And these lists are managed by GUI utilities in the running system, you simply select the sfs file you want to add, and then move it up the list to it's desired position.

2. Freedom to store the savefolder anywhere, again controlled by a GUI utility in the running system.
This makes it easy to setup a "save" location on a different device, e.g. puppy...sfs on SSD, savefolder on HD.
The "Saveconfig" utility that automatically runs at first-shutdown, can be run at any time.
So, if you want to have a savefolder but at first-shutdown you don't have an appropriate partition available, you can choose "Archive" so that changes you have made during the session will not be lost.
Then later, when you have setup a Linux partition, you can run "Saveconfig" again and choose "Folder", then select the Linux partition and sub-directory.
On shuddown the current "save" data will be copied to the new savefolder, and the Puppy will reboot into pupmode=12 without losing any of your changes.

3. Support for Luks partitions as "save" targets:
Following on the above example, if at a later time you decide that the contents of your savefolder are private and need to be encrypted, you can choose a partition to sacrifice as a Luks partition, and run "Saveconfig" to setup the selected partition with Luks.
On shutdown the "save" data will be copied to the selected savefolder location inside the Luks partition.
On reboot "init" will prompt you for the password for the Luks partition and then boot into pupmmode=12.
Then you would need to remember to delete the old plain text savefolder.

4. This "init" is based on the idea that it only does what it's told to do.
It will not boot if you don't specify the location of the puppy...sfs with a "psfspart=" (or "pupsfs=") boot parameter, and a "psfsdir=" (or "psubdir=") boot parameter, if the puppy...sfs is in a sub-directory.
It will continue to boot in pupmode=5 until a sucessful run of "Saveconfig" tells it to do otherwise.

5. Mostly you tell "init" what to do by running a GUI utility in the running system.
Not only the examples above for sfs files and "save" configuring,
but also some "pfix=" boot parameters with "Pfix parameter manager", e.g. "nosave", that works in all pupmodes.
Just remember that these are "boot parameters", they change the behaviour of the next "boot", not the next "shutdown".

6. Simplified boot parameters.
Along with the "adrv", "ydrv" etc.. going, so has their boot parameters.
In fact all the ':' separated file specification boot parameters have gone.
The current file specifying boot parameters are:
"psfspart" -> contains a partition label, uuid, or name of partition containing puppy...sfs
aliases are "pdev1", "pdrv", "pupsfs"
"psfsdir" -> contains the relative path to sub-directory containing puppy...sfs
alias is "psubdir"
"psavepart" -> contains a partition label, uuid, or name of partition containing savefolder
alias is "psave"
"psavedir" -> contains the relative path to sub-directory containing savefolder
"psavepart" and "psavedir" are usually not specified as boot parameters, they are set by "Saveconfig" utility.
But they can be used to set a default "save" location, and hence the location of BOOT_SPECS.

7. There are many facilities in the current "init" script in woof-ce 'testing' that are not here.
Some of these are simply not possible due to the limitations of overlayfs, others are made too complicated by the limitations of overlayfs.
And some are simply things I never use, but could possibly be easily ported to this "init".
But I will leave the discussion of these to another time, (this is already a rather verbose post).


How to try it, using a Puppy with a working sfs_load:

0. Checks to do before you start:
Choose the Puppy you intend to use. It should be a recent woof-ce based Puppy.
Test the kernel of a running version of the Puppy by running the command "grep 'OVERLAY' /etc/modules/*" in a console.
A response that includes "CONFIG_OVERLAY_FS=m" or "CONFIG_OVERLAY_FS=y", indicates overlayfs support, which is necessary for this "init".
Then run the command "grep 'TMPFS' /etc/modules/*". A response containing "CONFIG_TMPFS_XATTR=y" is highly desirable.
Otherwise I recommend minimising activity while the read/write layer is in "tmpfs", (pupmode=5 and pupmode=21),
and moving to a savefolder (pupmode=12) as soon as possible.
You should also be able to run the tests against "etc/modules/*" in the Puppies zdrv.

1. Do a fresh frugal install of your target Puppy into a suitable writeable directory.
If you don't have a "test" partition on an internal device, a partition on a usb device is fine.
If using a usb device, a typical usb HD is usually much faster than a typical usb stick.
Make sure the "kernel" line for this install in your boot loader config contains
at least an appropriate "pupsfs=<partition>" parameter and a "psubdir=<sub-directory>" parameter if required.
Where "<partition>" is the LABEL or UUID of the target partition, and "<sub-directory>" is the path to the target directory.
It might be a good idea to boot this new install at this point just to test that it can.
If you do boot it, on first shutdown, choose "No" to avoid any saving.

2. Download http://www.fishprogs.software/puppy/ini ... it-0.1.tar to the new install directory.
Open a console window in the nenw install directory, and run command "tar xf overlay_init-0.1.tar".
This should produce 2 files, "initrd.overlay.gz" and "overlay_mods.sfs".

3. Load "overlay_mods.sfs" using sfs_load.
This will make a number of utilities specific to this 'init', available to the running Puppy.

4. Run the command "mk-timezone-file", to produce a "TIME_ZONE" file.
This text file, should contain the local time zone as "<TZ-format>|<zone file link info>".
If "mk-timezone-file" can't get the required information from the running Puppy, it gets it from "http://geoip.ubuntu.com/lookup", (thanks Lassar).

5. Run the command "overlay-setup <install-directory>", where "<install-directory>" is the full path to your install directory.
This will:
Extract the "DISTRO_SPECS" file from the "initrd.gz" file.
Store this "DISTRO_SPECS" file into "initrd.overlay.gz".
If a "TIME_ZONE" file exists store it into "initrd.overlay.gz".
Rename "initrd.gz" to "initrd.release.gz".
Rename "initrd.overlay.gz" to "initrd.gz".
Create a "BOOT_SPECS" file that will load "overlay_mods.sfs" above any other sfs's in the overlay stack.

6. Unload "overlay_mods.sfs" using sfs_load.

7. Boot this modified installation.
This should result in a first boot, change data in "Quick Setup" as required.
If you provided a "TIME_ZONE" file in step 5, the timezone should already be set correctly.
On first shutdown, a utility "Saveconfig" should run so you can choose a "save" mechanism.
"Archive" provides a "persistence but still all in ram" facility, that works on any filesystem.
"Folder" provides a "pupmode=12, savefolder on Linux partition" facility, an option to format an existing partition is provided.

8. Reboot to enjoy the new working puppy.
To modify the list of extra sfs's that "init" tries to mount, use "Extra-SFS manager".
To modify the list of system sfs's that "init" tries to mount, use "System-SFS manager".
To change some of the boot characteristics, use "Pfix parameter manager".
To change "save" to a different mechanism or change the location of the savefolder, use "Saveconfig".

Note1: If you use a Puppy that already boots with this "init" and it's "overlay_mods.sfs", then the utilities are already present, so steps 3 and 6 would be ommitted.

Note2: Utilities that store a partition identifier use a LABEL by preference, then UUID, then name. So if you use LABEL's on your partitions, make sure they are unique.
I use LABEL's on my partitions, as a UUID is rather meaningless when the stored data is viewed.


What needs to be tested:

1) That it does successfully boot current woof-ce based Puppies, i.e. they boot to the desktop.

2) Are there any Puppy utilities, other than the patched ones included in "overlay_mods.sfs", that are broken by this "init"?
Please don't bother telling me about "sfs_load" or "snapmergepuppy", these are incompatible with overlayfs.

3) That the booted Puppies work the same as when they are booted with their release "init".
While I have done many, many boots as part of this project, I haven't sustainably used the resultant Puppy.
I plan to setup a Puppy I can use as my daily workhorse and boot it with this "init".

gyro
Last edited by gyro on Sun 07 Jan 2018, 08:29, edited 2 times in total.

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

#98 Post by gyro »

peebee wrote:Is it time to build a system for people to test? ArtfulPupOV?
Well, yes, sortof.
I'm thinking of producing a "delta" to the current ArtfulPup iso.
But editing an iso and producing a "delta" is new territory for me, so it may take a little time.
If that works ok, I might consider creating "delta"s for other recent woof-ce Puppies.

gyro

gyro
Posts: 1798
Joined: Tue 28 Oct 2008, 21:35
Location: Brisbane, Australia

The TIME_ZONE file

#99 Post by gyro »

The TIME_ZONE file:
It's important function is to set the TZ variable, hence the local time-zone in "init", before any partitions are mounted. Thus eliminating any complaints from fsck relatiing to times being in the future.
Since, by default, this "init" does an fsck before the first mount of any partition, I became annoyed with frequently seeing these messages.

Pre-setting the time-zone for "Quick Setup" is just a bonus.
But during testing, I have done an awful lot of first boots, and this is just 1 more thing I no longer need to change.

For my testing, I maintain an "initrd.gz" with the new "init" and my TIME_ZONE file in it, then to test any Puppy I only have to insert the appropriate DISTRO_SPECS file.

gyro

User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#100 Post by 01micko »

IMHO I don't think a delta is the way to go if the default is to check the filesystem integrity and time skew errors are reported. While it is probably important to check for filesystem errors, couldn't this be done in OS proper? Before a save is created or at least after TZ is set by the user?

Anyway, this looks like a very interesting project and I will be installing a slacko (maybe even a revamped slacko - no promises) with aforementioned overlay mods and reporting my findings.

And to make things easier for me I have copied gyro's post to a PDF so I can display it on another device (comp, phone, tab) while I muscle my way through the destructions; ( :P) - shared below for anyone else's convenience.
Attachments
overlay-instructions-0.1.pdf.gz
overlay init 0.1 instructions from 07/01/18
(38.46 KiB) Downloaded 184 times
Puppy Linux Blog - contact me for access

Post Reply