using SFS with full installs

[mikeb]

Patched and in a zip...well I did it on Windows
Will redo later...

note for users... fakechroot -- chroot {executable}

edit...now a tar.gz.... I have complied....

mike

[jamesbond]

well I did it on Windows

Heresy !!! That being said 7zip will create tgz archive on Windows too

[mikeb]

That being said 7zip will create tgz archive on Windows too

You would think so but it only offered tar with no compression options...so zip it was.

mike

[jamesbond]

You would think so but it only offered tar with no compression options...so zip it was.

It does, but it's a two step process (tar first, then gz/bz2/xz). (You know, I have to boot into my Windows VM to confirm this ) Agree that zip is more convenient.

Anyway, back on topic, if you're running full installs (which apparently missed my attention in my first reply) - the if you run root you can easily mount "/" as a branch of aufs. Of course, unionfs-fuse is probably better in this regard because it doesn't require patched kernels, so no contest if you're running other distros, and you get all the benefit.

Amigo thanks for bringing bindfs to my attention.

[mikeb]

hmm could not be asked... zip appears to be the same compression as gzip but with an index too so i prefer it for large archives/backups as I can rescue a single file quickly and update the archive without a full rebuild.

the if you run root you can easily mount "/" as a branch of aufs.

so you have created a union using '/' as a layer using aufs? that was a query earlier. Lucid refused to do this. If so why is this not the method used in puppy for running an sfs?

mike

[jamesbond]

so you have created a union using '/' as a layer using aufs? that was a query earlier.

Yes. As long as "/" is not aufs (which shouldn't be the case on full install, "/" should be /dev/sdxxx)

Lucid refused to do this. If so why is this not the method used in puppy for running an sfs?

No idea

[mikeb]

well I can have more than 10 sfs and load them on the fly on a standard puppy 2.16...2.6.18 kernel so I guess it takes a few years for these things to get through

mike

[saintless]

Thank you, Mike!
I just like to let you know your Idea inspired Fred to make nice improvements (for full and frugal install) in few applications:
http://www.murga-linux.com/puppy/viewto ... 075#820075
http://www.murga-linux.com/puppy/viewto ... 615#826615
Not Puppy but atleast related project. Maybe in Puppy some day...

Toni

[mikeb]

Ah great... I like to throw ideas around and its even better when they get picked up.

Glad to see debiandog has been thriving

Again amigo needs credit on this one.

Yes. As long as "/" is not aufs (which ... dev/sdxxx)
old thread and the penny just dropped.... sort of... sfs layered with system partition... but result would not be part of the main system but separate and still need to chroot into it. Seem to have gone circular.

Hmm could get busy in here...you never know

mike

[fredx181]

Hi Mike,

I'd like to thank you also!
Your idea is very useful for some scripts I made in different ways.
For loading a SFS I basically used this (slightly changed your code, so config files will be written to the 'normal' directory e.g. /root/.config):

Code: Select all

mkdir -p union
mkdir -p app
#mkdir -p write

mount -o loop xchat.sfs app
unionfs-fuse -o nonempty -o allow_root -o cow /=RW:/root/app=RO /root/union

chroot union xchat
umount -l /root/union
rmdir /root/union 

Here's attached loadsfs-fuse, we use it to load SFS in DebianDog full install.
(Depends besides unionfs-fuse also on yad. An "Applications" window will show)
Usage:

Code: Select all

loadsfs-fuse /path/to/<name>.sfs

Or just drag and drop a .sfs on to the loadsfs-fuse script in filemanager.
Tested only on DebianDog.

Edit: Now I tested on puppy precise and found that it doesn't work because of to old yad version.
Re-uploaded, with only change: removed unimportant yad switch so works now also with old yad version e.g. v. 0.12.

Fred

[mikeb]

Excellent .... I had a gut feeling this would be useful.

Thanks for sharing.... it may get popular

mike

[rufwoof]

Another option is to use sym links.

Create a mount point
Mount the sfs
copy the contents to /

Code: Select all

mkdir /mnt/gimp
mount -t squashfs /somewhere/gimp.sfs /mnt/gimp
cd /
cp -rsv /mnt/gimp/* . > /tmp/whatdone
fixmenus

Copies pretty quickly for me (second or two to 'load' the sfs, and every sfs I've thrown at that has worked ok (as expected).

The recursive copy as symlinks with verbose (-rsv) switches provides a reference of what was sym linked (in file /tmp/whatdone). With a bit of awk/sed or whatever that reference file could be used to undo/remove those links (unmount the sfs) i.e. remove symlinks and then unmount /mnt/gimp

Perhaps load and unload code something like (untested)

Code: Select all

#!/bin/bash
SFS=$1
DIR=$(dirname "$SFS")
[ "$DIR" = "." ] && DIR=$PWD
FILE=$(basename "$SFS")
mkdir /mnt/$FILE
mount -t squashfs $SFS /mnt/$FILE
cp -rsv /mnt/$FILE/* /. >/tmp/${FILE}_rec
fixmenus

Code: Select all

#!/bin/bash
SFS=$1
DIR=$(dirname "$SFS")
[ "$DIR" = "." ] && DIR=$PWD
FILE=$(basename "$SFS")
# remove links created by sfs load - catering for files with spaces in filename
cat /tmp/${FILE}_rec | awk 'BEGIN { FS = "-> `/." } ; { print "rm \"" $2 }' | sed 's/.$/\"/' >/tmp/${FILE}_del
IFS="
"
for line in `cat /tmp/${FILE}_del`;do
  LEN=`expr length "$line"`
  if [ $LEN -gt 4 ]; then
    exec $line
  fi
done
umount /mnt/$FILE
rm /tmp/${FILE}_rec
rm /tmp/${FILE}_del
rmdir /mnt/$FILE
fixmenus

[mikeb]

Well sort of defeats the objects of using an sfs...ie to leave no footprint behind once removed..plus the possibility of removing wanted items if you do clean up.

mike