(old)Puppy Linux Discussion Forum

Posted: **Wed 09 Feb 2011, 08:32**

seaside wrote:I thought this might be another aspect to throw in for consideration.
http://murga-linux.com/puppy/viewtopic. ... 294#493294

Thanks seaside.
I add a launcher after loading sfs, inspired from you.

sfs_load-0.6
9 Feb 2011 v0.6: fix was moved remote files, restart X info, launcher (thanks to seaside)

Posted: **Wed 09 Feb 2011, 10:43**

Shinobar, how I am not derailing your thread too much.

Did there exist something named TCX to Sfs convert? or Sfs to Tcz convert?

I am trying to learn TCL now and did remember something about being able to use Tcz files converting them to sfs files and loading them when Puppy starts?

They had the Virtual Digital Piano something as an Tcz file and maybe that one can be made into an sfs and used in puppy?

Posted: **Wed 09 Feb 2011, 13:23**

Yes Nooby - you are derailing the thread. Why cannot you ask your own questions on a new thread rather than going off topic? You've done it on the sfs.exe thread as well.

To answer this one I think you might consider sfs tcz linker here:
http://murga-linux.com/puppy/viewtopic.php?t=47976

Of course all these guys (shinobar, goingnuts, seaside) creating new 'on the fly' loaders might also consider whether they can be extended to load tcz files.

Posted: **Wed 09 Feb 2011, 16:21**

Thanks ICPUG, you are right. Thanks for the link to sfs/Txz thing. I did refer to that one but did not remember enough to really get it.

Posted: **Thu 10 Feb 2011, 07:35**

0.6 fails on Puppeee because AUFS is built into the kernel rather than built as a module. Sfs_load assumes that means we're using Unionfs.

Posted: **Thu 10 Feb 2011, 12:25**

jemimah wrote:0.6 fails on Puppeee because AUFS is built into the kernel rather than built as a module. Sfs_load assumes that means we're using Unionfs.

I see. i guess i can manage...

For the test on pupeee, rewrite line 775 in /usr/sbin/sfs_load:

Code: Select all

AUFS=$(lsmod | grep -w '^aufs')

to:

Code: Select all

AUFS=aufs

Posted: **Thu 10 Feb 2011, 23:16**

Yeah I figured that out no problem - you really don't even need to worry about it - I just thought I'd mention it.

Posted: **Fri 11 Feb 2011, 01:59**

Just finished testing 0.6 and it's working very well. I think it would be good to tell the user that they have reached the system SFS limit when you run out of loop devices, instead of just saying that mounting the SFS failed.

Posted: **Fri 11 Feb 2011, 14:03**

jemimah wrote:I think it would be good to tell the user that they have reached the system SFS limit when you run out of loop devices

UPDATE: sfs_load-0.7
11 Feb 2011 v0.7: fix was not update menu in some case, see aufs even with no module(thanks to jemimah), add new loop device

Posted: **Sat 12 Feb 2011, 05:35**

I was able to create one extra loop device, but when I tried to create the second one I get the error "failed to create new loop-back device". I can look in /dev and see that the new device was in fact created successfully.

Posted: **Sat 12 Feb 2011, 06:03**

jemimah wrote:I was able to create one extra loop device, but when I tried to create the second one I get the error "failed to create new loop-back device". I can look in /dev and see that the new device was in fact created successfully.

sfs_load is checking if it is available by the following command:

Code: Select all

losetup -f

I am not sure how many loop-back devices are allowed on the system and how to change the limit...

Posted: **Sat 12 Feb 2011, 07:07**

The actual limit is hard coded in the init script. I bumped the limit in Puppeee up to 11 for testing.

I think it should work fine to just create the loop device and mount point. If there are more SFSes in the list than the limit in the init script, it will just ignore the extra ones.

I'm not sure what maximum number of branches you can have in AUFS is. I guess lighthousepup supports 40 SFSes or something so the limit must be pretty high.

"losetup -f" returns nothing on my system after I run out of loop devices. I'm not sure what's going wrong exactly.

Posted: **Sat 12 Feb 2011, 16:05**

Experimenting with this a bit, I've found that SFS's are not just a simple substitute for PETS. Sometimes they don't work. For example, I tried making an SFS for TOR network-browser. The PET loads the network, while the SFS only partially loads it. Making a PET for directory of gmail phone plugins worked fine, but the SFS of the same directory didn't (they weren't seen in gmail). There may be a good reason to limit the number of AUFS loops. Perhaps there's something I'm not doing to make them work better.

Posted: **Sat 12 Feb 2011, 18:17**

Think I see what's going on. The PET overrides the whiteouts and loads all the files, while the SFS doesn't.

Edit: There was something like "initrd/pup_rw/opt/.wh..wh..opq" that prevented plugins in /opt from loading with the SFS, although the PET loaded. Worked after deleting. (there were also a few more that need deleting).

Posted: **Sat 12 Feb 2011, 20:01**

The solution I've come up with is a script that gets rid of whiteouts. I'll have to see if there's any problems with it, but it's enabling my SFS to load and haven't run into any problems.

USAGE: whiteouts [ -d ] ## just view them, or delete with option "-d". Whiteouts to leave alone are listed in script.

Code: Select all

 #!/bin/ash -a

display() {
[ -f /tmp/whiteouts ] &&  rm /tmp/whiteouts
 touch /tmp/whiteouts
 find /initrd/pup_rw | grep "\.wh" >>/tmp/whiteouts
}

if [ "$1" == "-d" ]; then
  [ -f /tmp/white-del ] && rm /tmp/white-del 
   touch /tmp/white-del
display
cat /tmp/whiteouts | sed ' 
/\.wh..wh.orph/ d 
/\.wh..wh.plnk/ d 
/\.wh.windowmanager.openbox/ d
/\.wh..wh.aufs/ d ' >>/tmp/white-del
  ## remove files
 while read line; do
   rm $line
 done < /tmp/white-del
  rm /tmp/white-del
 exit
fi

display
cat /tmp/whiteouts
rm /tmp/whiteouts

Posted: **Sat 12 Feb 2011, 23:06**

There is code in the init script that does the whiteout cleaning. Unfortunately it doesn't work with newer aufs versions because the name of the opaque whiteout files changed and the script has not been updated (Barry has fixed it in woof now). I think it should be safe to move the code to sfs-load and remove it from the init script. I intend to try it anyway.

Posted: **Mon 14 Feb 2011, 12:26**

Major update:
# 14 Feb 2011 v0.8:

warning excessive extra files
restart main dialog(thanks to Bert)
cleanup whiteout at unload(thanks to jpeps and jemimah)
mkfontscale, mkfontdir

Treating the whiteout may reduce the problem as jpeps reported, but note that sfs can not be the same as pet.
Suppose:

Load a sfs
Delete some of the files or directories in the sfs
Unload the sfs by the sfs_load-0.8, which cleans up the whiteouts
Load again the same sfs

Most of case, the once deleted files or directories revive with the last re-load.
But the files or the directories conflict (duplicated) with other layers shall not come back.

Posted: **Mon 14 Feb 2011, 16:47**

shinobar wrote: Treating the whiteout may reduce the problem as jpeps reported, but note that sfs can not be the same as pet.

As I recall, whiteouts were successfully removed with a pet install, but not with SFS.

Posted: **Mon 14 Feb 2011, 18:11**

Installing a pet writes to the top layer whereas installing an sfs puts the data on the bottom layer. That's why there's a difference,

Posted: **Mon 14 Feb 2011, 18:46**

New usage for sfs load on the fly. When using woof and ./3builddistro. When it is time to create devx.sfs, so far the Barry`s bacon basic compiler installing hasnt been succesful. Devx.sfs not loaded has been the error message (it has been always loaded with bootmanager)

Now I have twice used sfs load on the fly for devx.sfs. Both times bacon basic compiler and support files have been succesfully added to the devx.sfs

(old)Puppy Linux Discussion Forum

sfs_load-2.4 on-the-fly

sfs_load-0.6

aufs or unionfs

sfs_load-0.7

extra loop device

sfs_load-0.8

Re: sfs_load-0.8