(old)Puppy Linux Discussion Forum

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:

    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.

Posted: **Thu 03 Feb 2011, 21:57**

This is why I like calculators that round correctly:

179: echo "$(dc $MB 1024 \/ p|sed -e 's/$^.*\..$.*/\1/')GB"

echo "$(mc $MB/1024 -s1)GB"
http://murga-linux.com/puppy/viewtopic.php?t=62969

Posted: **Thu 03 Feb 2011, 23:53**

Some comments and feedback:

1. Would be useful to add option for "non-persistent change" (doesn't persist across reboots - i.e. don't touch SFSLIST) - especially useful for people (=me

) who runs at full capacity (6 SFS) and want to change / swap SFS for one session only. E.g. unload openoffice to be able to load something else.

2. As in my earlier comment, if you don't mind adding "non-persistent" loading of SFS beyond the original 6 SFS limit.

3. Does on the fly sfs loading / unloading works with pfix=nocopy option? (ie /pup_rw points to the disk rather than tmpfs)?

4. This is specific occurence, happenng in Fatdog I'm running at full capacity - 6 SFS. I can unload openoffice, but when I tried to load it again I always get an error --- it says the SFS doesn't exist. It's available on the left-hand selection, though, it's only after I selected and click ok - I'm asked whether I want to load it (and says size unknown), after I click it, I get an error saying this sfs is not found. This is what the console output looks like:

Code: Select all

SFS-Load: FILE1="go-oo_32_amd64-3.sfs"
LOADCHK="true"
LOADTXT=""
UNLOADCHK="false"
UNLOADSFS="audio-all-in-one-amd64-8.sfs"
UNLOADSFS_ALL="'audio-all-in-one-amd64-8.sfs' 'fd64-32bit-libs-4.sfs' 'fd64-devx_510.sfs' 'jre160_amd64-3.sfs' 'wine-1.3.8-i486.sfs'"
UNLOADTXT=""
EXIT="OK"
/usr/sbin/sfs_load: line 442: 20401 Terminated              gtkdialog3 -p DIALOG -c > /dev/null
SFS-Load: go-oo_32_amd64-3.sfs
du: cannot access `go-oo_32_amd64-3.sfs': No such file or directory
SFS-Load: FILEISAT=unionfs
SFS-Load: Do you want to load 'go-oo_32_amd64-3.sfs(filesize: unknown)'?

SFS-Load: 'go-oo_32_amd64-3.sfs' not found.

All my SFS are stored in /mnt/home.

Posted: **Fri 04 Feb 2011, 00:02**

jamesbond

I think the little bugfix toward the top of this page in shinobar's post fixes issue number 4.

Cheers

4. This is specific occurence, happenng in Fatdog I'm running at full capacity - 6 SFS. I can unload openoffice, but when I tried to load it again I always get an error --- it says the SFS doesn't exist. It's available on the left-hand selection, though, it's only after I selected and click ok - I'm asked whether I want to load it (and says size unknown), after I click it, I get an error saying this sfs is not found.

Posted: **Fri 04 Feb 2011, 00:24**

Thanks 01micko, I will try that. Somehow I got the wrong impression that this fix has been incorporated into version 3. Will let you know.

EDIT: it works now, thanks.

cheers!

Posted: **Fri 04 Feb 2011, 01:47**

jamesbond wrote:3. Does on the fly sfs loading / unloading works with pfix=nocopy option? (ie /pup_rw points to the disk rather than tmpfs)?

Answering my own question - it does work.

Just FYI (and a puzzle) - this works with when busybox mount is used. When mount-FULL is used, it will bring down the system

I wonder what's the difference?

Posted: **Fri 04 Feb 2011, 02:32**

jamesbond wrote:2. As in my earlier comment, if you don't mind adding "non-persistent" loading of SFS beyond the original 6 SFS limit.

Testing this - this is currently works partially:
a) Adding SFS beyond the maximum 6 works. The script will create the necessary mountpoint in /initrd (e.g. /initrd/pup_ro10). But it uses the wrong loop device - instead of using loop10, it uses loop2 instead.
b) It still adds into SFSLIST (obviously because this is how it's designed for right now).
c) Removing it (within the same session as adding it) seems to work (success message), but actually fails - the SFS is still mounted. But because it's no longer in SFSLIST, sfs_load doesn't see it anymore.

Well, I know this is probably outside your original scope of design when you started, so if you don't want to hear this, just tell me to shut up and I'll do

cheers!

Posted: **Fri 04 Feb 2011, 04:12**

jamesbond wrote:Just FYI (and a puzzle) - this works with when busybox mount is used. When mount-FULL is used, it will bring down the system I wonder what's the difference?

Interesting - even calling mount.aufs directly still kills

this busybox mount must have a power we all don't know

EDIT: mount.aufs is just a wrapper which will call the full mount - and thus it kills. busybox mount make the mount syscall directly.

Posted: **Fri 04 Feb 2011, 05:26**

jamesbond wrote:
jamesbond wrote:2. As in my earlier comment, if you don't mind adding "non-persistent" loading of SFS beyond the original 6 SFS limit.
Testing this - this is currently works partially:

Why not just create a simple merge utility?

EDIT:

http://murga-linux.com/puppy/viewtopic. ... 619#492619

Posted: **Fri 04 Feb 2011, 10:07**

jpeps wrote:
jamesbond wrote:
jamesbond wrote:2. As in my earlier comment, if you don't mind adding "non-persistent" loading of SFS beyond the original 6 SFS limit.
Testing this - this is currently works partially:
Why not just create a simple merge utility?

EDIT:

http://murga-linux.com/puppy/viewtopic. ... 619#492619

Because this is what OTF SFS loader is for ?

Posted: **Fri 04 Feb 2011, 12:31**

Thanks to all testers.
But please test again with the new version, sfs_load-0.4.
Mainly improved loading SFS from CD with RAM mode.
It offers COPYtoHDD/RAM/NOCOPY options for the live CD without pupsave.
You can see how it works with the multilingual Wary-500m07.

Doesn't check the number of extra SFS. I am not sure what happens when it exceeds 6...

(old)Puppy Linux Discussion Forum

sfs_load-2.4 on-the-fly

quick hack against sfs_load-0.3

Extra sfs order

sfs_load-0.4