Puppy Linux Discussion Forum

As I mentioned on the old forum, this project is based on the standbox tools available in puppy and fatdog64 which are:

rootfs-skeleton/usr/bin/sandbox.sh
rootfs-skeleton/usr/bin/sandbox-rw.sh

a traditional use for these tools was to build packages for puppy and puppy-like systems:
http://distro.ibiblio.org/fatdog/web/fa ... ckage.html

However, they can be used to run an entire puppy in a chroot environment. It is the latter aim which this project is focused on and as a consequence, it is possible that I could break some of the packaging building testing stuff along the way, which if I happen to break I can fix at a later date. The traditional way to run a puppy this way is to simulate the full install mode and having the top layer as an RW layer.

However, previously I've provided code to help simulate other pup modes but further testing is required. The pupmode can be specified with the flag --pupmode option and one thing that it does is affects how the initrd directory is made. See code:

psandbox.sh#L152

More recently, I've added the following options:

-r|--copy-resolv_conf) #Copies resolv.conf into the chroot:
-u|--bind-X11-sockets) #binds the x11 sockets into the proot
-a|--copy-Xauth) #Copies the Xauth file into the chroot

The following option was modified:

-e|--extra-sfs) add an sfs layer to the chroot via a single sfs file name or a file that lists multipole sfs files. 

and I restructured the code so all options are immediately processed rather than delaying the mounts until all arguments are processed. This simplifies the code. The updated code can be found at:

but I haven't copied it yet into the gitlab project since I have to remember how to do that.

I added a new option which allows you to specify directories to bind into the chroot. Recursive binds aren't yet supported. There are two ways that one can do this. They can either use --bind as the last option followed by source and target. Or alternatively they can use the form:

--bind sorce -j target

or at least that is the idea.

The point of the -j is to keep the getopt function from moving the target in the argument list to after the optional arguments. An alternative to this might be to process the arguments without using getop.

I've only tested this new --bind option as the last option in the command and in such cases the -j isn't required.

Here is the new version of psandbox.sh (again not yet uploaded to getlab)

Here is an example of how to run the code:

With this code I was able to run fossapup64 in a chroot sandbox, install, recoll and start indexing all within the sandbox. The host operating system was Fatdog64. The reason, that I'm doing this was that I wasn't able to compile recoll on fatdog64 without removing some of the compile options (see post).

this script may (or may not) be of interest to you.. xchroot (allows X stuff in the chroot)

...bear in mind I know nothing about chroot..

sc0ttman wrote: ↑Tue Nov 17, 2020 11:49 am

this script may (or may not) be of interest to you.. xchroot (allows X stuff in the chroot)

...bear in mind I know nothing about chroot..

I suppose, I should eventually look at this. Probably when my scripts are more polished. The XCHROOT project might have some features that I want to add such as the socat option.

I started a number of related threads on this. I'll post them here:
cpio symlink trick (tar workaround) & sandbox applications
sandbox-rw.sh modificaitons in progress

and also mentioned it in some other topics:
how the sandbox.sh script works
Re: inconsistent SFS creation results

Re: Can you load a different pupsave after booting?
Chroot sandbox w/ Hardlinked Savefile Snapshot made Via Rsync

I've been making major changes to this script and they and I would like to polish these changes more before updating the gitlab code. As a consequence I decided to push this updated code to github instead. I've been working a bit with pastebin because the chanes weren't polished enough for me. Some related pastes:

Part of the reason for not pushing the code to github / gitlab sooner is I tend to forget how to do it if I don't do it often. As a consequence, here are some notes, on how I did it. Take these notes as the wrong way to do it.
1. Download the tar.gz file from gitlab. Yes, I know I should have pulled the code.|
2. Make changes to said code.
3. Create a new project on github.
Then the steps are roughly as follows:

Norw 1
git symbolic-ref HEAD refs/heads/master
#Note 2
git remote set-url origin https://github.com/s243a/psandbox.sh.git
git add .
#Note 3, I'm sure about the git commit -am vs git commit -m
git commit -am "Major Changes from https://gitlab.com/s243a/psandbox"
git branch -M main
git push -u origin main

Notes:
1. I'm using "git symbolic-ref HEAD" because "git branch -M main" didn't work. See: https://confluence.atlassian.com/fishkb ... 72024.html
2. I'm using git remote set-url because origin is already defined so "git remote add origin". See: https://stackoverflow.com/questions/243 ... repository
3. git push origin master fails and gives error: src refspec HEAD does not match any

They way I did this I seemed to have lost my change history, which isn't such a big deal because there are major changes.

I've updated the documentation of psandbox2.sh

# f, --input-file
#    read layer paths from a file rather than reading existing layers
# -o, --output-file 
#    Just write layer paths to an output file but don't mount the sandbox. 
# --no-exit
#    if an output file is specified (i.e. -o or --output-file) layer paths are just written to a file and the program exits unless the no-exit flag is specified.
# -p|--env-prefix
#    TODO: Not yet defined. See if there is any old code related to this. 
#    enviornental variable prefix
# -m,--pmedia
#    Used to emulate the pmedia boot parmater. This helps to determine the pup mode. 
# d, --pdrv
#    this is the particiaion where the puppy files are located. The default is /mnt/home
# s, psubdir
#    this is the sub directory where the puppy files are located
#  --maybe-psubdir
#    get the layers from a given sub directory if no layers were found via the previous options.  
#  --distro-specs
#    path to distro specs (e.g. /etc/DISTRO_SPECS; e.g. /initrd/distro-specs)
#    this file is sourced to provide information about the pup layers. 
# c, --clear-env (Not yet implemented, but option processed)
#    deletes enviornental variabls
# b --boot-config (Not Yet Implemented, but option processed)
#    path to boot config (e.g. /etc/rc.d/BOOTCONFIG). This file provides information about extra sfs layers to add. If this option apears after psubdir then the layring will be like a standard puppy. 
#   --union-record (Not yet implemented, but option processed)
#   Specifies the main pup layers but file name only rather than the full path to the sfs. This is usually defined in boot-config. 
#  --aufs
#   With this option the currently mounted layers are used as part of the sandbox. 
#  --maybe-aufs
#   Same as aufs, but is only used if the layers aren't already selected by a previous option. 
# -t|--tmpfs
#   Use ram as the top layer. If no path is specified then tmpfs will be mounted. 
#  -r|--root
#   Specifies the parrent directory of the chroot folder. This parent directory is called SANDBOX_ROOT. By default this is /mnt/sb. See the option --fake-root, for the actual chroot folder. 
#  -f|-n|--fake-root|--new-root
#   Specifies the chroot folder. /mnt/sb/fakeroot. If this is occupied by a previous sandbox then the default is /mnt/sb/fakeroot.sandboxID Relative paths are assumed to be a subdirectory of SANDBOX_ROOT (see the --root option above). Currently, all these options do the same thing but thought behind the --new-root option is that we might try moving a mount point. The effect of this is to hide what is underneath the old mount point. This is simmilar to a chroot but would impact the whole system! 
#    This is a risky/experimental option. The idea
#  --pupmode
#   This option is used to emulate a pupmode. The default pupmode is "2" which emulates a full install. 
# --layer
#   Specify a layer of the layered file system. Layers are added as per the order that they apear as arguments. 
#   a subgke kater
# -l|--logfile
#   Standard error and standard output will copied to this file while the logger is on. 
# -t|--trace
#   Uses the set -x option in the areas of code where the logger is on. 
# -a|--copy-Xauth
#   Copy the Xauthority into the chroot. 
#  -u|--bind-X11-sockets
#   Bind the X11 sockets into the chroot. The default folder to bind is /tmp/.X11-unix
#  -r|--copy-resolv_conf
#   Copy /etc/resolve.conf into the chroot.
#  e, --extra-sfs
#   a list of extra sfs files (space seperated)
#  u, --union-record
# --xterm
# --sandbox
# -initrd
# --rev-bind 
#  Bind one or more folders from the sandbox into the main system
#  --before-chroot
#  Enter an arbitrary command immediatly before entering the chroot folder (e.g. start a samba server)
#  --bind
#  Bind arbitrary directories from the host system into the chroot. For safety reasons binds are not recursive but the option for recursive binds may be implemented at a later date. 
# 

https://github.com/s243a/psandbox.sh/bl ... andbox2.sh

Not all options shown are implemented or sufficiently tested. Since I have been making major changes I might have broke some things. psandbox2.sh originated by taking my old psandbox2.sh and merging code into it from other code I was working on, which I called "remount_save.sh" for lack of a better name I named remount_save.sh

remount_save.sh was based on the latest version of rw-sandbox.sh (from fatdog 811) with selected code from the original psandbox.sh merged into it. I orginally discussed these modifications in the thread, "sandbox-rw.sh modificaitons in progress". The name arose from the idea that, I might be able to remount a save file after boot (see post). I haven't implmented/tested this idea yet though.

@s243a :-

Just wanted to mention one thing, here. Although this IS an excellent idea, need to bear one thing in mind.....because it's essentially running one Puppy inside another, it's not really accessible any longer to anybody with really old hardware (who may well struggle to run ONE Pup properly....never mind TWO!)

That said, as I've proved myself - which you're aware of - it's certainly a good way to run more up-to-date applications (like browsers) within an older, much-loved Puppy. And can give it a new 'lease of life'!

Of course, I've seen enough of the community reporting moves to newer, more capable hardware over the last few years to realise that there really can't be that many 'dinosaur'-type machines left any longer...

Keep up the good work, mate. I'll be keeping an eye on your progress, out of interest.

Mike.

mikewalsh wrote: ↑Mon Jan 04, 2021 5:06 pm

@s243a :-

Just wanted to mention one thing, here. Although this IS an excellent idea, need to bear one thing in mind.....because it's essentially running one Puppy inside another, it's not really accessible any longer to anybody with really old hardware (who may well struggle to run ONE Pup properly....never mind TWO!)

You mentioned that your iron chroot works on puppy 4, so that that gives me a reference about how knew a puppy to run on older machines either as a standalone puppy or inside a chroot.

The chrooted puppy may not have a lot of processes running (e.g. now desktop running) and it can be constructed so that none of the layers are in Ram.

As a reference I have a machine that only has 1gb if Ram with dpup stretch as the host OS. It is a frugal puppy with the save folder located on the hard drive. I did not use the nocopy boot option. For this puppy, I had no issue running the warry version of Puppy Arcade within the chrooted sandbox.

For this setup I was able to use the chroot folder also as the ssh chroot folder and was able to share a samba folder between the guest and host. Granted, I did not try running any roms within the sandboxed puppy arcade...or even know how to do that yet.

Alternatively, one can run an older puppy in the chroot sandbox. This way one can try out older puppies without having to wory about stuff like if the browser is up to date.

That said, as I've proved myself - which you're aware of - it's certainly a good way to run more up-to-date applications (like browsers) within an older, much-loved Puppy. And can give it a new 'lease of life'!

Agreed. The chrooted Iron browser is very useful, especially for both older and newer versions of puppy. I was thinking of trying to break it up into layers that are either essential for iron or extra.

Of course, I've seen enough of the community reporting moves to newer, more capable hardware over the last few years to realise that there really can't be that many 'dinosaur'-type machines left any longer...

My machines are aging but granted they aren't as old as the machines that some people have on this forum. Aside from the chroot providing a way to try older puppies on knewer machines, newer machines could run many more versions of puppy at the same time.

For instance say, I wanted to simulate a p2p network such as freenet on a single machine; then I might be able to run more instances of an older puppy at once than I could with a newer version of puppy. Puppy is small enough that one could even run several versions at once in ram and the amount of ram needed to do this could be minimized by hardlinking files that are shared by each instance of puppy.

Keep up the good work, mate. I'll be keeping an eye on your progress, out of interest.

Mike.

Thankyou, I'll let you know when it is more pollished.

mikewalsh wrote: ↑Mon Jan 04, 2021 5:06 pm

That said, as I've proved myself - which you're aware of - it's certainly a good way to run more up-to-date applications (like browsers) within an older, much-loved Puppy. And can give it a new 'lease of life'!

I took a stab at at trying to get your iron chroot working with my psandbox scripts. One difference between a typical setup and your iron chroot is that I typically expect the sfs files to have the root at "/" but in your case the root is at "cont". I do want to add the ability to mount folders within archives such as sfs files but tonight I took a different approach. In the save file I created symlinks for the folders within "/cont" amd put these symlinks in "/". Seems like this could be also an opportunity to experiment with other symlinking techniques such as those suggested by wanderer. Anyway, I symlinked the folders as follows :

ls -1 ./cont | xargs -n 1 sh -c 'ln -s cont/$1 $2' {}

**This command was ran in the sandbox root and I spent much more time trying to do it with xargs then it would have taken me to manually do it.

After making these changes, Iron did start when entering the chroot. I was able to navigate in the browser to google. However, when I closed the browser the terminal was still busy.

If you want to see this, then extract the following archive to any folder:
chroot_sandbox_0.001
**You can extract this file via uextract

Once the file is extracted then run the script "run_psandbox2.sh"

My recent code changes are shown in the following link:
https://github.com/s243a/psandbox.sh/co ... aaeb9f1405

The code changes, made some fixes for setting the root directors, some fixes for safe unmounting and deleting and a more reliable command to enter the chroot.

          (
            echo "chroot $FAKEROOT"
             chroot "$FAKEROOT" < /dev/tty > /dev/tty 2>/dev/tty
            )

However, the system probably doesn't unmount properly yet. Not sure. Too, late to test this time of night. No warranties. I'll let you know when it is more polished.

In previous post I created an example where I packaged psandbox with @mikewalsh's Chrooted Iron 84 'portable'. In this example a save file supplied the symlinks from "/" to the directories in /cont. psandbox mounted @mikewalsh's chrooted-iron at "/" within the sandbox. The symlinks were required because the actual chroot folder for iron-chroot was within "/cont" rather than "/". @mikewalsh's built the chrooted iron this way so it was easy to build a chroot script to run iron whithin a running puppy.

There were numerous alternative approaches that I could of taken which I've itemized in the following thread:

"Dev implications: AUFS: symlinks overwrite folders and vice versa"

What I want is a single sfs file that let's me experiment with these numerous alternative approaches. This might help to illustrate some of the flexibility of the psandbox script. Towards this end, I've done the following:
1. Extract "chrooted-iron to "chroote-iron-extracted"
2. Within the extracted folder, hardlink the files in "/cont" to "/" (see related post)

#In the parent directory of chrooted-iron run:
rsync -rltDv --link-dest=$PWD/571-ironchroot-expanded/cont/ $PWD/571-ironchroot-expanded/cont/ $PWD/571-ironchroot-expanded/

3. After making the above change create a new sfs file:

mksquashfs ironchroot-extracted iron84_chroot_i386-hardlinked.sfs

The result file size is 518 Mb. The original file size was 436MB. What this shows is that hardlinks do result in much more space savings within the sfs file than one might expect if the files were just duplicated. What I haven't tested is if the sfs compression is smart enough to detect duplicate files and save space accordingly.

So now with our slightly larger sfs file we can experiment both with sylink approaches like @wanderer is advocating for and also traditional puppy type layering, all within a chrooted sandbox.

@s243a :-

Just so's we're absolutely clear on this, I want to make it plain that I'm not the one originally responsible for coming up with the concept of running a modern browser within a chrooted Puppy. Credit for this absolutely must go to the one responsible for originating the idea with a then current version of Pale Moon at the time darry20181966 was playing around with his updated Puppy 4.3.1 "Phoenix".....the redoubtable, and highly-resourceful watchdog (who has proven himself to never be afraid to experiment & try things out).

I don't mind Pale Moon, but the chrooted version of the browser was, for me at least, distinctly "sluggish" compared with the same browser running on "bare metal", as it were. I wanted to try something more in line with what I run myself on a daily basis. I've been a Chrome user from day one, first signing-up to the beta test programme & trying out the 'beta' test versions before the release of Chrome v001 back in October 2008. I've long been an advocate of Iron as the most 'Chrome-like' of the various clones, and one which is closest in appearance and operation to Chrome itself; I still run various 32-bit Pups, even on this brand-new hardware, and Linux Chrome hasn't been available in 32-bit format for almost 5 years now.

-------------------------------------------------------------

I basically took watchdog's concept and 'ran with it'. I did some experimenting, and settled on the oldest - and hence smallest - Puppy that would run the then current version of Iron (v69) without complaints. Which proved to be Tahrpup. Amazingly, the 'chrooted' Iron, despite being such a big, 'heavy' browser (as are ALL the 'clones, if I'm honest), proved to be unbelievably snappy within the chroot environment.....far more so than within a standard Tahr install. Both Darren and I were gobsmacked by just how fast & responsive it turned out to be.

Originally I 'installed' Iron within the standard locations as if it was installed via .pet or SFS. More recent versions use the 'portable' Iron browser that I produce for Puppy, mostly because it was already there, and hence easier to implement.

I've long run the chrooted Tahrpup from a common, remote location, so I can share the chrooted browser(s) - I also run Vivaldi-portable and a version of FF 78 esr the same way - between multiple older Puppies. Recently I've re-built the 'jail', as I call it, with 32-bit Xenialpup instead of Tahr, since newer versions of the browsers are beginning to moan about some of Tahr's dependencies.

"/Cont" is, I presume, simply short for "container".....the directory within which the chrooted Puppy + browsers run. I also concur with your supposition that the chrooted Puppy is like as not running with relatively few pocesses on the boil, thus has very little to actually slow it down when compared to a 'normal' install of Puppy; my own, in particular, get used as 'test-beds' for all sorts of stuff, thus get loaded down with a lot of software over a period of time.....all of which generate background processes that help to consume valuable CPU cycles/resources. For myself, on this new, highly-capable HP Pavilion tower, this is of little or no consequence (I'm fast becoming a very 'atypical' Puppy user), but for others, running much older & resource-limited hardware, 'every little counts'.

Mike.

mikewalsh wrote: ↑Wed Jan 13, 2021 2:02 am

@s243a :-

Just so's we're absolutely clear on this, I want to make it plain that I'm not the one originally responsible for coming up with the concept of running a modern browser within a chrooted Puppy. Credit for this absolutely must go to the one responsible for originating the idea with a then current version of Pale Moon at the time

It's good to give credit where credit is due. Therefore, while you may not have come up with the concept you put it together for us, so you deserve some credit

darry20181966 was playing around with his updated Puppy 4.3.1 "Phoenix".....the redoubtable, and highly-resourceful watchdog (who has proven himself to never be afraid to experiment & try things out).

Then let me also thank @watchdog for this work

I don't mind Pale Moon, but the chrooted version of the browser was, for me at least, distinctly "sluggish" compared with the same browser running on "bare metal", as it were. I wanted to try something more in line with what I run myself on a daily basis. I've been a Chrome user from day one, first signing-up to the beta test programme & trying out the 'beta' test versions before the release of Chrome v001 back in October 2008. I've long been an advocate of Iron as the most 'Chrome-like' of the various clones, and one which is closest in appearance and operation to Chrome itself; I still run various 32-bit Pups, even on this brand-new hardware, and Linux Chrome hasn't been available in 32-bit format for almost 5 years now.

-------------------------------------------------------------

I basically took watchdog's concept and 'ran with it'.

Thankyou for this history . I find that for some sites/applications unfortunately only chrome based browser are suitable. For instance there was a period that I recall that firefox-ESR wasn't working properly with gitlab.

I did some experimenting, and settled on the oldest - and hence smallest - Puppy that would run the then current version of Iron (v69) without complaints. Which proved to be Tahrpup. Amazingly, the 'chrooted' Iron, despite being such a big, 'heavy' browser (as are ALL the 'clones, if I'm honest), proved to be unbelievably snappy within the chroot environment.....far more so than within a standard Tahr install. Both Darren and I were gobsmacked by just how fast & responsive it turned out to be.

I like tahrpup a lot and would also like to try the concept with tahrpup. Perhaps at some point you can provide some build instructions, including mentioning of any components that you might strip out.

Perhaps the following is part of these instructions:

Originally I 'installed' Iron within the standard locations as if it was installed via .pet or SFS. More recent versions use the 'portable' Iron browser that I produce for Puppy, mostly because it was already there, and hence easier to implement.

I've long run the chrooted Tahrpup from a common, remote location, so I can share the chrooted browser(s) - I also run Vivaldi-portable and a version of FF 78 esr the same way - between multiple older Puppies. Recently I've re-built the 'jail', as I call it, with 32-bit Xenialpup instead of Tahr, since newer versions of the browsers are beginning to moan about some of Tahr's dependencies.

BTW have you tried using your chroot folder with ssh. The way, you have it, "/cont" is your chroot folder. In your sshd_conf file you can specify a chroot folder. Shen the ssh server starts the client will receive a shell for the chroot folder rather than your main system.

"/Cont" is, I presume, simply short for "container".....the directory within which the chrooted Puppy + browsers run.

That was my assumption.

I also concur with your supposition that the chrooted Puppy is like as not running with relatively few pocesses on the boil, thus has very little to actually slow it down when compared to a 'normal' install of Puppy; my own, in particular, get used as 'test-beds' for all sorts of stuff, thus get loaded down with a lot of software over a period of time.....all of which generate background processes that help to consume valuable CPU cycles/resources. For myself, on this new, highly-capable HP Pavilion tower, this is of little or no consequence (I'm fast becoming a very 'atypical' Puppy user), but for others, running much older & resource-limited hardware, 'every little counts'.

Mike.

agreed.

I'm still testing so I'll hold off releasing my modified psandbox.sh example using the hardlinked techniques mentioned in my previous post. I will make some observations though:

1. When I started the rox file exploerer with "rox -n" the icons were initially broken. I fixed this issue with the following command:

gdk-pixbuf-query-loaders --update-cache

which I got rom the puppy rc.update script.
2. While Iron did start, it produced some things I likely should adress. Here is some of the shell output:

root# iron
Fontconfig warning: "/etc/fonts/fonts.conf", line 86: unknown element "blank"
[2546:2673:0113/130257.171650:ERROR:bus.cc(393)] Failed to connect to the bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
Received signal 11 SEGV_MAPERR 000000000000
libGL error: image driver extension not found
libGL error: failed to load driver: nouveau
...
Most likely you need to configure your SUID sandbox correctly
[0113/133222.963074:ERROR:nacl_helper_linux.cc(308)] NaCl helper process running without a sandbox!
Most likely you need to configure your SUID sandbox correctly

There errors seem to kill chromium and as a consequence with chromium I had to set the "--use-angle" to get chromium to work (see post). For iron it seems I might not need to do this. Iron might eventually find working settings rather than the user having to manually set them. Needless to say, If I can help Iron out then it could speed up boot times.

The other issue is the dbus socket. I see two possibilities neither which are essential but might offer some advantage. I could either bind /var/run/dbus/system_bus_socket into the chroot or alternatively, I could start up dbus within the chroot. dbus is unfortunately something that I don't really understand.

Like in my previous post I created a cpio archive where psandbox is used to setup a sandbox for a chrooted iron browser. As mentioned above, this time rather then symlinking the contents of "/cont" to "/", within the chroot the sfs file now has the contents between these two folders hardlinked (see post).

Prior to creating the archive I ran a script to clean the iron profile data (see post). Prior to doing this the script worked but I haven't yet tested the file after this process.That said here is the download link:
iron-84-chroot_sandbox_0.002.cpio.gz
*I will test the download tonight.
**Use uextract to extract? then run the script, "run_psandbox2.sh"

Edit: I seem to be missing files. Something must have been wrong with my packaging script. I will try again later. End Edit

Edit #2-- I updated the link. I will explain the fixes in another post --End Edit#2

in my tests the chroot folder now successfully unmounts. This now fixed issue arose due to code changes that allow my fakeroot folder to be anywhere (see post). However, I haven't fully tested this feature yet. Prior to doing so I would like to demonstrate some previously developed features.

Anway the latest changes to my psandbox script can be found at:

https://github.com/s243a/psandbox.sh/co ... ce61f474bc

I'm thinking for these test archives that I build, I can provide multiple options to run the iron browser which include:
1. use a slighrly modified version of the chroot script provided by @mikewalsh to run iron in a chroot.
2. using the same sfs run iron as a "portable browser"
3. run using my psandbox tools

Optioms #1 and #2 are simpler but don't provide save funtionality except for the pssobiloty of a profile folder. Option #3 provides many more optioms such as adding extra layers.

@s243a :-

One way to speed-up start times for any of the Chromium 'clones' is to make use of the

--silent-launch

....'--switch' . ETP discovered, and made use of this in his original 'Chromebook' Pup v1 - Precise-based, and using vicmz's Openbox set-up - where he was attempting to make Puppy emulate the 'always ready-to-go' functionality of a Chromebook.

This basically starts the browser up as a background process, but without displaying the browser window(s). Since I don't know of anybody who actually wants to start up with the browser immediately up-and-running, this works quite well for most folks, since the instant you select the browser it displays straight-away.....because it is in fact already running.

I use a chroot script in /root/Startup of the 'host' Puppy to fire it up within the chroot as soon as Puppy gets underway. When I'm ready to start the browser, it's just 'there', instantly.

It looks like this:-

#!/bin/sh
export LC_ALL=C
mount --bind /dev /cont/dev
mount --bind /proc /cont/proc
mount --bind /sys /cont/sys
mount -t devpts devpts /cont/dev/pts
cp /etc/resolv.conf /cont/etc/resolv.conf
cp /var/lib/dbus/machine-id /cont/var/lib/dbus/machine-id 
xhost +
mkdir -p /cont/tmp/.X11-unix
mount --bind /tmp/.X11-unix /cont/tmp/.X11-unix
chroot /cont silent_launch
#
sleep 45
#
/usr/lib/gtkdialog/box_splash -placement top -bg yellow -fg black -timeout 10 -text "  IRON BROWSER HAS NOW LAUNCHED
AND IS RUNNING IN THE BACKGROUND......."

The 'sleep' command is simply there to give the browser time to fire-up & 'settle-down' before displaying the 'splash-box'.

------------------------------------------

This executes the actual 'silent-launch' script within /cont/usr/bin. The 'portable'-Iron browser sits in /cont/opt, and the 'silent-launch' script points here.....like so:-

#!/bin/sh
#
# Launch Iron in the background
#
/opt/Iron-portable/iron32/iron-pup --silent-launch &

DO note that the '--silent-launch' command must be applied to the 'iron-pup' wrapper-script, not the portable's 'LAUNCH' start-up script. Also, note the '&' at the end.....which effects any background process in Linux.

As for stuff to remove, I didn't remove very much, TBH. /usr/share/applications & /usr/share/pixmaps aren't needed, so I did away with them.....I guess you could remove /usr/games, too. Beyond that, I was concerned about removing vital components, so I left well alone at that point.....

Mike.

s243a wrote: ↑Thu Jan 14, 2021 2:40 pm

Like in my previous post I created a cpio archive where psandbox is used to setup a sandbox for a chrooted iron browser. As mentioned above, this time rather then symlinking the contents of "/cont" to "/", within the chroot the sfs file now has the contents between these two folders hardlinked (see post).

Prior to creating the archive I ran a script to clean the iron profile data (see post). Prior to doing this the script worked but I haven't yet tested the file after this process.That said here is the download link:
iron-84-chroot_sandbox_0.002.cpio.gz
*I will test the download tonight.
**Use uextract to extract? then run the script, "run_psandbox2.sh"

Edit: I seem to be missing files. Something must have been wrong with my packaging script. I will try again later. End Edit

Edit #2-- I updated the link. I will explain the fixes in another post --End Edit#2

in my tests the chroot folder now successfully unmounts. This now fixed issue arose due to code changes that allow my fakeroot folder to be anywhere (see post). However, I haven't fully tested this feature yet. Prior to doing so I would like to demonstrate some previously developed features.

Anway the latest changes to my psandbox script can be found at:

https://github.com/s243a/psandbox.sh/co ... ce61f474bc

I fixed was using the "-L" option in find because the I had a symlink to my psandbox scripts. This was wrong because I only wanted to follow one symlink rather than all. It resulted in an error where when the symlinks were followed one way cpio had a symlink but when they were followed another way cpio led to a folder. This resulted in an error when trying to extract because the folder and symlink conflicted with each other. The error caused cpio to stop extracting and this resulted in not all files being extracted.

To resolve this problem I modified my mk_tar script as follows:

#!/bin/bash
#tar -czvf ../slacko_arcade_sandbox.tar.gz $(find -L . -name '*' | grep -v "^[.]/psandbox$" ) 
version=0.002
{ 
	find . -name '*' | grep -v '^[.]/psandbox$' -v | grep -v '^[.]/psandbox/*$';
	 find ./psandbox -name '*' | grep -v '^[.]/psandbox$' -v
} \
| cpio -o -O ../"iron-84-chroot_sandbox"_${version}.cpio

gzip ../"iron-84-chroot_sandbox"_${version}.cpio

which should be renamed because we are no longer making a tar archive.

An update on my chrooted iron demonstration:

iron-84-chroot_sandbox_0.003.cpio.gz
*Extract by right clicking and select uextract. For the scripts to work correctly it (must?) be extracted to a physical device (any folder) and not on a aufs layer.

Either:
1. Run the Script, "run_psandbox.sh" and select:
-- option 1 for my psandbox scripts,
-- option 5 for a modified version of @mikewalsh's / @watchdog's script (see post) to start the chrooted iron (see post)
-- option 6 to run as the portable version of Iron.
2. Run the simplified iron_scripts/ironchroot script directly (like options 5 & 6 above). By default this will launch iron in a chroot but by supplying different option, you can run it in portable mode instead.

@TODOs (near term)
1. Make script to install menu items for some of these options
2. Add more secure container option based on rufwoof's code (see post "Fatdog unshare xephyr capsh container")
3. Further testing of options for psandbox script and bug fixes.

The latest psandbox commit was:
https://github.com/s243a/psandbox.sh/co ... ce61f474bc

The run_psandbox2.sh script is not part of this repo. It's code can be found at:

The simplified script to start iron in either a chroot or as a portable is not part of the above repo. The code for it can be found here:

What I think that I may do is create a new repo for these example scripts and also for some alternative scripts for the purposes of simplification or working out ideas.

The lastest release is back down to the expected size of about 515M, in the last example release I must of forgot to remove some stuff. I haven't tried downloading and testing yet. I only tested before packaging. I'll test the download now.

Edit: I was able to test the simlified scripts (option #5 and #6). Both of these options work on FD64-811 The portable option starts faster than the chroot option. The psandbox code seems to be missing from the archive (or failed to extract) and so it must be paced in the correct location either via a folder or symlink. For instance, one needs a symlink called "psandbox" that points to the root of the psandbox project.

s243a wrote: ↑Mon Jan 18, 2021 3:36 am

An update on my chrooted iron demonstration:

iron-84-chroot_sandbox_0.003.cpio.gz
*Extract by right clicking and select uextract. For the scripts to work correctly it (must?) be extracted to a physical device (any folder) and not on a aufs layer.

Either:
1. Run the Script, "run_psandbox.sh" and select:
-- option 1 for my psandbox scripts,
-- option 5 for a modified version of @mikewalsh's / @watchdog's script (see post) to start the chrooted iron (see post)
-- option 6 to run as the portable version of Iron.
2. Run the simplified iron_scripts/ironchroot script directly (like options 5 & 6 above). By default this will launch iron in a chroot but by supplying different option, you can run it in portable mode instead.

@TODOs (near term)
1. Make script to install menu items for some of these options
2. Add more secure container option based on rufwoof's code (see post "Fatdog unshare xephyr capsh container")
3. Further testing of options for psandbox script and bug fixes.

The latest psandbox commit was:
https://github.com/s243a/psandbox.sh/co ... ce61f474bc

The run_psandbox2.sh script is not part of this repo. It's code can be found at:

The simplified script to start iron in either a chroot or as a portable is not part of the above repo. The code for it can be found here:

What I think that I may do is create a new repo for these example scripts and also for some alternative scripts for the purposes of simplification or working out ideas.

The lastest release is back down to the expected size of about 515M, in the last example release I must of forgot to remove some stuff. I haven't tried downloading and testing yet. I only tested before packaging. I'll test the download now.

Edit: I was able to test the simlified scripts (option #5 and #6). Both of these options work on FD64-811 The portable option starts faster than the chroot option. The psandbox code seems to be missing from the archive (or failed to extract) and so it must be paced in the correct location either via a folder or symlink. For instance, one needs a symlink called "psandbox" that points to the root of the psandbox project.

For the simplified iron chroot script, I noticed somethings weren't getting unmounted so I added the missing unmounts. Still some things I forgot to delete for cleanup (will fix later).

function umountall(){
  set -x
  
  umount -l	/${CONT_NAME_DEST}/tmp/.X11-unix	
  umount -l /${CONT_NAME_DEST}/dev/pts
  umount -l	/${CONT_NAME_DEST}/dev
  umount -l	/${CONT_NAME_DEST}/proc
  umount -l	/${CONT_NAME_DEST}/sys
  umount -l	"/$CONT_NAME_DEST"
  umount -l	"$Cont_TMPFS"
  umount -l	"${BIND_Target}"

  for to_remove in "/${CONT_NAME_DEST}"; do
    to_remove="$(realpath "/${to_remove}")"
    if [ -z "$(cat /proc/mounts | grep "${to_remove}")" ] && 
       [ ${#to_remove} -gt 1 ]; then
      rm -rf ${to_remove}
    fi
  done

  xhost -
}

I just edited the paste rather than creating a new paste. Also as part of this edit was a fix to more reliably find the mount point of an sfs. See post:

Get the Original Mount Point (i.e. exclude binds)

Edit: This script should properly cleanup now.

New release of the chrooted-iron example:

iron-84-chroot_sandbox_0.004.cpio.gz

I fixed the error causing the psandbox scripts from being packaged. The issue is that if the path is a symlink in the find command then you have to have a trailing slash so that it resolves to a directory (or at least that's what I think was going on).

I've added the option to run iron in a container. This option is based on the following script by ruf-woof:

Fatdog unshare xephyr capsh container

To run it either go to the folder that says "iron_scripts" and then run the command "ruf-iron-flask.sh". Alternatively, you can run it by running "run_psandbox2.sh" and then selectiong option #7 for running Iron in a container.

I should note that this is the 32bit version of iron that I have contained in this archive. I tested the container script on fatdog64-811 on this current version. I've tested the other scripts on older version (of this example). Testing seems to take a fair bit of time which slows development.

I didn't expect this example-release to be any different than the previous one (last post). What I did was tried to modify my code to be closer to rufwoof's latest code. However, I'm not using a shared folder or window monitoring. I did put in some of the code related to it but the logic is structured so that so that said code won't execute.

rufwoof is also using cwm but my current code uses jwm. I did add a switch stement where if one changes the WM parmater (currently hardcoded) than rufwoof's cwm code will be executed. I also added some of his code related to window monitoring but this code isn't yet executed. My motivation here is to lean from what rufwoof is doing and in the future provide more options.

So while these changes were primarily geared to code alignment, mysteriously they fixed bugs in my previous example release. The jwm menus now work as they should. So while, the intent here is for a chrooted iron browser, it looks like that much more of the Slacko 571 / Slacko 5.7.2 (by Sailor's and Mikeslr respectively). capabilities are apparent in the Xephyr gui. Since it boots in full screen mode one might thing they are actualy in Slacko 571/5.7.2 until they hit the alt-tab key.

Anyway, here is the latest example release:
iron-84-chroot_sandbox_0.005.cpio.gz
* you can use uextract to extract this.
** tested on fatdog64-811 prior to packaging
*** not tested after packing or uploaded
**** contains portable iron32 browser

Here is the latest container code (not really part of the pasanbox project yet):

I'm thinking that I should now consider merging this code with psandbox to provide this container capability into psandbox. The simpler scripts though would still be available as examples.

s243a wrote: ↑Mon Jan 25, 2021 7:23 am

rufwoof is also using cwm but my current code uses jwm. I did add a switch stement where if one changes the WM parmater (currently hardcoded) than rufwoof's cwm code will be executed. I also added some of his code related to window monitoring but this code isn't yet executed. My motivation here is to lean from what rufwoof is doing and in the future provide more options.

So while these changes were primarily geared to code alignment, mysteriously they fixed bugs in my previous example release. The jwm menus now work as they should. So while, the intent here is for a chrooted iron browser, it looks like that much more of the Slacko 571 / Slacko 5.7.2 (by Sailor's and Mikeslr respectively). capabilities are apparent in the Xephyr gui. Since it boots in full screen mode one might thing they are actualy in Slacko 571/5.7.2 until they hit the alt-tab key.

I've swapped over to using jwm now myself

viewtopic.php?p=16047#p16047

With some additional key codes defined in .jwmrc

<Key mask="A" key="space">window</Key>
<Key mask="CA" key="Down">exec:amixer -c 1 set Master 2%-</Key>
<Key mask="CA" key="Up">exec:amixer set -c 1 Master 2%+</Key> 
<Key mask="CA" key="Return">exec:xterm</Key>
<Key mask="CA" key="m">maximize</Key>
<Key mask="CA" key="x">close</Key>

it can be made very cwm'ish

It's working well. One factor is that Fatdog's jwm setup is preventing rox desktop being run, but I'm not a great user of desktop icons anyway - I rather use the tray to hold the icons I more often use. Otherwise its working very well for me.

Usually when loaded the alt-tab key steps between main session windows, of which the Xephyr is one. Xephyr however has a hard coded Ctrl-Shift key combination that toggles locking the mouse/keyboard into the Xephyr window, or releasing it. If Xephyr is started as a window rather than full screen then its window title shows that key combination and state, but when full screened you obviously don't see that. So I experimented with different ways to indicate the mouse/keyboard locked/unlocked state and finally opted to just have a systray icon - a ball that is coloured green if unlocked, blue if locked.

So for instance when locked then alt-tab will step just between windows within the Xephyr session/(full screen) window, if unlocked then alt-tab steps through the main sessions windows, of which the Xephyr window is just one. If the ball is clicked then I have it just present a information box

Very usable as a desktop, so much so is I pretty much use it solely as my desktop (started as part of ~/Startup). But that's very contained/restricted in what any hack might achieve. For ssh'ing I flip back into the main session (Fatdog, that uses OpenBox/lxqt panel) where data is also stored. I use /home/shared within the 'container' that appears as /mnt/sda4/shared in my case in the main session, for moving files between the two.

As the sfs, changes and top folders that are used to set up the container are in a ext HDD another benefit is that there's no memory constraints involved. cd to /root and dd a massive file and that won't stop because ram is exhausted but instead just works, at least up to the limits of available disk space.

In effect 'root' is just the userid name of a restricted user, that is running within its own X, isolated from the main session (real root) X session, and that has restricted access to mounting or even viewing files/folders outside of the chroot within which it resides.

My present code runs things on a one-off throw-away basis i.e. the contents of 'changes' are simply removed when the container is exited. That could easily be modified to leave the contents, so that you'd resume the session as last left off, or with the option to remove the content before starting to 'start clean'. Or as EasyOS does, make sfs copies of the content so that you might 'snapshot' a session, perhaps start clean after that, and then later 'restore' (unsquashfs) the snapshot copy to revert back to that.

EDIT: After some tidying up, I'm using a darker jwm theme

rufwoof wrote: ↑Wed Jan 27, 2021 2:54 pm

s243a wrote: ↑Mon Jan 25, 2021 7:23 am

rufwoof is also using cwm but my current code uses jwm. I did add a switch stement where if one changes the WM parmater (currently hardcoded) than rufwoof's cwm code will be executed. I also added some of his code related to window monitoring but this code isn't yet executed. My motivation here is to lean from what rufwoof is doing and in the future provide more options.

So while these changes were primarily geared to code alignment, mysteriously they fixed bugs in my previous example release. The jwm menus now work as they should. So while, the intent here is for a chrooted iron browser, it looks like that much more of the Slacko 571 / Slacko 5.7.2 (by Sailor's and Mikeslr respectively). capabilities are apparent in the Xephyr gui. Since it boots in full screen mode one might thing they are actualy in Slacko 571/5.7.2 until they hit the alt-tab key.

I've swapped over to using jwm now myself

viewtopic.php?p=16047#p16047

With some additional key codes defined in .jwmrc

Code: Select all

<Key mask="A" key="space">window</Key>
<Key mask="CA" key="Down">exec:amixer -c 1 set Master 2%-</Key>
<Key mask="CA" key="Up">exec:amixer set -c 1 Master 2%+</Key> 
<Key mask="CA" key="Return">exec:xterm</Key>
<Key mask="CA" key="m">maximize</Key>
<Key mask="CA" key="x">close</Key>

it can be made very cwm'ish

It's working well. One factor is that Fatdog's jwm setup is preventing rox desktop being run, but I'm not a great user of desktop icons anyway - I rather use the tray to hold the icons I more often use. Otherwise its working very well for me.

Usually when loaded the alt-tab key steps between main session windows, of which the Xephyr is one. Xephyr however has a hard coded Ctrl-Shift key combination that toggles locking the mouse/keyboard into the Xephyr window, or releasing it. If Xephyr is started as a window rather than full screen then its window title shows that key combination and state, but when full screened you obviously don't see that. So I experimented with different ways to indicate the mouse/keyboard locked/unlocked state and finally opted to just have a systray icon - a ball that is coloured green if unlocked, blue if locked.

So for instance when locked then alt-tab will step just between windows within the Xephyr session/(full screen) window, if unlocked then alt-tab steps through the main sessions windows, of which the Xephyr window is just one. If the ball is clicked then I have it just present a information box

s.png

Very usable as a desktop, so much so is I pretty much use it solely as my desktop (started as part of ~/Startup). But that's very contained/restricted in what any hack might achieve. For ssh'ing I flip back into the main session (Fatdog, that uses OpenBox/lxqt panel) where data is also stored. I use /home/shared within the 'container' that appears as /mnt/sda4/shared in my case in the main session, for moving files between the two.

As the sfs, changes and top folders that are used to set up the container are in a ext HDD another benefit is that there's no memory constraints involved. cd to /root and dd a massive file and that won't stop because ram is exhausted but instead just works, at least up to the limits of available disk space.

In effect 'root' is just the userid name of a restricted user, that is running within its own X, isolated from the main session (real root) X session, and that has restricted access to mounting or even viewing files/folders outside of the chroot within which it resides.

My present code runs things on a one-off throw-away basis i.e. the contents of 'changes' are simply removed when the container is exited. That could easily be modified to leave the contents, so that you'd resume the session as last left off, or with the option to remove the content before starting to 'start clean'. Or as EasyOS does, make sfs copies of the content so that you might 'snapshot' a session, perhaps start clean after that, and then later 'restore' (unsquashfs) the snapshot copy to revert back to that.

EDIT: After some tidying up, I'm using a darker jwm theme

s1.png

I'm a bit behind on your latest work here. I hope to get back to it soon but I have a few balls in the air. Maybe from my next post or to you'll see what I mean.

This is an interesting experiment. My psandbox scripts are a bit on hold but included here (not tested) with the sfs file contained in the linked archive. What is tested are modified versions of the chroot script used by @mikewalsh to start the ironchroot he published (see browser_scripts/simplechroot) and modified versions of @rufwoof 's earlier container scripts.

puli7.3_x86_64-ungoogled-seamonkey-hardlinked_0.001.cpio.gz

The actual file is larger than one might expect (925MB for the sfs file, 993MB for the whole archive, with sfs included) but contained two browsers and three separate chroot systems. The chroot systems are:
1. Pure Puli/Xenial64 w/ portable seamonkey as the browser
2. Puli/Xenial64 upgraded via the rootfs of @wiak 's WDLGO_UbuntuFocal64, with ungoogled chromium as the browser. (See post about the upgrade methadology)
3. A pristine Firstrib WLGO rootfs (No browser or gui)

The intent here is to be able to experiment with several systems and try to save space via hardlinks. In the future, I think I'll try to save more space by deleting rather than moving the files that I need for the upgrade and not including seamonkey. I like seamonkey because it provides composer as an html editor and works on older system than chromium based browsers will. However, ungoogled chromium starts very fast and should be a good choice from a privacy perspective.

Rather than doing a pure Puli system I might have two upgraded systems, one with the multi-arch symlink hack and one with separate architecture directories. I also might try using official Xenial next time rather than Puli becuase since more people use Xenail on this forum and it will provide said users with an upgrade option. Also Puli security features aren't really meant to be run in this way.

Space wise it really isn't huge from a modern perspective. I know some small laptops are still quite limited but the laptop that I tried this on has 8gb of ram and I bought it in 2014. For ram limited systems (new and old) there is the possibility of booting without copying the sfs to ram. That said currently, I am only trying this as a chroot or container system so this isn't relevant at this point.

Run Instructions
1. Use uextract to extract the archive.
2. Run the script "run_psandbox2.sh
3. Selection either option #5 (Use Simplified Iron Chroot Script @mikewalsh's approach) or Option #7 (Start Iron in a Container @rufwoof 's )
4. For the container option select either option #1, which will run the upgraded Puli/Xenial64 w/ ungoogled Chromium, or option #2 which will run a prestine Puli/Xenial64 with seamonkey as the browser. With the simplified chroot (option #5) you can also chroot into to WDLGO_UbuntuFocal64 but this option has neither gui or browser support.

Feel free to try other options also but the other options aren't guaranteed to work either because I haven't tested them with this setup or they might depend on system system specific literary. I tested this archive on fatdog64.

Hi guys! Very late to the chRoot party,,, but would like to run other puppy distros from within a chroot.

For example... did a full install of debian to a disk (SDA4).

eg... something like ..

mkdir /myChroot
mount /dev/sda4 /myChroot
mount --bind /dev /myChroot/dev
mount --bind /proc /myChroot/proc
mount --bind /sys /myChroot/sys
...
chroot /myChroot 

This worked because there was a debian install waiting at the base of sda4.

Question: How to do this for a foreign puppy liveiso? Short words please! I'm struggling to get my head round this.

The intention is to run the guest on a VT (CTL-ALT-F2).

Something like this perhaps ? (loop-mount the main puppy .sfs and chroot in)

# set path to puppy sfs
SFS="/mnt/sda2/bwormp/puppy_dpupbw64_10.0.6.sfs" ### change this !

mkdir /myChroot
#mount /dev/sda4 /myChroot
mount -o loop "$SFS" /myChroot
mount --bind /dev /myChroot/dev
mount -t devpts devpts /myChroot/dev/pts
mount --bind /proc /myChroot/proc
[ ! -d /myChroot/sys ] && mkdir /myChroot/sys
mount --bind /sys /myChroot/sys

chroot /myChroot

@fredx181, mount -o loop $SFS /myChroot makes /myChroot read-only.
bash will complain when you finally do chroot /myChroot.

The idea is to be able to run FD901 from within a FD813 machine that will not be upgraded until the summer because the install on that machine is busy ... many souls to harvest never enough time!

Not my decision. But anyhoo ...

The SFS files are ...

/mnt/home/32bit-fd64_901.sfs
/mnt/home/kernel-source-6.1.46.sfs
/mnt/home/compiz-reloaded-2024.02-x86_64-1.sfs
/mnt/home/wine-8.6-i686-1.sfs
/mnt/home/fd64-devx_901.sfs 

The idea being I can test the workings of this construct here (on a co-incidentally 901 mc) before trying it elsewhere and perhaps with other distros? What will work?! Ohhh tingles!!!

# ./newchroot001.sh
sh: ./newchroot001.sh: Permission denied
# ./newchroot001.sh
mount: /myChroot: WARNING: source write-protected, mounted read-only.
mount: /myChroot/dev: mount point does not exist.
       dmesg(1) may have more information after failed mount system call.
mount: /myChroot/dev/pts: mount point does not exist.
       dmesg(1) may have more information after failed mount system call.
mount: /myChroot/proc: mount point does not exist.
       dmesg(1) may have more information after failed mount system call.
mkdir: cannot create directory ‘/myChroot/sys’: Read-only file system
mount: /myChroot/sys: mount point does not exist.
       dmesg(1) may have more information after failed mount system call.
./newchroot001.sh: line 13: --: command not found
# 

yes there were complaints! we are used to that.

# chroot /myChroot
chroot: failed to run command ‘/bin/sh’: No such file or directory
# 

fredx181 wrote: ↑Tue May 21, 2024 9:29 am

(loop-mount the main puppy .sfs and chroot in)

Code: Select all

# set path to puppy sfs
SFS="/mnt/sda2/bwormp/puppy_dpupbw64_10.0.6.sfs" ### change this !

In terms of FD901 - Where is this sfs? or rather can I make one?

Or is there an easier way ?