Puppy Linux Discussion Forum

install various linux distributions, including graphical ones such as ubuntu and even kali. The caveat to those linux distros is that they can take up a great deal of internal storage, and cannot run if they are transferred to sd card.

pupgeek wrote: ↑Sun Nov 01, 2020 5:18 pm

Update: After further research, I found that I cannot use the mount command for squashfs files without having rooted my device, which really defeats the purpose of termux, as it provides a linux environment to those who do not want to root their devices. Unless the termux team can come up with a way around that, I guess this is a dead issue for now.

Perhaps that is the case, but could you please post link or links to the research results you have that lead you to this conclusion in case there are ways around it or otherwise.

wiak wrote: ↑Mon Nov 02, 2020 11:30 pm

pupgeek wrote: ↑Sun Nov 01, 2020 5:18 pm

Update: After further research, I found that I cannot use the mount command for squashfs files without having rooted my device, which really defeats the purpose of termux, as it provides a linux environment to those who do not want to root their devices. Unless the termux team can come up with a way around that, I guess this is a dead issue for now.

Perhaps that is the case, but could you please post link or links to the research results you have that lead you to this conclusion in case there are ways around it or otherwise.

Newer versions of busybox might have a tool that we can use to mount squashfs as non privlaged users:

"squashfs-fuse: new package "
http://buildroot-busybox.2317881.n4.nab ... 72520.html

My understanding is that with fuse non privlaged users can mount certain types of files:
https://wiki.archlinux.org/index.php/FUSE

For instance fuseISO let's you mount the following file types:

 *.iso ; *.nrg ; *.bin ; *.img ; *.mdf
 

https://wiki.archlinux.org/index.php/FuseISO

As a side note I expect that puppy will run in full install mode on termux.

If One has root then the following might be useful:

Grimler91 commented on 14 Oct 2018
@lars18th I've added libfuse, squashfuse and encfs to the root repo, but I've barely tested them.

https://github.com/termux/termux-root-p ... -429646346

I know that this is slightly different than the original intent of this thread.

It occurred to me that wanderer's symlink approach could be useful here. See post:
symlinks w/ whiteout files (Re: Corepup - a minimalist modular system)

So the layers, would be extracted to /initrd/roN, where N is the layer (e.g. an sfs layer), and then the root folder would mostly be comprised of symlinks pointing to the various initrd subfolders. Maybe an sfs might have a name like devx_sfs.tar, since it isn't really an sfs file. Rather than call it sfs_load, maybe we call it layer_load, where a layer, can be a directory, an archive (e.g. zip) or an image file. If the right tools and permissions are available the file would be mounted to the appropriates initrd subfolder, otherwise it would be extracted. Unfortunately, I don't know a way to extract an sfs file without root permissions.

We also need a command to re-evaluate the layers. This command could be based on the timestamps (i.e. last modified) of the file. However, this wouldn't capture deletions of the symlinks. One should then perhaps whenever deleting a symlink create the appropriate whiteout file to the rw layer. We can't though force this behavior without a full layered file system.

Any easy hack might be to trick pkg into thinking that it is in PUPMODE=2, let it install a package, look at the list of installed files for the package, copy these files to the rw_layer, and then replace the added file with a symlink pointing to the rw layer. There could also be a daemon running that scans the file system for changes and then updates the layers as changes are identified. For instance if a file no longer exists that is in the rw_layer then it gets delete from the rw_layer if it resides in the rw_layer, otherwise a whiteout file is added to the rw_layer.

bigpup wrote: ↑Sun Nov 01, 2020 8:35 pm

install various linux distributions, including graphical ones such as ubuntu and even kali. The caveat to those linux distros is that they can take up a great deal of internal storage, and cannot run if they are transferred to sd card.

Have you just tried to install one of the Puppy Linux versions?
Most versions are around 300 to 400 MB in total size installed as a frugal install.

bigpup wrote: ↑Thu Dec 10, 2020 3:01 pm

Have you just tried to install one of the Puppy Linux versions?
Most versions are around 300 to 400 MB in total size installed as a frugal install.

On Android, that is simply not going to work I feel. Puppy needs aufs supporting kernel, which is not going to be available. Since I doubt even overlayfs support will be in Android kernel by default, it seems to me that s243a's suggestion is the most likely to be workable (using symlinks, per tinycorelinux method, to merge in sfs, assuming it proves possible to mount the sfs in the first case). Will certainly be interesting to know if someone gets round to trying this in Android environment - really needs some practical testing now to see if these ideas are feasible or quickly discovered as dead-ends. I currently use AnLinux to run various Linux versions on my Android phone - I don't really use it in any serious way, but it does work (and in the past I've even installed gtkdialog (I used version compiled for arm from FatDog for that) and jwm on such system along with some Puppy utility, which certainly worked; but never tried also merging/mounting any sfs filesystem.

wiak wrote: ↑Fri Dec 11, 2020 7:23 am

bigpup wrote: ↑Thu Dec 10, 2020 3:01 pm

Have you just tried to install one of the Puppy Linux versions?
Most versions are around 300 to 400 MB in total size installed as a frugal install.

On Android, that is simply not going to work I feel.

Not as is but if you extract all the sfs files and run in PUPMODE=2, You are part of the way there. Unfortunately, you won't be able to easily extract these sfs files on android and doing so will likely require root (as a minimum).

Puppy needs aufs supporting kernel, which is not going to be available. Since I doubt even overlayfs support will be in Android kernel by default, it seems to me that s243a's suggestion is the most likely to be workable (using symlinks, per tinycorelinux method, to merge in sfs,

Maybe there is a user-space solution (e.g. fuse-unionfs)? If not, then patching the kernel might be possible but unfortunately, this will likely leave you without google play.

assuming it proves possible to mount the sfs in the first case).

If one can't mount the sfs, then maybe extract it via some web service. The Termux wiki suggests using a tor hidden service to do this:
https://wiki.termux.com/wiki/Bypassing_NAT
*unless your server (for this webservice) is able to open a listening port to the internet. ISPs though make this difficult for you.

Will certainly be interesting to know if someone gets round to trying this in Android environment - really needs some practical testing now to see if these ideas are feasible or quickly discovered as dead-ends. I currently use AnLinux to run various Linux versions on my Android phone - I don't really use it in any serious way, but it does work (and in the past I've even installed gtkdialog (I used version compiled for arm from FatDog for that) and jwm on such system along with some Puppy utility, which certainly worked;

Fatdog has a nice script to create the jwm menus, which avoids the need to compile some of the stuff used by the puppy "fixmenus" approach.

If we do full install (i.e. PUPMODE=2) the merging isn't completely necessary but I want to experiment with symlink approaches to better learn how they might be useful and also being able to break things down into separate layers is useful for development and system repair. The layers form a more stable base, which we can easily reuse for fresh installs.

As a side note, rather than using whiteout files, a layer can be divided into separate folders such as:
pup_ro1_visible #File can be scene in the top layer
pup_ro1_duplicated #File is duplicated in a higher layer
pup_ro1_wh #File is deleted in a higher layer.

Where these three layers, comprise the extractred base sfs file of a version of puppy. These folders can be symlinks (or hardlinks) to a folder (or mount point) that contains all the actual files for the layer. The top layer would symlink to the pup_ro1_visible folder which may have a secondary sylinink elsewhere. A background process could check for files which are unexpectedly deleted, modified or added. Files which are added will likely be the easiest to detect due to the timestamp. These files can be moved to the pup_rw layer, and then replaced with a symlink in the combined folder.