Puppy Linux Discussion Forum

Why a Chroot? Because unlike other isolation mechanisms any Puppy can use it.

This started out as an exploration of running Wine in a Chroot, but evolved into a more general exploration of the Chroot mechanism. But you may want to skip this post and wait for someone to publish a more secure chroot system. s243a was working on that viewtopic.php?f=136&t=1917&i=1, especially with s243a’s sandbox script, viewtopic.php?p=17162#p17162. Something like it may overcome the ‘not-completely isolated OS flaw’ achieved via the currently available Chroot technique. Still, that technique goes a long way.

Running Windows Programs under Linux poses several privacy and security problems. The ones which this post attempts to deal with are the combined effect of (1) Wine’s lack of any anti-malware protection and (2) that it is generally intrusive into your Linux Operating System. Puppys’ counter-measure to these intrusions is isolation. EasyOS can run Wine in a containerized sub-ordinate operating system. Puli can run Wine from RAM, having loaded Wine into RAM from a now removed USB-Key. The following discusses a third approach, but first –in passing-- there may be a 4th.

Does anyone know what became of UnderDog? I’ve never used it. But as I recall at one time Puppys could run the applications under other operating systems with which they shared the computer. How does that differ from ‘Chrooting’ as described below?

In order to run Web-browsers which demand more recent glibc libraries that older Puppys could not provide, Watchdog and MikeWalsh developed a chrooted Web-browser, viewtopic.php?f=90&t=760. Dissecting it reveals two components: (1) a top level usr folder which will merge with the usr folder of the primary Puppy; and (2) a top level cont folder.

The following explains how to create an SFS with such /cont folder and the files in the MainOS's /usr folder to make use of the /cont folder. Start by creating a directory which --via the dir2sfs command-- will later be packaged as an SFS, referred to below as Chroot.SFS. Within it, create two folders: cont and usr.

As you know, Puppys are modular constructs, of which the puppy_verion_number.sfs contains the File -and-Window managers and the applications builtin by the Puppy’s Dev. For example, the puppy_xenialpup64-7.5.sfs provides that Puppy with jwm window manager, rox-filer, and all those applications you will find OOTB on the Start Menu, other applications which do not require menu entries, and “infra-structure” –the libraries and other files which tie all the pieces together and enable the Xenialpup64 operating system to make use of them.
Subject (I think) to the limitation that a 32-bit operating system can’t run a 64-bit operating system, any puppy_version_number.sfs can provide the contents of the /cont folder. Just mount the puppy_version_number.sfs and copy all its files and folders into /cont.
On the Screen-shot “Puppy-using-cont”, the top shows the cont folder as a Top-Level folder of the Main OS; the bottom shows the contents of the cont folder, to wit: an entire puppy_version_number.sfs having been unpacked into /cont.

Reasons to run a Chrooted Puppy:
The original – overcomes the ‘only one glibc per operating system’ limitation.
Security – Under Puli, because of the way it handles SFS differently than Puppys, the Chroot.SFS can be smartloaded, or SFS-loaded after boot-up, and the partition on which the Chroot.SFS is located can then be unmounted. The Chrooted Operating System remains functional and those of its applications which worked before un-mounting continue to work.
Under Puppys, the partition from which the Chroot.SFS was mounted can NOT be unmounted. However, applications which run in the Chroot can not ‘see’ beyond the Chroot folder, apparently can not access any partition, including the one from which the SFS was loaded. and applications such as pmount fail. See Chroot-Mount-Unmount.png.

But if a partition has been mounted using your MainOS, applications within the Chroot can access that partition.. For purposes of security, the Chroot.SFS can reside on a partition different from that of your Puppy. It can even be SFS-Loaded from a USB-Key’s partition, even one just big enough to only hold the Chroot.SFS. Under a Puppy running without a SaveFile/Folder --such as one in which setup using the NicOS-Utility-Suite Save2SFS module-- Puppy's Home/System partition is not automatically mounted and can remain unmounted throughout your entire work session.
Special Purpose Applications: Wine is obvious. But there may be others. For example, under Bionicpup the best, all inclusive, video editor is KDEnlive. But under Xenialpup it is Openshot. Running them both from the same OS is difficult-to-impossible as their python structures conflict.

Reason Not to Run a Chrooted Puppy.
Setting up the /cont folder can be a PITA. It’s not too bad if the application you want to run under it is a portable. Just drop the portable folder into the /cont/opt folder. Or a builtin – well, it’s builtin. But if its something else, you have to run the Puppy which will be used in /cont, install the pets, debs or what-have-you, test, and remaster that Puppy before its remastered puppy_version_number.sfs can be used in /cont.

Updating portable applications, or adding other portable applications –and you’ll be surprised at how many applications can work as portables-- isn’t too bad, either. Just mount the Chroot.sfs, copy its files into another folder, make the changes to /opt and dir2sfs that other folder. [Recommended, portables apps be tested before dir2sfs]. But if the application is not a portable, your only choice other than working your way to a remaster is to manually install each of the files required by an application and hope for the best. During that process there is no Puppy Package Manager and no form of dependency-checking.

And remember, if any bookmarks, plugins, addons, setting or configurations are necessary, that has to be done before the dir2sfs.. Configurations --such as those found in /root/.config-- have to be copied from their location in the Source-Puppy-booted-up into /cont/root/.config before running dir2sfs.

Applications in the Chroot can only access folders in the Chroot. The data files you download or create there will only be in RAM, generating all the problems which come about with RAM limitations. To preserve those files and/or work on them using an application of your Main-OS, you’ll have to move/copy them out of their folders in Chroot.
[A simplified version of MIkeWalsh's Spot2Root, https://drive.google.com/drive/folders/ ... 4vCp2rVBqX may be useful. Download, unpack, delete the unnecessary files/lines pertaining to changing permissions, keep those relating to moving files into/out-of folders, repack under a new name].

Before running dir2sfs on the folder with its populated /cont folder there are a couple of other things you have to do. (1) You have to know how to start the application within the Chroot and, possibly, (2) create the structure making it easy to do so from the MainOS; (3) create a connection between the chrooted application and your Main-OS; and create a Menu entry.

Applications are started by calling their binaries, or a bash-script or bash-wrapper “on the path”. Neither applications in /opt, nor by default, their scripts or wrappers are ‘on the path”. One location, unique to Puppys, is “on the path”: /root/my-applications/bin. That folder, within /cont, provides a convenient location to hold symbolic-links to and scripts or wrappers which call the binaries, or scripts or wrappers which already are a part of the application. Convenient: if you have to make adjustments all the relevant files will be in one place.
A simple example would be handling a Chrooted portable-firefox. Portable-firefox is started via a wrapper with the name ‘ff’. That wrapper is in the firefox folder, which would be in the /opt folder in /cont: /cont/opt/firefox/ff. You can open two rox windows: one to /cont/opt/firefox, the other to /cont/root/my-applications/bin. Drag the ff wrapper from the former into the latter and select Link(relative). You now have a symlink ‘on the path’ which will start the application.

I’ve attached a Temple containing example scripts for use in /cont/my-applications/bin. I’ll discuss them after explaining what you’ll need to do in the Chroot.SFS’s /usr folder. https://www.mediafire.com/file/2vzk3dzk ... ar.gz/file

Watchdog, MikeWalsh and s243a have actually made this part of the job pretty easy. As with all applications that are to have menu entries, each application within the Chroot that you intend to use from the Main-OS via a menu entry has three components: (1) a binary, script or symbolic link ‘on the path’; (2) an icon to display on the Menu-listing; and (3) a Desktop file which uses the previous two files.
The existing desktop file for an application can serve as a template for the same application that will be in the Chroot. But, you’ll probably want to change three or four things. First the name of the file so that it doesn’t overwrite the ‘non-Chroot’ version. For example, firefox.desktop can become Chroot-firefox.desktop. Chroot-firefox.desktop’s Name= argument undergoes a similar change, e.g. firefox can become chroot-firefox.
Third, and most important, the Exec= argument is edited to call the script which will call the file within the Chroot that starts the application within the Chroot.
Watchdog, MikeWalsh and s243a developed following Template for the script ‘on-the-path’ which is called by the Desktop’s Exec= argument. They located it at /usr/bin; and I’ve continued that arrangement. Only two things change from one Script to another. First, for obvious reasons, the name of each script must be unique. And Second, the name of the file within /cont which starts the application must also be unique AND that used within the Chroot to start the application. The following is the text within that script. Note, it continues the firefox example from above, where firefox is started by the symbolic link 'ff' in /cont/root/my-applications/bin to that file in /cont/opt/....:

#!/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 NAME-WITHIN-CONT-TO-START-APPLICATION "$@"
# for example: chroot /cont ff "$@"
exit

You may want to use a different icon than that used with the non-Chroot version: just makes it easier to spot on your Start-Menu. FWIW, I usually place icons in /usr/share/pixmaps. Using a consistent location for similar things avoids having to hunt or remember a bunch of exceptions.

It isn’t necessary to set up many applications in the Chroot to run via the Main-OS’s Menu; just those few you want to have quick access to. Within the Template are all the files required to initiate the Chrooted-OS’s rox file-manager. Note, however, that those files were customized to start the Chrooted-rox differently than if you just typed ‘rox’ in a terminal on the Main-OS. Per a post by s243a, before starting rox the following command is issued in the /cont/root/my-applications/bin/roxX script:
gdk-pixbuf-query-loaders –update-cache
Without that not all Chrooted-OS's rox windows will display icons: xenial's did; dpup-stretch's didn’t.
The Chrooted Rox is opened at the /cont/usr/share/applications folder. Many of the Chrooted-OS’s applications are then only a scroll and click away. Some applications, however, won’t function such as, fortunately, pmount as shown by the screenshot above.

If before dir2sfs you created two profiles for firefox-portable, you can create structures to open either from the menu. Or you can use the chrooted rox to file-browse into the chrooted /opt/firefox folder to start either via its wrapper. For that matter, you can create several chrooted-rox menu entries to open commonly used chrooted folders.
Both the bin/closechroot (without a menu entry) and bin/mscwchroot were part of the Watchdog/MikeWalsh build. I believe the former is necessary; and the latter –which starts the Chrooted Multiple-Sound-Card-Wizard-- may be in some instances.

Although the Chroot appears to be isolated, that may not be entirely true. pmount doesn’t work; but terminal applications within the Chroot do. At least in theory, a hacker may be able to ‘escape’ the Chroot. Moreover, if I read the arguments which are to be written to /usr/bin correctly –a BIG IF-- identifying characteristics of the Main-OS are written to the Chrooted-OS. Consequently, ‘finger-printing’ of your online activity continues to be possible. However, AFAICT, if you activate a VPN thru your Main-OS, web activity in the Chrooted-OS is channeled thru it.

Hi Mike,
This looks really interesting and something I'll try, thanks for providing some details. I've run mikewalsh's iron chroot and it works fine, but seems to takes a lot of resources. What do you think the advantages of this are compared to running in a virtual machine?

wizard

wizard wrote: Sat Aug 14, 2021 2:16 pm

Hi Mike,
This looks really interesting and something I'll try, thanks for providing some details. I've run mikewalsh's iron chroot and it works fine, but seems to takes a lot of resources. What do you think the advantages of this are compared to running in a virtual machine?

wizard

Virtual Machine? I've never been able to set one up. You've reminded me that there's a 5th way to achieve isolation.
My guess is that a Chroot would require less RAM than running the same OS in a VM just because your system doesn't have to provide resources for that middle-man.

My 'test-chase' was running a 64-bit Puppy which SFS-Loaded a Chrooted 32-bit Puppy remastered to include Wine. As far as I could tell, it did not use any more resources than would have been used if a 32-bit compatibility SFS had been loaded and Wine and its applications installed. Further exploration resulted from fear and curiosity.
I had to figure out a way to run portable Windows programs if, in the future, I wanted to add them to the /cont/opt folder. I discovered that the chrooted Wine File-manager could be started by providing for it on the MainOS's menu. Using it to file-browse to a Window's executable and left-clicking the latter would run it. What else would Wine File-manager run? Apparently, most Linux binaries. But, as I expected, Wine had created its 'prefix' in the chrooted Puppy; and as I hoped, no Windows program could access anything beyond the Chroot.

One of the Linux applications Wine File-Manager could run was rox. And, with rox running, the chrooted Puppy was again familiar territory. Hence the setup to run chrooted rox directly from the MainOS, cutting out the Wine File-Manager middleman [and eliminating Wine entirely if I didn't want it].

I don't know how VMs actually use RAM. I've always SFS-loaded a Chroot.SFS from a Puppy running without a SaveFile/Folder (i.e. having employed nicOS-Utility-Suites Save2SFS to create a y-or-adrv.sfs). When the Chroot.SFS is selected via SFS-Load, the choice of whether to 'copy to a partition' or 'No Copy' is offered. Having 16 Gbs of RAM, I choose the latter. As I mentioned, under Puppys the partition can't be unmounted, but also can't be accessed from applications in the Chroot. However, my guess is that its contents have been 'cached' in RAM.
But the Chroot.sfs is an SFS. Ordinarily SFSes aren't copied into RAM; merely mounted. I'd be reluctant to choose "copy" to the partition from which the Chroot.sfs is being loaded. How would Puppy handle trying to copy it to where it already exists? But perhaps choosing to copy it to a different partition would work with the mounted chroot only using such RAM as was needed to run an opened chrooted application.
That might be more RAM-efficient than running that application via VM.

Still, I have to wonder if 'Underdog' might not be both more efficient and more convenient; and what became of it.

Well, thanks to Barry K and mistfire it still exists, https://oldforum.puppylinux.com/viewtop ... 96#p916896. Will have to explore its capabilities and limitations. But that's for another thread. I'll just note here that apparently "It will mount the partition on the bottom layer of unionfs." per above post. And per DANgerd0g, it can be used to run a 64-bit Puppy from a 32-bit Puppy. viewtopic.php?p=7299#p7299

Mike, very nice explanations.

Your work here is consistent with directions being taken by most major Linux manufacturers; containers.

As you note that UnderDOG can run a 64bit distro in a 32bit PUP, I add that may be useful, as well, for 32bit users: QEMU also affords that feature.
In fact, QEMU allows the user on any PUP, 32/64bit, to ALSO run ARM distros, PPC distros, X86 distros, X86-64 distros in the virtual PC without any disruption to the HOST.

I am following your ideas, as, it appears to relate to 'containers' of sort. Great.

Thanks, Clarity, for providing information about QEMU. Anyone interested should read/post-to the Virtualization Section, viewforum.php?f=107 . Although mixed in with posts about Wine, the 'Old Forum's Virtualization Section' offers many discussions, https://oldforum.puppylinux.com/viewforum.php?f=61

Curiosity regarding 'Underdog' got the better of me. viewtopic.php?f=7&t=3725. But, as the Edits at the bottom of the Posts imply, I don't think I'll explore it further. QEMU &/or Virtualbox do seem to hold greater possibilities for flexibly managing one's interest.

By the way, do you have any idea regarding wizard's concern about the comparative demands on system resources, i.e. RAM? Puppys pull us in opposite directions: the desire to maintain old hardware and the desire to extend our systems as much as possible. Intuitively, adding any additional system should require that some additional resources be used. But my various explorations seem to suggest that the effect shows up as cache and CPU usage with only a slight impact on available RAM.

Mike, QEMU has, for decades, the distinction of being the 'fastest' Virtual Machine(VM) for Linux because of the way Tovalds incorporated it into the kernel.

All of the VMs do essentially the same thing. They differ in how they implement within the operating system. The primary difference is in the user interface for building the Virutal PC's resources and in how they manage the Virtual PCs via the host.

QEMU has a very rudimentary (elementary in some respects) interface for building the Virtual PC (think of it as adding the components you want to your PC) and launching the virtual machine. And it is at launch that it essentially gets out of the way so that the user can run it as if he had the console desktop of the host PC and the virtual PC on the same screen. So the user 'can', should he choose, create a Virtual 32bit PC with disks drives or a virtual ARM PC with drives or a virtual PPC PC with ...

I am sure you know all of this. But new users may or may not be aware of that ability to make a PC on-screen and boot it with whatever OS they choose in that "PC" (the VM). To me, its like a Lego or an erector set for a PC. I run FossaPUP64 and test various PUPs (and others) in QEMU created Virtual PCs, regularly. For some unexplained reason, FATDOG runs FASTER in a Virtual PC than it does natively. FossaPUP64's VM runs as fast as it does natively too (I estimate it to be near 100% as fast) as I sometime when I have the VM running on the full screen, I am confused as to whether I am running the VM or the host FossaPUP64.

I have tested QEMU on Slacko64 as well as FATDOG over the last couple years.

In QEMU, you the user, can build a VM that has resources more than the physical machine has: for example you can create a Virtual PC that has 8 processors or more if you choose. Remember, it is "virtual".

For decades, developers have used VMs because they behave exactly like real PCs. This allows them a test vehicle that pretty much assures that what they build will behave the same when deployed to a real PC.

RAM allocation in VMs are static in that you will apportion 'real' memory away from the host assigning it to the VM, Also, disks space is a static allocation as well.

Others may want to add to this 'expanse' I have just given.

P.S. Here's an example from last year of running a QEMU Virtual PC on FossaPUP64.

Clarity wrote: Sun Aug 15, 2021 4:57 am

(I estimate it to be near 100% as fast)

Fast yes. But not so compatible. I use QEMU regularly. Some programs do not work correctly in QEMU and other virtual environments. Therefore, just in case, it is advisable to check critical programs in a real system. Well, this only applies to cases of creating .pet or .sfs files for example.

This post, viewtopic.php?p=35380#p35380 discusses a remastered puppy_xenialpup_7.5.sfs (32-bit) with Wine builtin ready to be used to populate the /cont folder: one of the two Top folders that make up a Chroot.SFS. The other Top folder of a Chroot.SFS consists of folders and files which will be located within the MainOS’s Top /usr folder.

Although it can be used otherwise, I recommend that it be used in the creation of an SFS. To do that download both the puppy_xenialpup_7.5.sfs and the Create_Chroot_links2MainOS-1.pet from https://www.mediafire.com/folder/g6g66r ... lpup-32bit. Then:

1. Keeping in mind that the finished product will be about 1 Gb, create folder to hold the necessary files. Right-Click an empty space, select New>Directory and give it a meaningful name, e.g. xen32wine. [The name xen32wine will be assumed below. If you choose a different name, make appropriate substitutions while following this recipe]. Left-Click that folder and create a folder within named ‘cont’ –without the quotes. Left-Click to enter that folder and leave it open.
2. File-browse to the puppy_xenialpup_7.5.sfs, Left-Click it, select View Contents, Left-Click an empty space in the Window which opened to focus Rox on it, hold down the Ctrl key while typing ‘a’ –without the quotes- to select All, then drag the contents of that Window into the cont folder you created in Step 1. Wait for it to finish copying the 988 Mbs of files. Then file-browse up so that you will see ‘cont’ as a folder. [Left-Click the puppy_xenialpup_7.5.sfs again to unmount it].
3. You have two choices. I recommend the 1st.
(a) Right-Click the Create_Chroot_links2MainOS-1.pet and select UExtract from the pop-up menu. In the extraction folder will be a folder named ‘usr’. Left-Press, Hold, then drag that folder adjacent to the cont folder in xen32wine. File-browse up so that you will see xen32wine as a folder. Right-Click it and select dir2sfs from the pop-up menu. [If your Puppy does not offer dir2pet on its Right-Click Menu, open a terminal adjacent to the xen32wine folder and enter the command ‘dir2sfs xen32wine]. Wait for your Puppy to finish creating an SFS. Remember you are dealing with a 1 Gb +/- of files.
(b) You can skip the extraction of the pet and copying of the usr folder into the xen32wine folder. But then you’ll have to store the Create_Chroot_links2MainOS-1.pet someplace and install it (left-click) before you can actually use the xen32wine SFS. This choice may be useful as it permits the pet to be used with any other ‘cont’ you create; and makes it easy to change icons and/or add, delete or modify the ‘usr’ component –i.e., what applications within the ChrootOS will be directly available from the MainOS.

I believe the easiest way for Puli, viewtopic.php?f=40&t=484&hilit=puli, to make use of this (or any Chroot.OS) is merely to name the SFS –rather than something like xen32wine-- as an a-or-ydrv.sfs; for example ydrv_puli7.3.sfs: general format ydrv_puliX.Z.sfs where X.Z corresponds with your puli’s version number. It will automatically be loaded on bootup. To avoid that you’ll have to delete it, or edit its name to, for example, 1ydrv_puli7.3.sfs. When used with Puli booted from a USB-Key, after bootup Puli retains its ability to continue to function –including the functioning of the Chrooted OS-- even if the USB-Key it booted from is unplugged.

For other Puppys, review what I wrote in the OP about the use of nicOS Utility Suite's Save2sfs in order to run without a SaveFile/Folder and locating the Chroot.SFS on a partition which is not the one on which a Puppy's system files are located. Booting into such Puppy will not mount any partitions; and If the Chroot.SFS is SFS-Loaded after bootup --choosing the 'No Copy' option-- only its partition will be mounted, but not reachable from the Chroot.OS.

I don’t have sufficient knowledge about how to use either the remastered puppy_xenialpup_7.5.sfs or its Chroot with EasyOS.

Other than to again thank MikeWalsh and watchdog for their work in developing and publicizing the Chroot technique, there is little I can tell you beyond what I’ve written earlier. A couple things are, however, worth mentioning:
Whatever appeared on the ChrootedOS’s Start-Menu, as panel-launchers or as desktop launcher-icons can’t be used to start any applications in the Chroot.OS. Your desktop is controlled by the Window and File managers of your MainOS. Hence the need to start applications in the Chroot.OS via the files in the MainOS. But, as I reported in the OP, rox once running can start applications in /opt and many applications having desktop file in the Chroot.OS’s /usr/share/applications. I subsequently discovered that so can AppFinder.
To facilitate the occasional use of some application which the Chroot.OS has –other than those directly called by the MainOS-- that the MainOS lacks, one of the applications you can directly start from the MainOS is the Chrooted.OS’s AppFinder. It will look something like this Screenshot showing the chrooted-xenialpup’s AppFinder invoked under Fossapup64.

In short, a Categorized (albeit floating) Start-Menu with description of the available applications. AFAIK, AppFinder can be installed into any Puppy. Including its dependencies, it is rather small. Puppy Package Manager will find it under its full name "xfce4-appfinder" in one of your Puppy's binary compatible's repos.

The reason why I’ve stressed occasional is that it was brought to our attention (IIRC by s243a) that the script to invoke a chrooted application should end with the command ‘exit’. [Examine the scripts in /usr/bin in the pet. With the exception of mscwchroot, all do]. I am uncertain of the reason. But while physically isolated the Chroot and any of its applications make use of the same RAM as the MainOS and its applications. Perhaps without the ‘exit’ argument a Chrooted application does not fully release the RAM it used even when you close it.
It may be worth considering installing CleanRAM, https://www.forum.puppylinux.com/viewto ... 0cb#p25645 into your MainOS.

Exploring the possibility of running Telegram --a Windows program which will run under Wine-- in either a Chroot based on dpup-stretch or xenialpup on this post, viewtopic.php?p=36336#p36336 and later on that thread I ran into problems, especially with browsers. In particular see, viewtopic.php?p=36438#p36438. As noted there, after creating and SFS-Loading the dpup-stretch Chroot, I merely copied web-browsers into the /cont/opt folder and tried to start them via their wrappers.
Keep in mind that the original web-browser xenial-based chroot MikeWalsh published was to run Iron; and it did function under precise. I can confirm that it still does.
My guess was that the problems I encountered could have been memory-management related as a consequence of not actually building the applications into the Chroot.
So I rebuild the Chroot based on dpup-stretch to include Iron89, slimjet, vivaldi, firefox-esr, and seamonkey. SFS-loading that Chroot into Bionicpup64 all the browsers were functional. Under precise, none were. Indeed, some of the other chrooted applications which functioned under precise employing the xenialpup-chroot didn't when employing the dpup-stretch chroot. Examinations via terminal and ldd did not always disclose the same reason for the failure.
My suspicion now is that the underlying cause of the problems are that the versions of bash used in precise and that used in dpup-stretch are not the same nor sufficiently similar. Or some other 'infra-structure' incompatibility.
Hence, my recommendation to employ xenialpup as the chroot for older Puppies.

@mikeslr :-

I believe there are subtle differences between Ubuntu and Debian, despite that the former is based on the latter.

I first came to realize this last year, when starting to use Zoom (before developing the Zoom-portable build). They offer both Ubuntu .debs AND Debian .debs.....but the Debian .deb refused to run in a 'buntu-based Puppy, and the Ubuntu .deb would NOT run properly in a Debian-based Pup. And this was despite superficially appearing identical when extracted & examined side-by-side.

I've opted to always use Ubuntu-based stuff wherever possible, simply because it's more likely to work acceptably well OOTB.

T'other Mike.