A SAVE-session to directory option added for PUPs [REOPENED]
Hello @Gyro
2fs/3fs/4fs are files that get created, then written into. The shutdown processing subsystem uses Linux utilities to create a file that looks like a posix partition, then writes the system's changes into that posix look-a-like. Once this is done, that file, namely 2fs/3fs/4fs can be place "undisturbed" on ANY known partiton (ext/NTFS/vFAT/FAT32/...etc) which a booting PUP can capably search on boot-up.
What is discussed here is an addition to shutdown-restart processing (persistence) change needs, where the changes (save-session) is a "real" folder for linux use, not one of these special files. The advantage and has been mention earlier, is that the primary system needs are NOT restricted to the size of the 2fs/3fs/4fs sizes....ever!
Hope this helps
2fs/3fs/4fs are files that get created, then written into. The shutdown processing subsystem uses Linux utilities to create a file that looks like a posix partition, then writes the system's changes into that posix look-a-like. Once this is done, that file, namely 2fs/3fs/4fs can be place "undisturbed" on ANY known partiton (ext/NTFS/vFAT/FAT32/...etc) which a booting PUP can capably search on boot-up.
What is discussed here is an addition to shutdown-restart processing (persistence) change needs, where the changes (save-session) is a "real" folder for linux use, not one of these special files. The advantage and has been mention earlier, is that the primary system needs are NOT restricted to the size of the 2fs/3fs/4fs sizes....ever!
Hope this helps
No, i didnt get that far. I booted it live and had a look around but really it was just a cursory look with the intention of coming back to it (a bad habit of mine unfortunately ). I shall go back and do an install. Thanks for the remindermikeb wrote:@ greengeek
did you not try the folder save (and sfs) and the multiuser option from the pup you had from me? ..a place I put my mouth
Then you can try out all this theory in practice.
ok well the save folder and archive is simply added to the shutdown options.No, i didnt get that far. I booted it live and had a look around but really it was just a cursory look with the intention of coming back to it (a bad habit of mine unfortunately Embarassed ). I shall go back and do an install. Thanks for the reminder
For multiuser rename /etc/slim.conf.bak to slim.conf and that triggers xwin to give a login screen for root or user. Use the create user wizard from the menu. Suggest test one thing at a time
mike
This resize2fs manual page suggests that resizing might be possible whilst still being mounted (if ext3/4)gcmartin wrote:The advantage and has been mention earlier, is that the primary system needs are NOT restricted to the size of the 2fs/3fs/4fs sizes....ever!
The resize2fs program will resize ext2, ext3, or ext4 file systems. It can be used to enlarge or shrink an unmounted file system located on device. If the filesystem is mounted, it can be used to expand the size of the mounted filesystem, assuming the kernel supports on-line resizing. (As of this writing, the Linux 2.6 kernel supports on-line resize for filesystems mounted using ext3 and ext4.).
Might then it be viable to monitor/dynamically (live) expand the savefile by 25% once it was >75% filled .... to equal effect (assuming ext3/4).
That intelligence would need to added to the running system somewhere; say, when attempting to add subsystem functionality via PPM.rufwoof wrote:... Might then it be viable to monitor/dynamically (live) expand the savefile by 25% once it was >75% filled .... to equal effect (assuming ext3/4).
But, if user had selected the option to use a folder, this intelligence would not be necessary. Every user, Apple/Microsoft/unix/Linux understands "drive level space management" solutions. ... everyone. Not so, when understanding of a "file" which is a filesystem which has run out of space and any problems which surface related to such. This is why the discussion is being pondered. In reality, a folder approach would reduce the number of questions that surface on the forum about issues related to 2fs/3fs/4fs.
Folders offer a clearer and clean solution. And certainly make for a universally understandable item to address. As is mentioned earlier about FATDOG, that approach attempts to address much of this. As does the other case where "under certain conditions" one is given the option of partition selection. But, this thread ponders the option of folder selection at shutdown to easy understandable save-session/persistence management for the RAM approach to Puppy operation. Primary, again, for both Live and Frugal experienced or non-experienced users.
Hope this is helpful.
After checking the "init" from Dpup Wheezy, I've changed my suggestion to no longer require a ".dir" extension.
If we are looking on a linux partition, and a save folder exists, use that,
else, look for a save file.
The following is some example code for "init":
replacewith
replacewith
Note1: I have not got around to testing this yet.
Note2: Unfortunately a couple of the lines in the code are quite long, and get wrapped in this forum.
gyro
If we are looking on a linux partition, and a save folder exists, use that,
else, look for a save file.
The following is some example code for "init":
replace
Code: Select all
[ -d /mnt/data${PSUBDIR} ] && FND_PUPSAVES="`find /mnt/data${PSUBDIR} -maxdepth 1 -xdev -type f -iname ${DISTRO_FILE_PREFIX}save*.[234]fs | grep -v ' ' | sed -e 's%^/mnt/data%%' | tr '\n' ' '`"
Code: Select all
if [ -d /mnt/data${PSUBDIR} ]; then
case $ONEFS in
ext2|ext3|ext4|reiserfs|minix|f2fs) FND_PUPSAVES="`find /mnt/data${PSUBDIR} -maxdepth 1 -xdev -type d -iname ${DISTRO_FILE_PREFIX}save'*'| grep -v ' ' | sed -e 's%^/mnt/data%%' | tr '\n' ' '`" ;;
esac
[ "$FND_PUPSAVES" = "" ] && FND_PUPSAVES="`find /mnt/data${PSUBDIR} -maxdepth 1 -xdev -type f -iname ${DISTRO_FILE_PREFIX}save*.[234]fs | grep -v ' ' | sed -e 's%^/mnt/data%%' | tr '\n' ' '`"
fi
Code: Select all
else #pupsave not encrypted.
Code: Select all
elif [ -d /mnt/dev_save$PUPSAVEFILE ]; then
mount -o bind /mnt/dev_save${PUPSAVEFILE} $CREATEPUPSAVE2FS
else #pupsave not encrypted.
Note2: Unfortunately a couple of the lines in the code are quite long, and get wrapped in this forum.
gyro
Last edited by gyro on Mon 05 May 2014, 12:15, edited 1 time in total.
looking good gyro.... my way of thinking is why not work with a save system located where the pup sfs is rather than trying to search next doors garden for something....only exception would be the live cd for those who have an aversion to grub4dos.
If a save folder is found or better still defined then let the save be in there = a dead simple test.
Trying to cover absolutely any combination regardless of how unlikely its needed just produces diffficult to work code...
saying that the puppy 2 code manages most of that in a much simpler way.... ls /mnt/data/*/pup_{$PUPPYVERSION}.sfs also does a targetted subfolder search... ..alternatively /* could be a variable set by psubdir... so rather than all that subfolder searching just target a specified folder or search the drives roots. Like a nit nurse....
mike
If a save folder is found or better still defined then let the save be in there = a dead simple test.
Trying to cover absolutely any combination regardless of how unlikely its needed just produces diffficult to work code...
saying that the puppy 2 code manages most of that in a much simpler way.... ls /mnt/data/*/pup_{$PUPPYVERSION}.sfs also does a targetted subfolder search... ..alternatively /* could be a variable set by psubdir... so rather than all that subfolder searching just target a specified folder or search the drives roots. Like a nit nurse....
mike
Seems to my noob minded view that it would just be a slow transition to a (almost) full install, excepting unchanging bin's/lib's.... Wouldn't therefore an alternative be to create a partial full install option but with the core (unchanging) bin's/lib's (busybox.. etc) being retained inside Puppy? Personally I can't see much of a benefit of that compared to a full install - after all the cost per MB of HDD storage is (very) inexpensive (in Puppy's small size terms).gcmartin wrote:But, if user had selected the option to use a folder, this intelligence would not be necessary. Every user, Apple/Microsoft/unix/Linux understands "drive level space management" solutions. ... everyone. Not so, when understanding of a "file" which is a filesystem which has run out of space and any problems which surface related to such.
Would a kernel change/extension approach be viable where :
An external file that contained a master list of all filenames, location of file, permissions, size, state - which could even be textual/standard and as such storable on any partition type (ntfs ...etc).
When puppy needs to access a file it looks at that table of files and follows that route. The state flag/field would indicate whether that file was active or deleted (unavailable). The state flag might also indicate whether writes could actually be made (or not). i.e. when puppy changed a file and the current location was read only (inside puppy) but the user had permission to write to that file, then store the changed/new file outside of puppy and update the master file table to point to that.
Where that might get interesting is that the location could even be a wget to a remote (cloud) location. Personally my internet connection speed is approaching my LAN speed (on a old 100T LAN with 50Mb - 75Mb internet speed), I'm old enough to remember sub 1200 baud speeds and accordingly can see future potential speeds being significantly higher than current levels. A Puppy based on purely pointer driven file locations could be very small in size when the internet connection speed was adequately fast enough, or larger in size (files all local) for no/slow internet speeds.
An external file that contained a master list of all filenames, location of file, permissions, size, state - which could even be textual/standard and as such storable on any partition type (ntfs ...etc).
When puppy needs to access a file it looks at that table of files and follows that route. The state flag/field would indicate whether that file was active or deleted (unavailable). The state flag might also indicate whether writes could actually be made (or not). i.e. when puppy changed a file and the current location was read only (inside puppy) but the user had permission to write to that file, then store the changed/new file outside of puppy and update the master file table to point to that.
Where that might get interesting is that the location could even be a wget to a remote (cloud) location. Personally my internet connection speed is approaching my LAN speed (on a old 100T LAN with 50Mb - 75Mb internet speed), I'm old enough to remember sub 1200 baud speeds and accordingly can see future potential speeds being significantly higher than current levels. A Puppy based on purely pointer driven file locations could be very small in size when the internet connection speed was adequately fast enough, or larger in size (files all local) for no/slow internet speeds.
I'm afraid is not looking very good.gyro wrote: The following is some example code for "init":
replacewithCode: Select all
[ -d /mnt/data${PSUBDIR} ] && FND_PUPSAVES="`find /mnt/data${PSUBDIR} -maxdepth 1 -xdev -type f -iname ${DISTRO_FILE_PREFIX}save*.[234]fs | grep -v ' ' | sed -e 's%^/mnt/data%%' | tr '\n' ' '`"
replaceCode: Select all
if [ -d /mnt/data${PSUBDIR} ]; then case $ONEFS in ext2|ext3|ext4|reiserfs|minix|f2fs) FND_PUPSAVES="`find /mnt/data${PSUBDIR} -maxdepth 1 -xdev -type d -iname ${DISTRO_FILE_PREFIX}save'*'| grep -v ' ' | sed -e 's%^/mnt/data%%' | tr '\n' ' '`" ;; esac [ "$FND_PUPSAVES" = "" ] && FND_PUPSAVES="`find /mnt/data${PSUBDIR} -maxdepth 1 -xdev -type f -iname ${DISTRO_FILE_PREFIX}save*.[234]fs | grep -v ' ' | sed -e 's%^/mnt/data%%' | tr '\n' ' '`" fi
withCode: Select all
else #pupsave not encrypted.
Note1: I have not got around to testing this yet.Code: Select all
elif [ -d /mnt/dev_save$PUPSAVEFILE ]; then mount --bind /mnt/dev_save${PUPSAVEFILE} $CREATEPUPSAVE2FS else #pupsave not encrypted.
Note2: Unfortunately a couple of the lines in the code are quite long, and get wrapped in this forum.
gyro
As I eluted to earlier the indicated changes a) will fail to find a savefile if it is also present, more important b) will result in a kernel panic.
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==
I have now tested my suggestion on Dpup Wheezy, and it basically works.
I have only changed the "init" script, nothing else.
So I had to manually setup the save folder using another puppy on the same machine.
I created a folder called "wheezysave" and copied the contents of the save file into it. Then removed the save file.
If a psubdir is specified, if a save folder is found, then this is used, else a save file is used.
b) If only the conceptual code from my previous post is applied, then using a save folder will result in a kernel panic.
The problem is that "mount" now lists the partition as mounted twice. Once at "/initrd/mnt/dev_save" and again at "/initrd/pup_rw".
So a number of lines in 'init' that process the output of "mount" need to be changed also.becomes
I think it might be this "mount" problem that causes a left click on the partitions icon to open more than 1 directory, in the running system.
I have edited my previous post to show the "mount" command I actually used.
gyro
I have only changed the "init" script, nothing else.
So I had to manually setup the save folder using another puppy on the same machine.
I created a folder called "wheezysave" and copied the contents of the save file into it. Then removed the save file.
a) All the save file finding code is still functional.mavrothal wrote:As I eluted to earlier the indicated changes a) will fail to find a savefile if it is also present, more important b) will result in a kernel panic.
If a psubdir is specified, if a save folder is found, then this is used, else a save file is used.
b) If only the conceptual code from my previous post is applied, then using a save folder will result in a kernel panic.
The problem is that "mount" now lists the partition as mounted twice. Once at "/initrd/mnt/dev_save" and again at "/initrd/pup_rw".
So a number of lines in 'init' that process the output of "mount" need to be changed also.
Code: Select all
PUPSFSDEVMNTPT="`mount | grep "$PPATTERN" | cut -f 3 -d ' '`"
Code: Select all
PUPSFSDEVMNTPT="`mount | grep "$PPATTERN" | head -n 1 | cut -f 3 -d ' '`"
I have edited my previous post to show the "mount" command I actually used.
gyro
Last edited by gyro on Mon 05 May 2014, 12:51, edited 1 time in total.
Here is a diff file for the "init" script from the "initrd.gz" of puppy_wheezy_3.5.2.11
gyro
gyro
- Attachments
-
- init_save_folder_diff.txt.gz
- gzip of diff file for "init"
- (649 Bytes) Downloaded 274 times
I applied the patch in slacko-5.7 and still get the kernel panic (with a slackosave folder that has the content of slackosave file)gyro wrote:Here is a diff file for the "init" script from the "initrd.gz" of puppy_wheezy_3.5.2.11
gyro
Below is diff of my init after the patch.
Code: Select all
--- a/init 2014-05-05 16:01:09.569997819 +0300
+++ b/init 2014-05-05 15:58:12.693308715 +0300
@@ -506,7 +506,15 @@
if [ "$SAVEPART" = "$ONEDEV" ];then
if [ "$PSUBDIR" ];then
#look in same subdir, then in '/' (maxdepth=1)...
- [ -d /mnt/data${PSUBDIR} ] && FND_PUPSAVES="`find /mnt/data${PSUBDIR} -maxdepth 1 -xdev -type f -iname ${DISTRO_FILE_PREFIX}save*.[234]fs | grep -v ' ' | sed -e 's%^/mnt/data%%' | tr '\n' ' '`"
+# [ -d /mnt/data${PSUBDIR} ] && FND_PUPSAVES="`find /mnt/data${PSUBDIR} -maxdepth 1 -xdev -type f -iname ${DISTRO_FILE_PREFIX}save*.[234]fs | grep -v ' ' | sed -e 's%^/mnt/data%%' | tr '\n' ' '`"
+#gyro
+ if [ -d /mnt/data${PSUBDIR} ]; then
+ case $ONEFS in
+ ext2|ext3|ext4|reiserfs|minix|f2fs) FND_PUPSAVES="`find /mnt/data${PSUBDIR} -maxdepth 1 -xdev -type d -iname ${DISTRO_FILE_PREFIX}save'*'| grep -v ' ' | sed -e 's%^/mnt/data%%' | tr '\n' ' '`" ;;
+ esac
+ [ "$FND_PUPSAVES" = "" ] && FND_PUPSAVES="`find /mnt/data${PSUBDIR} -maxdepth 1 -xdev -type f -iname ${DISTRO_FILE_PREFIX}save*.[234]fs | grep -v ' ' | sed -e 's%^/mnt/data%%' | tr '\n' ' '`"
+ fi
+#gyro
[ "$FND_PUPSAVES" = "" ] && FND_PUPSAVES="`find /mnt/data -maxdepth 1 -xdev -type f -iname ${DISTRO_FILE_PREFIX}save*.[234]fs | grep -v ' ' | sed -e 's%^/mnt/data%%' | tr '\n' ' '`"
else
FND_PUPSAVES="`find /mnt/data -maxdepth ${SEARCHDEPTH} -xdev -type f -iname ${DISTRO_FILE_PREFIX}save*.[234]fs | grep -v ' ' | sed -e 's%^/mnt/data%%' | tr '\n' ' '`"
@@ -516,7 +524,15 @@
else #101020
if [ "$PSUBDIR" ];then
#look in same subdir, then in '/' (maxdepth=1)...
- [ -d /mnt/data${PSUBDIR} ] && FND_PUPSAVES="`find /mnt/data${PSUBDIR} -maxdepth 1 -xdev -type f -iname ${DISTRO_FILE_PREFIX}save*.[234]fs | grep -v ' ' | sed -e 's%^/mnt/data%%' | tr '\n' ' '`"
+# [ -d /mnt/data${PSUBDIR} ] && FND_PUPSAVES="`find /mnt/data${PSUBDIR} -maxdepth 1 -xdev -type f -iname ${DISTRO_FILE_PREFIX}save*.[234]fs | grep -v ' ' | sed -e 's%^/mnt/data%%' | tr '\n' ' '`"
+#gyro
+ if [ -d /mnt/data${PSUBDIR} ]; then
+ case $ONEFS in
+ ext2|ext3|ext4|reiserfs|minix|f2fs) FND_PUPSAVES="`find /mnt/data${PSUBDIR} -maxdepth 1 -xdev -type d -iname ${DISTRO_FILE_PREFIX}save'*'| grep -v ' ' | sed -e 's%^/mnt/data%%' | tr '\n' ' '`" ;;
+ esac
+ [ "$FND_PUPSAVES" = "" ] && FND_PUPSAVES="`find /mnt/data${PSUBDIR} -maxdepth 1 -xdev -type f -iname ${DISTRO_FILE_PREFIX}save*.[234]fs | grep -v ' ' | sed -e 's%^/mnt/data%%' | tr '\n' ' '`"
+ fi
+#gyro
[ "$FND_PUPSAVES" = "" ] && FND_PUPSAVES="`find /mnt/data -maxdepth 1 -xdev -type f -iname ${DISTRO_FILE_PREFIX}save*.[234]fs | grep -v ' ' | sed -e 's%^/mnt/data%%' | tr '\n' ' '`"
else
FND_PUPSAVES="`find /mnt/data -maxdepth ${SEARCHDEPTH} -xdev -type f -iname ${DISTRO_FILE_PREFIX}save*.[234]fs | grep -v ' ' | sed -e 's%^/mnt/data%%' | tr '\n' ' '`"
@@ -1143,6 +1159,10 @@
if [ $PUPMODE -eq 12 -o $PUPMODE -eq 13 ];then #4+8 or 4+8+1
OLDDISTRO_VERSION="`grep '^DISTRO_VERSION' $CREATEPUPSAVE2FS/etc/DISTRO_SPECS | cut -f 2 -d '=' | cut -f 2 -d "'" | cut -f 2 -d '"' | cut -f 1 -d ' '`" #110422
if vercmp ${DISTRO_VERSION} gt ${OLDDISTRO_VERSION} ;then #110422
+#gyro
+ elif [ -d /mnt/dev_save$PUPSAVEFILE ]; then
+ mount -o bind /mnt/dev_save${PUPSAVEFILE} $CREATEPUPSAVE2FS
+#gyro
if [ "$NUMPUPSAVES" = "1" ];then #only one save-file was found.
echo -e "\\033[1;36m" >/dev/console #36=aquablue
echo "This save-file was last used with version $OLDDISTRO_VERSION of Puppy." >/dev/console
@@ -1182,7 +1202,9 @@
echo "'${basepupsfs}' now copying to hard drive (but only available next boot)..." >/dev/console
echo -en "\\033[0;39m" >/dev/console
PPATTERN="/dev/$xPUPSFSDEV "
- PUPSFSDEVMNTPT="`mount | grep "$PPATTERN" | cut -f 3 -d ' '`"
+#gyro
+# PUPSFSDEVMNTPT="`mount | grep "$PPATTERN" | cut -f 3 -d ' '`"
+ PUPSFSDEVMNTPT="`mount | grep "$PPATTERN" | head -n 1 | cut -f 3 -d ' '`"
if [ "$PUPSFSDEVMNTPT" = "" ];then
mntfunc $xPUPSFSFS /dev/$xPUPSFSDEV /mnt/dev_ro2 #-t $PUPSFSFS /dev/$PUPSFSDEV /mnt/dev_ro2
PUPSFSDEVMNTPT="/mnt/dev_ro2"
@@ -1394,7 +1416,9 @@
COPY2RAM='yes' #actually it is already in ram, but code below puts it in a tmpfs.
else
PPATTERN="/dev/$PUPSFSDEV "
- PUPSFSDEVMNTPT="`mount | grep "$PPATTERN" | cut -f 3 -d ' '`"
+#gyro
+# PUPSFSDEVMNTPT="`mount | grep "$PPATTERN" | cut -f 3 -d ' '`"
+ PUPSFSDEVMNTPT="`mount | grep "$PPATTERN" | head -n 1 | cut -f 3 -d ' '`"
if [ "$PUPSFSDEVMNTPT" = "" ];then
mntfunc $PUPSFSFS /dev/$PUPSFSDEV /mnt/dev_ro2 #-t $PUPSFSFS /dev/$PUPSFSDEV /mnt/dev_ro2
PUPSFSDEVMNTPT="/mnt/dev_ro2"
@@ -1455,7 +1479,9 @@
COPY2RAM='yes' #actually it is already in ram, but code below puts it in a tmpfs.
else
zPATTERN="/dev/$ZDEV "
- MNT_ZFILE="`mount | grep "$zPATTERN" | cut -f 3 -d ' '`"
+#gyro
+# MNT_ZFILE="`mount | grep "$zPATTERN" | cut -f 3 -d ' '`"
+ MNT_ZFILE="`mount | grep "$zPATTERN" | head -n 1 | cut -f 3 -d ' '`"
fi
ZBASENAME="`basename $ZFILE`" #v426 moved up.
if [ "$MNT_ZFILE" != "" ];then
@@ -1519,7 +1545,9 @@
AFILE="`echo "$ADRV" | cut -f 3 -d ','`"
MNT_AFILE=""
aPATTERN="/dev/$ADEV "
- MNT_AFILE="`mount | grep "$aPATTERN" | cut -f 3 -d ' '`"
+#gyro
+# MNT_AFILE="`mount | grep "$aPATTERN" | cut -f 3 -d ' '`"
+ MNT_AFILE="`mount | grep "$aPATTERN" | head -n 1 | cut -f 3 -d ' '`"
ABASENAME="`basename $AFILE`" #v426 moved up.
if [ "$MNT_AFILE" != "" ];then
if [ "$COPY2RAM" = "yes" ];then
@@ -1548,7 +1576,9 @@
YFILE="`echo "$YDRV" | cut -f 3 -d ','`"
MNT_YFILE=""
yPATTERN="/dev/$YDEV "
- MNT_YFILE="`mount | grep "$yPATTERN" | cut -f 3 -d ' '`"
+#gyro
+# MNT_YFILE="`mount | grep "$yPATTERN" | cut -f 3 -d ' '`"
+ MNT_YFILE="`mount | grep "$yPATTERN" | head -n 1 | cut -f 3 -d ' '`"
YBASENAME="`basename $YFILE`" #v426 moved up.
if [ "$MNT_YFILE" != "" ];then
if [ "$COPY2RAM" = "yes" ];then
@@ -1691,7 +1721,9 @@
FNDPART="`echo "$PCPARTS0" | grep "$udPTN1"`" #ex: sda1|ext3
if [ "$FNDPART" ];then
udPTN2="^/dev/${UNDERDOG} "
- UDMNTPT="`mount | grep "$udPTN2" | tr -s ' ' | cut -f 3 -d ' '`"
+#gyro
+# UDMNTPT="`mount | grep "$udPTN2" | tr -s ' ' | cut -f 3 -d ' '`"
+ UDMNTPT="`mount | grep "$udPTN2" | head -n 1 | tr -s ' ' | cut -f 3 -d ' '`"
if [ ! "$UDMNTPT" ];then #must not be mounted.
udFS="`echo -n "$FNDPART" | cut -f 2 -d '|'`"
mount -r -t $udFS /dev/$UNDERDOG /pup_ro${CNTLOOP}
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==
All about looks eh...
At firstrun shutdown its just a case of make the folder and copy
selectively the pup_rw into it rather than into the save file....almost
the same code as the save file but no save file making code and creation
time.
Double mount entry... might crop up elsewhere in need of a similar fix...
slax hides such things as the initrd and main system are not merged as
they are in puppy so those initrd mounts are effectively in a separete
chroot. A 'real' /mnt/sda(n) is made instead .
Just for the question of drifting into a full install....
This appraoch retains the frugal install of puppy. This uses a layered
filesystem...the save folder is just one layer. This means that the system
can for example be booted pristine with pfix=ram so easy to
fix/recover/experiment.
sfs modules are easily added and removed...either at boot or when running.
Robust read only core system.
Core can load to ram for speed... only changes are on the hard drive which
is also the case for a save file.
Dead easy to update...just change the pup_xxx.sfs
So in short all the advantages of a frugal save file based system but
without space restrictions or wastage.... also note ANY posix filessystem
can be used... reiserfs, XFS and others if you get the urge. All this
without losing the ability to have multiple installs on one partition.
mike
edit...i would have thought puppy is too changeable to apply a diff patch
made on one version to another reliably
At firstrun shutdown its just a case of make the folder and copy
selectively the pup_rw into it rather than into the save file....almost
the same code as the save file but no save file making code and creation
time.
Double mount entry... might crop up elsewhere in need of a similar fix...
slax hides such things as the initrd and main system are not merged as
they are in puppy so those initrd mounts are effectively in a separete
chroot. A 'real' /mnt/sda(n) is made instead .
Just for the question of drifting into a full install....
This appraoch retains the frugal install of puppy. This uses a layered
filesystem...the save folder is just one layer. This means that the system
can for example be booted pristine with pfix=ram so easy to
fix/recover/experiment.
sfs modules are easily added and removed...either at boot or when running.
Robust read only core system.
Core can load to ram for speed... only changes are on the hard drive which
is also the case for a save file.
Dead easy to update...just change the pup_xxx.sfs
So in short all the advantages of a frugal save file based system but
without space restrictions or wastage.... also note ANY posix filessystem
can be used... reiserfs, XFS and others if you get the urge. All this
without losing the ability to have multiple installs on one partition.
mike
edit...i would have thought puppy is too changeable to apply a diff patch
made on one version to another reliably
I'm not surprised that my diff file does not work against other puppy versions. To me it's just a single example of the concept working.
If this concept does not get included in woof-ce, then it will require sorting out for each individual "init" script.
The big downside to the concept is scripts that process the output of "mount" or "df" getting 2 results when they depend on getting 1 result.
I've changed how I modify these statements; instead of insertingI insertThis removes the extra entry that the change has produced, rather than assuming that the extra entry is always the second line.
Using this technique I fixed the "left click on the partitions icon" problem.
gyro
If this concept does not get included in woof-ce, then it will require sorting out for each individual "init" script.
The big downside to the concept is scripts that process the output of "mount" or "df" getting 2 results when they depend on getting 1 result.
I've changed how I modify these statements; instead of inserting
Code: Select all
| head -n 1
Code: Select all
| grep -v 'pup_pw'
Using this technique I fixed the "left click on the partitions icon" problem.
gyro
Last edited by gyro on Tue 06 May 2014, 05:44, edited 1 time in total.
Here is a diff file for the "init" script from the "initrd.gz" of puppy_slacko_5.7
gyro
gyro
- Attachments
-
- slacko_init_save_folder_diff.txt.gz
- gzip of diff file for "init" for slacko
- (610 Bytes) Downloaded 209 times
Here is the latest diff file for the "init" script from the "initrd.gz" of puppy_wheezy_3.5.2.11
The main difference is that it uses "grep" rather than "head" to get around the "mount" output problem.
gyro
The main difference is that it uses "grep" rather than "head" to get around the "mount" output problem.
gyro
- Attachments
-
- wheezy_init_save_folder_diff.txt.gz
- gzip of diff file for "init" for wheezy
- (626 Bytes) Downloaded 226 times
You beat me to itgyro wrote:Here is a diff file for the "init" script from the "initrd.gz" of puppy_slacko_5.7
gyro
The only thing different I did was is to remove the "-type d" argument so it can find both folders and files if present simultaneously, and remove the now needles separate search for savefiles.
The only thing is, that now you can not mask savefiles/folders by changing the savefile/savedir suffix (ie will also find "savefile.__2fs")
One strange behavior if you have a savefolder is that opening the boot partition with ROX opens 3 windows! The correct "/initrd/mnt/dev_save" and 2 /initrd_pup_rw" windows (true also when tested with your patch)
I guess savefolders confuse pmount/ROXapp.
Here it is for the history
- Attachments
-
- init_slacko.patch.gz
- init patch to detect both savefiles and savefolders simultaneously
- (1.32 KiB) Downloaded 206 times
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==
The problem is that the "AppRun" script for the icon, processes the output from a "df" command to find the mount point of the device. But gets confused when it receives 2 lines instead of 1. The solution is to insert " | grep -v 'pup_rw" into the command, to remove the extra line.mavrothal wrote:One strange behavior if you have a savefolder is that opening the boot partition with ROX opens 3 windows! The correct "/initrd/mnt/dev_save" and 2 /initrd_pup_rw" windows (true also when tested with your patch)
I guess savefolders confuse pmount/ROXapp.
I tried this on slacko and it works.
BUT, I'm editing the individual "AppRun" for the boot partition, I need to find how these ROXapps are generated, and fix it at the source.
gyro
Actually the source of the problem is that /dev/<boot_partition> is mounted both at /initrd/mnt/dev_save and /initrd/pup_rw
This may generate problems beyond pmount and ROXapps
Latter: Another problem that these init changes generate (regardless if a savefile or a savefolder is used) is that on version difference is proceeding to the update automatically without asking with the user to update or run in without a savefile.
Come to think of it savefolder might need a new pupmode between 12 (file) and 6 (partition), ie pupmode=9 where the CREATEPFOLDSV="/pup_rw" will be used instead.
Alternatively and maybe easier is to add code so when a savefolder is used /initrd/pup_rw to mount /dev/<boot_partition>/savefolder
Edit: add last sentence
This may generate problems beyond pmount and ROXapps
Latter: Another problem that these init changes generate (regardless if a savefile or a savefolder is used) is that on version difference is proceeding to the update automatically without asking with the user to update or run in without a savefile.
Come to think of it savefolder might need a new pupmode between 12 (file) and 6 (partition), ie pupmode=9 where the CREATEPFOLDSV="/pup_rw" will be used instead.
Alternatively and maybe easier is to add code so when a savefolder is used /initrd/pup_rw to mount /dev/<boot_partition>/savefolder
Edit: add last sentence
Last edited by mavrothal on Tue 06 May 2014, 12:31, edited 1 time in total.
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==