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

Under development: PCMCIA, wireless, etc.
Post Reply
Message
Author
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

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

overlay init 0.1 instructions from 07/01/18

#101 Post by Rangan Masti »

Hi, good afternoon. I am using the new initrd on both Slacko64 and Slacko32.
Working fine for me sofar!. Tahnk you. Have a nice day.

Rangan.

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

Re: overlay init 0.1 instructions from 07/01/18

#102 Post by gyro »

Rangan Masti wrote:I am using the new initrd on both Slacko64 and Slacko32. Working fine for me sofar!.
Thanks for testing and reporting
gyro

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

#103 Post by gyro »

01micko wrote: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.
The idea of a delta to an iso was to make it easier to try.
I need to create a patched .iso to be able to test CD booting, and installers etc. So I thought I might publish a delta of this iso.
01micko wrote: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?
No, for most reliable results, fsck should be run before the first mount on every boot, i.e. as this init does.
So idealy the time skew issue needs to be solved in init before the first mount.
If a TIME_ZONE file is present in the initrd.gz, this is exactly what this init script does.

The problem is that the current TIME_ZONE stuff works fine in this test setup environment, where the overlay-setup script can add a TIME_ZONE file to the initrd.gz.
But it won't if there is a published iso, which people expect to just boot directly or install with a standard installer. Since no published iso should contain a TIME_ZONE file.

I have no simple solution at this time.

Theoretically we could modify all the Puppy installers to generate a TIME_ZONE file from the current Puppy and add it to the installed initrd.gz.
(Modifying and maintaining all the Puppy installers is the hard thing here.)
This would not do anything for booting from a CD or iso.

Or the running system could signal the selected TZ to the init script.
This does not resolve the issue for first boot, but does for subsequent boots.
This might be the best compromise.

This TIME_ZONE issue is one of the things I'm working on for version 0.2.

@01micko, thanks for testing, and for the pdf.

gyro

User avatar
bigpup
Posts: 13886
Joined: Sun 11 Oct 2009, 18:15
Location: S.C. USA

#104 Post by bigpup »

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.
This usually indicates your computers internal hardware clock is not working correctly and does not keep correct time.

This is one way to get around this problem.
fake-hwclock
http://manpages.ubuntu.com/manpages/tru ... ock.8.html
The things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected :shock:
YaPI(any iso installer)

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

#105 Post by gyro »

bigpup wrote:This usually indicates your computers internal hardware clock is not working correctly and does not keep correct time.
Sorry, I have to disagree.
The hardware clock is fine, the problem is that the 'init' script does not know what the actual timezone is, while it's busy mounting and unmounting partitions.
The Puppy tradidional way, is for 'init' to set the timezone to some hardcoded value (hence usually wrong). The problem wih this is that the superblock times in a Linux partition can get skewed into the future either when you reboot to this Puppy or when you reboot to another Puppy, depending on which side of your actual timezone the hardcoded timezone is set to.

The concept of the TIME_ZONE file is to allow 'init' to correctly set the timezone, before any mounts or unmounts of partitions.

The good news about all this timezone stuff is that it does not affect the integrity of the data. It's just annoying messages from fsck.

gyro

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

#106 Post by 01micko »

gyro wrote:The problem wih this is that the superblock times in a Linux partition can get skewed into the future either when you reboot to this Puppy or when you reboot to another Puppy, depending on which side of your actual timezone the hardcoded timezone is set to.
What about for ISO booting purposes, hard coding to Pacific/Kiritimati? That is the eastern most time zone so therefore anywhere after must be in the past. I notice fsck doesn't care if the time is in the past. I just checked by skipping my clock back an hour (future superblock error is reported) and skipping it forward an hour and no error reported. Of course I have Australia/Queensland set in my TIME_ZONE file.

In other news, I did the deed with a fresh slacko64 install with kernel updated to 4.9.73 with necessary configs. I approached it a bit differently though. I did the fresh frugal and then booted it, set timezone and from within that install performed all of your modifications. Seems to be working quite well. I have a google-chrome sfs loaded running as 'spot' with added support packages added from PPM (gtk+3, updated mozilla-nss etc).

I'll keep this as a daily driver for a while.

Thanks!
Puppy Linux Blog - contact me for access

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

#107 Post by peebee »

Tested with:
LxPupSc-18.01+4T-k64
Kernel 4.14.13 64-bit

All seems fine :D
Cheers
peebee

menu.lst=

Code: Select all

title OverlayFS (sda4/overlayfs)
  uuid 9bb32631-a1f9-425f-81bb-9f816347e8fc
  kernel /overlayfs/vmlinuz  pmedia=atahd pdrv=sda4 psubdir=overlayfs
  initrd /overlayfs/initrd.gz

Code: Select all

====> /initrd/tmp/bootinit.log <====

'FATAL' messages may be insignificant.

Doing fsck of /dev/sda4 as ext4 with e2fsck.
e2fsck 1.43.3 (04-Sep-2016)
Linux-3: clean, 303495/5693440 files, 15090214/22761984 blocks
Mounting /dev/sda4 on /mnt/sda4 as ext4.
Using /mnt/sda4/overlayfs/BOOT_SPECS
Using 'puppy_LxPupSc_18.01.sfs' as sfs0 file...
 Copying /mnt/sda4/overlayfs/puppy_LxPupSc_18.01.sfs to /mnt/tmpfs/
 Mounting /mnt/tmpfs/puppy_LxPupSc_18.01.sfs on /pup_sfs0.
Using 'fdrv_LxPupSc_18.01.sfs' as sfs1 file...
 Copying /mnt/sda4/overlayfs/fdrv_LxPupSc_18.01.sfs to /mnt/tmpfs/
 Mounting /mnt/tmpfs/fdrv_LxPupSc_18.01.sfs on /pup_sfs1.
Using 'zdrv_LxPupSc_18.01.sfs' as sfs2 file...
 Copying /mnt/sda4/overlayfs/zdrv_LxPupSc_18.01.sfs to /mnt/tmpfs/
 Mounting /mnt/tmpfs/zdrv_LxPupSc_18.01.sfs on /pup_sfs2.
Using 'overlay_mods.sfs' as sfs3 file...
 Copying /mnt/sda4/overlayfs/overlay_mods.sfs to /mnt/tmpfs/
 Mounting /mnt/tmpfs/overlay_mods.sfs on /pup_sfs3.
Using 'adrv_LxPupSc_18.01.sfs' as sfs4 file...
 Copying /mnt/sda4/overlayfs/adrv_LxPupSc_18.01.sfs to /mnt/tmpfs/
 Mounting /mnt/tmpfs/adrv_LxPupSc_18.01.sfs on /pup_sfs4.
Adding module kernel/fs/overlayfs/overlay.ko
Mounting pup_sfs3:pup_sfs4:pup_sfs0:pup_sfs1:pup_sfs2 on /pup_sfs...
umount_unneeded - keeping /dev/sda4
Booting with PUPMODE=12
Using personal storage /overlayfs/LxPupScsave [sda4].
Mounting LxPupScsave:pup_sfs on /pup_new...
mount -o move /pup_sfs0 /pup_new/initrd/pup_sfs0
mount -o move /pup_sfs1 /pup_new/initrd/pup_sfs1
mount -o move /pup_sfs2 /pup_new/initrd/pup_sfs2
mount -o move /pup_sfs3 /pup_new/initrd/pup_sfs3
mount -o move /pup_sfs4 /pup_new/initrd/pup_sfs4
mount -o move /pup_sfs /pup_new/initrd/pup_sfs
mount -o move /mnt/sda4 /pup_new/initrd/mnt/sda4
mount -o move /mnt/tmpfs /pup_new/initrd/mnt/tmpfs
'/pup_new/initrd/pup_rw' -> '/initrd/mnt/sda4/overlayfs/LxPupScsave'
'/pup_new/tmp' -> '/initrd/mnt/tmpfs/tmp'
Attachments
Screenshot.png
(179.07 KiB) Downloaded 471 times
Last edited by peebee on Sun 14 Jan 2018, 09:36, edited 1 time in total.
ImageLxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#108 Post by jamesbond »

01micko wrote:
gyro wrote:The problem wih this is that the superblock times in a Linux partition can get skewed into the future either when you reboot to this Puppy or when you reboot to another Puppy, depending on which side of your actual timezone the hardcoded timezone is set to.
I got interested when I read this, so I've done a few tests.

I found out that this superblock problem only manifest itself when your hardware clock is set to localtime - which is the default settings in most puppies, to accomodate dual booting with Windows. If hwclock is set in UTC, all is good.

I don't know how you do it gyro, but this is how I did it in init (I don't have persistence file in initrd like you do): "[ $TZ ] && hwclock -t" where hwclock is busybox applet similar to coreutils' utility of the same name.

This way, I only need to pass boot parameter TZ=EST-10 and all will be right. Of course, again, this is only necessary when running hwclock in localtime.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

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

#109 Post by peebee »

I've made a delta to produce LxPupSc-18.01+4-overlayfs.iso

See: http://murga-linux.com/puppy/viewtopic. ... 329#980329
ImageLxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64

stemsee

#110 Post by stemsee »

I tried this with artful pup. opened the initrd and put in the DISTRO_SPECS. added kernel arguments pdrv and psubdir and everything else was automatic.
Once at desktop loaded wine-2.2.sfs @200mb. the 32bit pae kernel recognised 7.9gb of 16gb.
Attachments
Screenshot(3).png
(117.18 KiB) Downloaded 157 times

Post Reply