SFS Load on the Fly - I have to load my sfs on every boot

Miscellaneous tools
Post Reply
Message
Author
tenochslb

SFS Load on the Fly - I have to load my sfs on every boot

#1 Post by tenochslb »

Something is not working right with SFS Load on the Fly. Since a few days back, I need to load all my SFSes every time I turn on the computer. Before that, puppy would remember the sfses loaded on the system, so:

1. I turn on the computer
2. There are no sfs files loaded
3. I load my sfs files
4. turn off the computer
5. turn on the computer
6. There are no sfs loaded
7. Go to 1 (infinite loop)

Hopefully you can help me figure out what is wrong.

Code: Select all

▶—— /etc/rc.d/PUPSTATE ——◀

 • PUPMODE=12
 • PDEV1='sda4'
 • DEV1FS='ext3'
 • PUPSFS='sda4,ext3,/tarh64/puppy_tahr64_6.0.6.sfs'
 • PUPSAVE='sda4,ext3,/tarh64/tahr64save-version1.0'
 • PMEDIA='scsihd'

ATADRIVES is all internal ide/pata/sata drives, excluding optical, excluding usb...
 • ATADRIVES='sda '

ATAOPTICALDRIVES is list of non-usb optical drives...
 • ATAOPTICALDRIVES='sr0 '

These directories are unionfs/aufs layers in /initrd...
 • SAVE_LAYER='/pup_rw'
 • PUP_LAYER='/pup_ro2'

The partition that has the tahr64save file is mounted here...
 • PUP_HOME='/mnt/dev_save'
(in /initrd) ...note, /mnt/home is a link to it.

This file has extra kernel drivers and firmware...
 • ZDRV='sda4,ext3,/tarh64/zdrv_tahr64_6.0.6.sfs'
 • FDRV=''
 • ADRV=''
 • YDRV=''

Partition no. override on boot drive to which session is (or will be) saved...
 • PSAVEMARK=''
 • PSAVEPART=''
 • PSAVEDIR=''
 • PSUBDIR='/tarh64'

▶—— Common Pupmodes ——◀

PUPMODE 02 : full install
PUPMODE 03 : full install, flash drive
PUPMODE 05 : first boot [or pfix=ram]
PUPMODE 06 : pup_save is a partition
PUPMODE 07 : ditto, but flash drive
PUPMODE 12 : normal running puppy
PUPMODE 13 : ditto, but flash drive
PUPMODE 77 : multisession cd/dvd [13+64]

User avatar
nic007
Posts: 3408
Joined: Sun 13 Nov 2011, 12:31
Location: Cradle of Humankind

#2 Post by nic007 »

Try to load the extra sfs's via the Boot Manager under System in the menu.

User avatar
Marv
Posts: 1264
Joined: Wed 04 May 2005, 13:47
Location: SW Wisconsin

#3 Post by Marv »

Is the save file working at all? Create a dummy test file somewhere and reboot to test that. Also, with sda4 unmounted (USB, CD or ram boot), run e2fsck on /dev/sda4. The fact that it was working, then stopped, might point to a problem with sda4...
Pups currently in kennel :D Older LxPupSc and X-slacko-4.4 for my users; LxPupSc, LxPupSc64 and upupEF for me. All good pups indeed, and all running savefiles for look'n'feel only. Browsers, etc. solely from SFS.

TenochSLB2
Posts: 6
Joined: Sat 13 Oct 2018, 00:50

#4 Post by TenochSLB2 »

nic007 wrote:Try to load the extra sfs's via the Boot Manager under System in the menu.
No change, I continue to have to load the sfs files.

TenochSLB2
Posts: 6
Joined: Sat 13 Oct 2018, 00:50

#5 Post by TenochSLB2 »

Marv wrote:Is the save file working at all? Create a dummy test file somewhere and reboot to test that. Also, with sda4 unmounted (USB, CD or ram boot), run e2fsck on /dev/sda4. The fact that it was working, then stopped, might point to a problem with sda4...
The dummy test file works fine, in other words, I do not have to load my sfs files on every time I need to start puppy when using the new savefolder.

e2fsck returns no errors.

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

#6 Post by bigpup »

Now we need to figure out what is wrong or missing in the old save.

Boot not using the old save.
In Rox file manager.
Navigate to the old save and left click on it to show what is in it.
Navigate to the /etc/rc.d directory in the old save.
Should be two files in it that should have info on sfs loading.
BOOTCONFIG
BOOTCONFIG.save

This is examples of info that should be in these files:
(this is a Xenialpup64save for example)
In BOOTCONFIG:
Notice the XTRASFSLIST= entry.

BOOTCONFIG
XTRASFSLIST='kodi-17.6-x86_64.sfs devx_xenialpup64_7.5.sfs 32bit_compatibility_libs_xenial64.sfs SlimJet-16.0.8.0-amd64-tahr.sfs'
PREVUNIONRECORD='xenialpup64save-1 puppy_xenialpup64_7.5.sfs zdrv_xenialpup64_7.5.sfs'
LASTUNIONRECORD='xenialpup64save-1 puppy_xenialpup64_7.5.sfs zdrv_xenialpup64_7.5.sfs'
BOOTCONFIG.save
PREVEXTRASFSLIST='devx_xenialpup64_7.5.sfs kernel_sources-4.9.58-xenialpup64.sfs 32bit_compatibility_libs_xenial64.sfs LibreOffice-5.4.2_en-US_xz.sfs'
Notice they have info about the sfs's to load.
If there is no info these files are bad in the old save.
(BOOTCONFIG.save may not have anything listed unless you made a change to what gets loaded. It is a save of the old listing)


Try replacing them with the good ones in the new save.

The question is still there. Why in the old save, these files are not getting updated and saved with the changes.
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)

User avatar
nic007
Posts: 3408
Joined: Sun 13 Nov 2011, 12:31
Location: Cradle of Humankind

#7 Post by nic007 »

Place your extra sfs files in the same directory as the puppy files if not. BTW - if you still can't get it right and have to load it during the session, try the following command which will load it automatically during bootup:
sfs_load -c -q FullPathOfSfsFile eg: /mnt/home/tahr64/Wine.sfs
You can add the above command to the /etc/rc.d/rc.local file. You can add the path and names of all those sfs's you want to load next to each other in the same command.

sheldonisaac
Posts: 902
Joined: Mon 22 Jun 2009, 01:36
Location: Philadelphia, PA

#8 Post by sheldonisaac »

nic007 (in part) wrote: sfs_load -c -q FullPathOfSfsFile eg: /mnt/home/tahr64/Wine.sfs
You can add the above command to the /etc/rc.d/rc.local file. You can add the path and names of all those sfs's you want to load next to each other in the same command.
Thank you, nicoo7! How did you find out that command?

And, if loading more than one, how to say it? Separate with spaces, or commas, ..?

And thanks to bigpup re the files to check.


Thanks a lot,
Sheldon
Dell E6410: BusterPup, BionicPup64, Xenial, etc
Intel DQ35JOE, Dell Vostro 430
Dell Inspiron, Acer Aspire One, EeePC 1018P

User avatar
nic007
Posts: 3408
Joined: Sun 13 Nov 2011, 12:31
Location: Cradle of Humankind

#9 Post by nic007 »

sheldonisaac wrote:
nic007 (in part) wrote: sfs_load -c -q FullPathOfSfsFile eg: /mnt/home/tahr64/Wine.sfs
You can add the above command to the /etc/rc.d/rc.local file. You can add the path and names of all those sfs's you want to load next to each other in the same command.
Thank you, nicoo7! How did you find out that command?

And, if loading more than one, how to say it? Separate with spaces, or commas, ..?

And thanks to bigpup re the files to check.


Thanks a lot,
Sheldon
Been doing it for a long time because I don't use a savefile/savefolder. Just a space between (best to use the full path of every file). If that doesn't quite work as it should you can use the command for every sfs file seperately, every command on a next line. If I'm not mistaken wildcards also work (haven't tried it for a long time so no guarantee), in other words if you want to load all sfs files in a directory:
sfs_load -c -q /mnt/home/tahr64/*.sfs
To unload, add -u as an option.

TenochSLB2
Posts: 6
Joined: Sat 13 Oct 2018, 00:50

#10 Post by TenochSLB2 »

bigpup wrote:Now we need to figure out what is wrong or missing in the old save.

Boot not using the old save.
In Rox file manager.
Navigate to the old save and left click on it to show what is in it.
Navigate to the /etc/rc.d directory in the old save.
Should be two files in it that should have info on sfs loading.
BOOTCONFIG
BOOTCONFIG.save

This is examples of info that should be in these files:
(this is a Xenialpup64save for example)
In BOOTCONFIG:
Notice the XTRASFSLIST= entry.

BOOTCONFIG
XTRASFSLIST='kodi-17.6-x86_64.sfs devx_xenialpup64_7.5.sfs 32bit_compatibility_libs_xenial64.sfs SlimJet-16.0.8.0-amd64-tahr.sfs'
PREVUNIONRECORD='xenialpup64save-1 puppy_xenialpup64_7.5.sfs zdrv_xenialpup64_7.5.sfs'
LASTUNIONRECORD='xenialpup64save-1 puppy_xenialpup64_7.5.sfs zdrv_xenialpup64_7.5.sfs'
BOOTCONFIG.save
PREVEXTRASFSLIST='devx_xenialpup64_7.5.sfs kernel_sources-4.9.58-xenialpup64.sfs 32bit_compatibility_libs_xenial64.sfs LibreOffice-5.4.2_en-US_xz.sfs'
Notice they have info about the sfs's to load.
If there is no info these files are bad in the old save.
(BOOTCONFIG.save may not have anything listed unless you made a change to what gets loaded. It is a save of the old listing)


Try replacing them with the good ones in the new save.

The question is still there. Why in the old save, these files are not getting updated and saved with the changes.
During the first boot after replacing the BOOTCONFIG and BOOTCONFIG.save from the old savefolder (not working) with new files from the dummy (working) savefolder, the sfses listed on those files are loaded, however, after the first reboot the same problem occurs, NO sfs are loaded again.

Here is an image with information that I think could be useful to figure out what is going on:

Image
DIRECT LINK TO HQ IMAGE: https://i.postimg.cc/66ghWHMh/ilustraci ... dolder.png

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

#11 Post by bigpup »

In the old save that is not working correctly.
/etc/rc.d
There is a pupsave.conf file.

Can you post what is in it.
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)

TenochSLB2
Posts: 6
Joined: Sat 13 Oct 2018, 00:50

#12 Post by TenochSLB2 »

bigpup wrote:In the old save that is not working correctly.
/etc/rc.d
There is a pupsave.conf file.

Can you post what is in it.

Code: Select all

PRECHOICE=no
POPUP=no

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

#13 Post by bigpup »

pupsave.conf

Not sure why you have this in old save. It is not in my save for an install of Tahrpup64 6.0.6.

Try moving the pupsave.conf file out of the save so it is not there.
Copy it to some location away from the Tahrpup64 6.0.6 install. Delete it from the save /etc/rc.d

Any help using the old save?

In the old save you probably have programs you installed.
Are you by any chance using some shutdown control program you installed? Like Pupshutdown.
Something other than what is in Tahrpup.
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)

TenochSLB2
Posts: 6
Joined: Sat 13 Oct 2018, 00:50

#14 Post by TenochSLB2 »

bigpup wrote: Try moving the pupsave.conf file out of the save so it is not there.
Copy it to some location away from the Tahrpup64 6.0.6 install. Delete it from the save /etc/rc.d

Any help using the old save?
I removed it, apparently nothing changed.

Here is the content of rc.d without pupsave.conf

Code: Select all

root# ls -ag /mnt/home/tarh64/tahr64save-version1.0/etc/rc.d/
total 188
drwxr-xr-x  9 root  4096 Oct 13 13:49 .
drwxr-xr-x 44 root  4096 Oct 14  2018 ..
-rw-r--r--  1 root   186 Oct 13  2018 BOOTCONFIG
-rw-r--r--  1 root   186 Oct 14  2018 BOOTCONFIG.save
-rw-r--r--  1 root 11918 Jan 30  2017 functions4puppy
-rw-r--r--  1 root  5945 Jan 30  2017 functions4puppy4
-rw-r--r--  1 root  2769 Oct 12 05:21 MODULESCONFIG
-rw-r--r--  1 root   831 Oct 13  2018 PUPSTATE
drwxr-xr-x  2 root  4096 Apr  6  2018 rc0.d
drwxr-xr-x  2 root  4096 Apr  6  2018 rc1.d
drwxr-xr-x  2 root  4096 Apr  6  2018 rc2.d
drwxr-xr-x  2 root  4096 Apr  6  2018 rc3.d
drwxr-xr-x  2 root  4096 Apr  6  2018 rc4.d
drwxr-xr-x  2 root  4096 Apr  6  2018 rc5.d
drwxr-xr-x  2 root  4096 Apr  6  2018 rc6.d
-rwxr-xr-x  1 root  6706 Jan 30  2017 rc.country
-rw-r--r--  1 root  1387 Oct 12 10:22 rc.local
-rwxr-xr-x  1 root 26860 Mar  7  2010 rc.network
-rwxr-xr-x  1 root   311 Jan 30  2017 rc.services
-rwxr-xr-x  1 root 18022 Oct 12 10:22 rc.shutdown
-rwxr-xr-x  1 root 33290 Jan 30  2017 rc.sysinit
-rwxr-xr-x  1 root 15381 Jan 30  2017 rc.update
bigpup wrote: Are you by any chance using some shutdown control program you installed? Like Pupshutdown.
Something other than what is in Tahrpup.
Not that I am aware of, I always turn OFF the computer through MENU>EXIT>SHUTDOWN

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

#15 Post by bigpup »

During the first boot after replacing the BOOTCONFIG and BOOTCONFIG.save from the old savefolder (not working) with new files from the dummy (working) savefolder, the sfses listed on those files are loaded, however, after the first reboot the same problem occurs, NO sfs are loaded again.
Something seems to be deleting the info in the BOOTCONFIG file.

Boot using the old save.

In a console run this command.

Code: Select all

sfs_load
Maybe it will show some error.

It will show something like this if it is working correctly.
In this example the sfs's are on sdc3 /mnt/home

Code: Select all

root# sfs_load
sfs_load: debug: PUPHOME=/mnt/home;
sfs_load: debug: SFSMODE=y, DESTPART=sdc3, DESTDIR=/mnt/home;
sfs_load: debug: loadable_sfs_list
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)

TenochSLB2
Posts: 6
Joined: Sat 13 Oct 2018, 00:50

#16 Post by TenochSLB2 »

bigpup wrote: In a console run this command.

Code: Select all

sfs_load
Maybe it will show some error.

It will show something like this if it is working correctly.
In this example the sfs's are on sdc3 /mnt/home

Code: Select all

root# sfs_load
sfs_load: debug: PUPHOME=/mnt/home;
sfs_load: debug: SFSMODE=y, DESTPART=sdc3, DESTDIR=/mnt/home;
sfs_load: debug: loadable_sfs_list

Code: Select all

root# sfs_load 
sfs_load: debug: Using /usr/bin/gtkdialog4.
sfs_load: debug: SUPPORTSIG=green, SFSMODE=y, DESTPART=sda4, DESTDIR=/mnt/home;
sfs_load: debug: MAXEXTRANUM=0
sfs_load: debug: loadable_sfs_list 
sfs_load: debug: EXIT="abort"
/usr/sbin/sfs_load: line 847: 20094 Terminated              $GTKDIALOG -p DIALOG -c > /dev/null
sfs_load: --stop

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

#17 Post by bigpup »

This part of your posted results is normal. It is just info about closing the program.

Code: Select all

/usr/sbin/sfs_load: line 847: 20094 Terminated              $GTKDIALOG -p DIALOG -c > /dev/null
sfs_load: --stop 

This is what I get in a working Tahrpup64 6.0.6

Code: Select all

root# sfs_load
sfs_load: debug: PUPHOME=/mnt/home;
sfs_load: debug: SUPPORTSIG=green, SFSMODE=y, DESTPART=sdc6, DESTDIR=/mnt/home;
sfs_load: debug: loadable_sfs_list 
sfs_load: debug: FILE1=""
UNLOADSFS=""
EXIT="Abort"
I am just giving you ideas to try.
When you start SFS-Load-on-the-fly it does say it is V3.0?

Look at the contents of the save by left clicking on it in Rox file manager.
Navigate to /usr/sbin in the save.
There should be nothing there about sfs_load.
If there is delete it.

The easy fix is to replace the bad save with the good working backup save, we know you made earlier :!: :lol:

Tracking down a cure, for a broken Puppy save, is a deep hunt, in the deep tangled Puppy OS file system. Never know what you will find or how you will find it!
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)

Post Reply