Hi everybody!
Sorry, just a little question... Trying Lazy as live from usb.

Clicking on the top bar for internet it says that there isn't sfs for firefox.
Then it asks for download it, after accept this the download starts (from smokey01) and then it seems ok.
But after good download a message appears, saying that it isn't ok.

Then, with Puppy package manager I select firefox and in this way everything runs fine.

You do mean the message about different md5sum found.

This means not necessary the SFS wasn't ok. This is mostly a result of different dates of creating the RunScript and uploading the SFS Module (after editing it again without to create a new RunScript). The md5sum-file is stored inside the RunScript's directory and created only when creating a RunScript. Just try run the application again - should work, though!

However: please do post anything about issues in LazY Puppy in its thread. I'm trying to keep this here divided from LazY Puppy as far as possible - thanks.

mikeb wrote:

Ok downloaded it, tried it but no sfs obtained perhaps the lack of DISTRO_FILE_PREFIX would be the reason.... something easily hacked or is there more to it?

partsman wrote:

@RSH
I tried the StandAlone-RunScript-RoxApp-Dir.tar.gz
Very impressive

Ok, so it doesn't work for mikeb, but it does for partsman.

@mikeb

Can you give more informationon what you did and what you mean by: perhaps the lack of DISTRO_FILE_PREFIX would be the reason.

Quote:

So just to clarify the use of sfs files and RSH script box are not the modular idea here "just a little extra bonus" am i right ?

RSHs-ScriptBox was just an addition to give anyone an easy start for testings. Actually it is a rough cut-down of the version that I'm using here - and turned it into EN for this (mine is DE only).

The Modular Concept is basically the use of SFS Modules, but refined/improved as they download, load and run the application by a RunScript - using sfs_load in cli mode only.

The SFS P.L.U.S. development toolkit is to be found inside the RSHs-ScriptBox in its directory Module.

1. LP3_SFS_PLUS_3.sfs
2. LP3_SFS_PLUS-3.9.3-install.pet

These two are needed to build/edit SFS Modules, create RunScripts, adding dependencies to SFS Modules and many more. just do a right-click onto a SFS Module or a directory and look at the options (most of them do start with SFS P.L.U.S. - I think).

Note: this version 3.9.3 can not create those StandAlone-RunScript-RoxApp-Dirs - this is new in my current version 3.9.4.

When it is version 4.0.x I will publish this as a release. This will include then (hopefully) a short guide to the use of it._________________LazY PuppyRSH's DNASARA B.

For those with frugal installs on a linux partition, using a "save directory" in place of a "save file" would be a very neat way to go.

Added this option several years ago and yes its works nicely. Was pretty simple and mainly involved the use of a bind mount.

I added it after using nimblex/slax's save folder option and having a full partition for temp storage is so much easier. Stilll have the same save folder created 5 years ago

I believe puppies pfix=fsck option does do partitions....since I have pups loading to ram along with the save I just manually fsck occasionally since nothing is mounted at boot though it could be automated in the rc.sysinit like for a full install rather than hacking the initrd.

archive/sfs save is no problem on ntfs....whether ntfs is a problem is another matter The improvements in hard drives seem to offset the weaknesses of FAT.

Instead I ran my Lucid which behaved a bit better.
It gave an error message at first but then did download the program.... it then downloaded java. It mounted sda3 and created a modules folder and added the first sfs to it and mounted it to pup_ro4. The java sfs never did and I could not find it. So closer..

here are distrospecs (comments removed) , or whats left of it and the pupstate

It gave an error message at first but then did download the program.... it then downloaded java. It mounted sda3 and created a modules folder and added the first sfs to it and mounted it to pup_ro4. The java sfs never did and I could not find it.

Quote:

PUPSAVE='ext2,sda3,/525_archive.sfs'

The use of 525_archive.sfs defined as the PUPSAVE of course was the reason for this. When a save file is in use, sfs_load tries to move/copy the SFS Modules. So, the java might have been copied to a black hole etc.pp.

When no save file is in use, sfs_load doesn't move the SFS Modules.

Oh, better saying here: lazy_sfs_load, because this one is used and it is modified to not to copy the SFS Module when no save file is in use.

I was not able to modify this also for the use of a save file - until now!

So, there are some good news.

The trick was: PSUBDIR has to be redirected inside of sfs_load to the directory used for the storage of the SFS Modules.

Also I have wrote a script, that will generate a temp DISTRO_SPECS if it is not existing.

well I can test pfix=ram if that helps but i assume you want to deal with all the variations that are present in puppy though mine are a bit different I try to keep them as compatible as possible. There are pups from 2.14x through to current in common use so thats a large base to try and cover.. I have a variety up to and including Lucid.

I noticed you did not load sfs to ram ...is that intentional or just for testing?

Ok well the sfs was saved to a folder modules on sda3 and mounted from there. If loaded to ram I would expect to find it in /initrd/mnt/tmpfs or similar. I only mentioned it as loading to ram was mentioned in earlier posts so wondered if you intended to do so.

So, if sda3 is your boot directory then it was intended to be saved in that directory and loaded from there.

If sda3 was the drive that you have had entered into the file download_dir_temp, then it was intended to be saved in that directory and loaded from there.

The RunScript uses this directory in its definitions.

Change these two entries:

Code:

DISPLAYRUNOVERRIDE="Module"
DISPLAYRUNOVERRIDELPBPLOPT="true"

to false and it should download to the boot directory and loaded from there.

Though, I don't know if the SFS will load into RAM after this...

Attached a new Standalone RunScript RoxApp Directory for some testings. I could not test running it when booting from CD. Anything else seems to work - even if there is no DISTRO_SPECS file existing.

EDIT:

I did try to upload a version for SquashFS-3 files, but when trying to download I did get a 403 Error about wrong permissions. Don't know how to fix this for SquashFS-3 version files. So, currently no option to test this for older puppies.

OK was having too much fun in windows but eventually reset to test in Lucid.

Ok seems like all worked and ran with save loaded.

Main file and dependency downloaded to modules on sda3 (was unmounted for test) ...they ran and gave the messages.
Both items appeared in the menu (under utility) and the right click unload option worked.

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