Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Tue 17 Jul 2018, 05:13
All times are UTC - 4
 Forum index » Advanced Topics » Cutting edge
Another re-write of the "init" script - using OverlayFs?
Moderators: Flash, Ian, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 7 of 13 [189 Posts]   Goto page: Previous 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13 Next
Author Message
peebee


Joined: 21 Sep 2008
Posts: 3391
Location: Worcestershire, UK

PostPosted: Tue 08 Aug 2017, 12:01    Post subject:  

gyro wrote:
I've uploaded new versions to http://www.fishprogs.software/puppy/initrd/initrd.gz and http://www.fishprogs.software/puppy/initrd/ydrv_overlay.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:
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:
PMODE='12'
XTRA_SFS=':min_1.6.0_i386.sfs'

_________________
LxPup = Puppy + LXDE
Back to top
View user's profile Send private message Visit poster's website 
gyro

Joined: 28 Oct 2008
Posts: 1527
Location: Brisbane, Australia

PostPosted: Wed 09 Aug 2017, 02:34    Post subject:  

peebee wrote:
Now seems to be working correctly....
Great.
Thanks for reporting.
gyro
Back to top
View user's profile Send private message 
gyro

Joined: 28 Oct 2008
Posts: 1527
Location: Brisbane, Australia

PostPosted: Fri 18 Aug 2017, 05:35    Post subject:  

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
Back to top
View user's profile Send private message 
gyro

Joined: 28 Oct 2008
Posts: 1527
Location: Brisbane, Australia

PostPosted: Wed 15 Nov 2017, 05:35    Post subject:  

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/initrd/ydrv_overlay.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
Back to top
View user's profile Send private message 
peebee


Joined: 21 Sep 2008
Posts: 3391
Location: Worcestershire, UK

PostPosted: Mon 20 Nov 2017, 05:26    Post subject:  

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
Screenshot.png
 Description   
 Filesize   217.07 KB
 Viewed   334 Time(s)

Screenshot.png

Screenshot.png
 Description   
 Filesize   160.8 KB
 Viewed   331 Time(s)

Screenshot.png


_________________
LxPup = Puppy + LXDE
Back to top
View user's profile Send private message Visit poster's website 
gyro

Joined: 28 Oct 2008
Posts: 1527
Location: Brisbane, Australia

PostPosted: Mon 20 Nov 2017, 09:10    Post subject:  

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
Back to top
View user's profile Send private message 
gyro

Joined: 28 Oct 2008
Posts: 1527
Location: Brisbane, Australia

PostPosted: Sun 07 Jan 2018, 03:52    Post subject: Release of overlay_init-0.1  

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/initrd/overlay_init-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, 04:29; edited 2 times in total
Back to top
View user's profile Send private message 
gyro

Joined: 28 Oct 2008
Posts: 1527
Location: Brisbane, Australia

PostPosted: Sun 07 Jan 2018, 04:00    Post subject:  

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
Back to top
View user's profile Send private message 
gyro

Joined: 28 Oct 2008
Posts: 1527
Location: Brisbane, Australia

PostPosted: Sun 07 Jan 2018, 05:02    Post subject: The TIME_ZONE file  

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
Back to top
View user's profile Send private message 
01micko


Joined: 11 Oct 2008
Posts: 8675
Location: qld

PostPosted: Thu 11 Jan 2018, 03:38    Post subject:  

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; ( Razz) - shared below for anyone else's convenience.
overlay-instructions-0.1.pdf.gz
Description  overlay init 0.1 instructions from 07/01/18
gz

 Download 
Filename  overlay-instructions-0.1.pdf.gz 
Filesize  38.46 KB 
Downloaded  80 Time(s) 

_________________
Puppy Linux Blog - contact me for access
Back to top
View user's profile Send private message Visit poster's website 
Rangan Masti

Joined: 01 Jan 2013
Posts: 36
Location: Germany, Berlin

PostPosted: Thu 11 Jan 2018, 07:29    Post subject: overlay init 0.1 instructions from 07/01/18  

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.
Back to top
View user's profile Send private message 
gyro

Joined: 28 Oct 2008
Posts: 1527
Location: Brisbane, Australia

PostPosted: Fri 12 Jan 2018, 06:25    Post subject: Re: overlay init 0.1 instructions from 07/01/18  

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
Back to top
View user's profile Send private message 
gyro

Joined: 28 Oct 2008
Posts: 1527
Location: Brisbane, Australia

PostPosted: Fri 12 Jan 2018, 07:30    Post subject:  

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
Back to top
View user's profile Send private message 
bigpup


Joined: 11 Oct 2009
Posts: 10705
Location: Charleston S.C. USA

PostPosted: Fri 12 Jan 2018, 17:11    Post subject:  

Quote:
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/trusty/man8/fake-hwclock.8.html

_________________
I have found, in trying to help people, that 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 Shocked
Back to top
View user's profile Send private message 
gyro

Joined: 28 Oct 2008
Posts: 1527
Location: Brisbane, Australia

PostPosted: Sat 13 Jan 2018, 05:39    Post subject:  

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
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 7 of 13 [189 Posts]   Goto page: Previous 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Cutting edge
Jump to:  

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


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.0839s ][ Queries: 15 (0.0107s) ][ GZIP on ]