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)_________________Woof Mailing List | keep the faith |

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._________________Downloads for Puppy Linux http://shino.pos.to/linux/downloads.htmlLast edited by shinobar on Wed 23 Feb 2011, 20:59; edited 1 time in total

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).

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.

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:

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

Cheers

Quote:

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.

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?_________________Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread.Last edited by jamesbond on Fri 04 Feb 2011, 00:11; edited 2 times in total

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