Tiny syntax error (v2) at line 124
Code: Select all
case "$M" in
info|warning|error|question) MARK="dialog-$M";;
*) MARK="$M"
esac
Code: Select all
*) MARK="$M" ;;
Cheers
Code: Select all
case "$M" in
info|warning|error|question) MARK="dialog-$M";;
*) MARK="$M"
esac
Code: Select all
*) MARK="$M" ;;
Right. I am wondering why the sfs_load does not. Checking it up more...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).
Confirmed the sfs_load does not work with Puppy-4.2.1.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 ?
Aaaaah, that's what I was waiting for...shinobar wrote: Supports Puppy-4.2.1.
Basically same method i guess. The sfs_load is designed to keep the compatibility with traditional bootmanager.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)
No. The sfs_loader keeps the compatibility with the traditional bootmanager and has same limit.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!)
Yes.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 checking, but does not have the button or launcher.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, you can. Well... i wonder why the goingnuts otf-sfs cannot. Maybe for the auto converting the sfs version?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...)
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).shinobar wrote:No. The sfs_loader keeps the compatibility with the traditional bootmanager and has same limit.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!)
Barry thinks too many layers to the unionfs slows down the performance.
Ah...you are right.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
Code: Select all
BASELIST=$( echo "$BASEFIXEDSFSLIST" | sort | uniq)
#echo "$BASEFIXEDSFSLIST" | sort | uniq
Code: Select all
loadable_sfs_list
#BASELIST=$(loadable_sfs_list)
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?).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!
APOLOGIES FOR OT RESPONSE01micko 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)
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.jemimah wrote:I think it makes more sense to use the word "temporary" instead of "tentative" to describe changes that may not be saved.