(old)Puppy Linux Discussion Forum

Posted: **Sat 29 Jan 2011, 21:37**

Hi shino

Tiny syntax error (v2) at line 124

case "$M" in
  info|warning|error|question) MARK="dialog-$M";;
  *) MARK="$M"
  esac

should be

Code: Select all

*) MARK="$M" ;;

I think

Cheers

Posted: **Sat 29 Jan 2011, 22:39**

rodin.s wrote:Works OK now with or without pupsave, but maybe it should run fixmenus after unloading SFS to remove menu entries of unloaded SFS. Tested on Wary-5.0 (original and multilingual).

Right. I am wondering why the sfs_load does not. Checking it up more...
EDIT: Got it now.

@01micko. Thanks for the debugging.

Both will be fixed at next release.

Posted: **Sun 30 Jan 2011, 01:35**

nancy reagan wrote:As I like the sfs method, on my 128mb toshiba, I mainly use choicepup 4.1.2 cd with jrb's pre installed "open with sfs load/unload" and sfs 412 on usb.
Simultaneously I use your pupsaveconfig, pupsave=-0 (never) pupmode =13 .
When I tried yours, it said "failed to append "initrd/pup-ro4" to unionfs. "x-sfs moved to initrd/mnt/dev_save"
Maybe cause jrb's is already in there ?

Confirmed the sfs_load does not work with Puppy-4.2.1.
I can manage it and will be fixed at next release.

Posted: **Sun 30 Jan 2011, 03:32**

This increases the attractiveness of separating out seldom used apps into their own SFS. (or theme/task groups).

Posted: **Sun 30 Jan 2011, 08:03**

UPDATE:
30 Jan 2011 v0.3: unionfs mount option, fix menu update after unload
Supports Puppy-4.2.1.

EDIT:
Also tested on 4.1.2 and 4.3.1.
That is, tested and works: Puppy-4.1 through 5.0(wary) and 5.2(Lucid).
But seems not work on Puppy-4.0.

Posted: **Sun 30 Jan 2011, 10:14**

shinobar wrote: Supports Puppy-4.2.1.

Aaaaah, that's what I was waiting for...

I am in the middle of testing other things, so cannot install this one yet, so have a few questions:

1. How does this differ from the otf-sfs-loader by goingnuts? Does it use the same method?
(Because the goingnuts otf-sfs-loader doesn't work in puppy 5)

2. Does this allow users to change the maximum number of loops available - so that users can choose how many SFSs are loaded on the fly?
(Very useful!)

3. Have you added ROX right click options for SFS files to load them?
I did it in Puplite, it is very convenient!

3. Do you check for incompatible SFS version, and load Trios SFS convertor, if it is installed?
(That would be great, I will do it in Puplite.)

4. Can I load a 200mb SFS file on the fly, using only a 128mb save file?
(Because when using the goingnuts otf-sfs script, the size of any SFS file loaded on the fly must not be larger than the free space in the save file, during initial unsquashing...)

Sorry for all the questions!

Posted: **Sun 30 Jan 2011, 11:38**

sc0ttman wrote:1. How does this differ from the otf-sfs-loader by goingnuts? Does it use the same method?
(Because the goingnuts otf-sfs-loader doesn't work in puppy 5)

Basically same method i guess. The sfs_load is designed to keep the compatibility with traditional bootmanager.
Of course there are small tweaks matching with Various Puppy versions. The sfs_load is tested on Puppy version 4.1 through 5.0(wary) and 5.2(lucid).

sc0ttman wrote:2. Does this allow users to change the maximum number of loops available - so that users can choose how many SFSs are loaded on the fly?
(Very useful!)

No. The sfs_loader keeps the compatibility with the traditional bootmanager and has same limit.
Barry thinks too many layers to the unionfs slows down the performance.

EDIT: sfs_load-0.9 and later supports sfs more than 6(experimental). I don't know the upper limit

sc0ttman wrote:3. Have you added ROX right click options for SFS files to load them?
I did it in Puplite, it is very convenient!

Yes.

sc0ttman wrote:3. Do you check for incompatible SFS version, and load Trios SFS convertor, if it is installed?
(That would be great, I will do it in Puplite.)

Yes checking, but does not have the button or launcher.
I think the sfs version converting is not so easy for beginners.
It consumes large space and requires Linux partition or work space.

sc0ttman wrote:4. Can I load a 200mb SFS file on the fly, using only a 128mb save file?
(Because when using the goingnuts otf-sfs script, the size of any SFS file loaded on the fly must not be larger than the free space in the save file, during initial unsquashing...)

Yes, you can. Well... i wonder why the goingnuts otf-sfs cannot. Maybe for the auto converting the sfs version?

Posted: **Sun 30 Jan 2011, 13:48**

shinobar wrote:
sc0ttman wrote:2. Does this allow users to change the maximum number of loops available - so that users can choose how many SFSs are loaded on the fly?
(Very useful!)
No. The sfs_loader keeps the compatibility with the traditional bootmanager and has same limit.
Barry thinks too many layers to the unionfs slows down the performance.

I know what you're feeling about this. That being said, can I persuade you to implement a "non-persistent" SFS loading beyond the traditional 6 SFSes limit? Yes I know it may be slow - you can include a pop-up warning etc when a user tries do this - but it has its uses, especially for testing multiple SFS-es ==> however slow it is, it's still faster than a reboot, and some of us can live with the degraded performance. Especially since the newer kernels have dynamic loop devices (for older kernels, you can disable this functionality).

For your consideration. And thanks for this.

cheers!

Posted: **Sun 30 Jan 2011, 18:58**

When I choose sfs-file from the pulldown it doesn't work, but works OK with drug and drop into the field 'Which sfs do you want to load?' More info on the picture. (Wary-5.0)

Posted: **Sun 30 Jan 2011, 19:17**

Worked nicely in Lucid 5.2 with an extra.sfs package that contained apps/files from remastered lucid_520.sfs. Apps installed/uninstalled without rebooting, and worked fine. After uninstalling, a few empty links remained, but it got everything else. Thanks shinobar...very useful utility.

Posted: **Sun 30 Jan 2011, 20:56**

Thanks for your answers. Keep up the good work.

Posted: **Mon 31 Jan 2011, 02:21**

rodin.s wrote:When I choose sfs-file from the pulldown it doesn't work, but works OK with drug and drop into the field

Ah...you are right.
Quick hacks at /usr/sbin/sfs_load:
Enable the line 371 and the line 372 to be commented out:

Code: Select all

    BASELIST=$( echo "$BASEFIXEDSFSLIST" | sort | uniq)
    #echo "$BASEFIXEDSFSLIST" | sort | uniq

Rewrite the line 386:

Code: Select all

    loadable_sfs_list
    #BASELIST=$(loadable_sfs_list)

Thanks.

Posted: **Mon 31 Jan 2011, 02:57**

Thanks shinobar your application is very handy - load from drop down menu fix is working here on Lucid 5.2

Posted: **Mon 31 Jan 2011, 07:27**

Deleted

Posted: **Mon 31 Jan 2011, 08:33**

I like this one shino (with the small fix you posted)

Working well in spup-055 and latest puppeee 4.4beta8. (sd card installs on the one disk using grub4dos to boot, so PUPMODE=13 for both).(also ok in spup on main box, PUPMODE=12).

One thing, age old puppy bug, the desktop icons mess up after a reboot (only if you customise your pinboard). I think it's something to do with the layering order, where the main sfs takes priority. I hate that bug!

Nice work and I will include in next spup for broader testing.

Cheers

EDIT: shino, the rox pinboard is not your problem. The main sfs contains a hard coded pinboard. The main sfs will always take priority and that's fine. The real fix is to create the pinboard in the init scripts, I might work on that one

(sorry a bit off topic)

Posted: **Mon 31 Jan 2011, 09:29**

Thanks for testing, jpeps, stu90 and mick.

01micko wrote:One thing, age old puppy bug, the desktop icons mess up after a reboot (only if you customise your pinboard). I think it's something to do with the layering order, where the main sfs takes priority. I hate that bug!

The sfs_load appends the extra sfs at the last layer, and doesn't run the rc.update(should run because of the pinboard issue?).
At the reboot, the initrd ignores the directed order of the extra sfs, and re-arrange maybe by the filename.
So, sometimes the order is modified and the rc.update runs, and sometimes does not.
Yes, i think it a bug of the woof on the order of the extra sfs's.

The initrd of Puppy-431JP(Japanese edition) and of LupQ-511 keeps the directed order of the extra sfs, and the main sfs at the last.
It may cause troubles with improperly prepaired sfs's, and makes serious issue with some devx.sfs.
So i conclude that the main sfs is better to be at the top as the tradition, but the extra sfs's should be in the order of 'EXTRASFSLIST' written in the '/etc/rc.d/BOOTCONFIG'.

EDIT: Sorry, the discussion i made here is on somewhat different topic.
As for the pinboard, the issue is the sfs_loader does not run the rc.update, but the rc.update runs at the next reboot...

EDIT2: sfs_load-0.9 and later handles the puppypin.

Posted: **Tue 01 Feb 2011, 00:05**

I think it makes more sense to use the word "temporary" instead of "tentative" to describe changes that may not be saved.

Posted: **Tue 01 Feb 2011, 09:01**

01micko wrote:
EDIT: shino, the rox pinboard is not your problem. The main sfs contains a hard coded pinboard. The main sfs will always take priority and that's fine. The real fix is to create the pinboard in the init scripts, I might work on that one (sorry a bit off topic)

APOLOGIES FOR OT RESPONSE
I'm surprised that this hasn't already been done, given the ongoing complaints. Or if it isn't so simple, an "autorestore last setup" could be put in the menu for nubees to click on....end of complaints. (the globicons symlink isn't always so obvious).

Jammed this together for starters:
http://murga-linux.com/puppy/viewtopic. ... 976#491976

Posted: **Wed 02 Feb 2011, 01:21**

Possible bug: It's looking like SFS files still need to be in /mnt/home to survive a reboot that updates the layered filesystem. Otherwise, the SFS displays as loaded when it isn't.

Posted: **Wed 02 Feb 2011, 01:59**

jemimah wrote:I think it makes more sense to use the word "temporary" instead of "tentative" to describe changes that may not be saved.

I guess "tentative" means "dependent on" whether the layered filesytem gets updated, and if the SFS is located in /mnt/home when it is. Shouldn't be any more temporary than a traditional mount. For temporary on-the-fly....drag from a location other than /mnt/home.

(old)Puppy Linux Discussion Forum

sfs_load-2.4 on-the-fly

menu update

Re: choicepup cd

sfs_load-0.3

Re: sfs_load-0.3

Re: sfs_load-0.3

Re: sfs_load-0.3

sfs_load-0.3

quick hack against sfs_load-0.3

Extra sfs order