FatDog64-813 - fatdog64-iso-builder-2022.10 ... Initial problems.

[Duprate]

Initially I downloaded fatdog64-iso-builder-2022.10.tar.xz, configured sfs-baselist removing the following packages:

#gimp-2.8.22-x86_64-1
#libreoffice-6.3.6.2-x86_64-1
#libreoffice-dict-en-6.3.6.2-x86_64-1
#seamonkey-2.49.5-x86_64-1
#flash-plugin-32.0.0.156-x86_64-1.txz
#vlc-plugin-2.0.6-x86_64-1_vlc303.txz
#armagetronad-0.2.8.3.4-x86_64-1
#pipepanic-0.1.3-x86_64-1
#xinvaders3d-1.3.6-x86_64-1
#gtktetris-0.6.2b-x86_64-1
#sven-2020.08-x86_64-1
#florence-0.5.4-x86_64-1

Added the following packages, necessary for the operation of the modern web browsers (Firefox, Vivaldi, Google Chrome, Opera):

atk2-2.36.0-x86_64-1.txz
at-spi2-atk-2.26.2-x86_64-1.txz
at-spi2-core-2.28.0-x86_64-1.txz
glib-networking-2.56.1-x86_64-1.txz
gobject-introspection-1.56.1-x86_64-1.txz
gsettings-desktop-schemas-3.28.0-x86_64-1.txz
gtk3-3.24.31-x86_64-1.txz
librest-0.8.1-x86_64-1.txz
libsoup-2.62.3-x86_64-1.txz
libwayland-1.20.0-x86_64-1.txz

Creating basesfs (fd64.sfs): Create a link (fatdog-iso-builder) in /usr/src/, renamed "builder"

In the terminal type:
# cd /usr/src/builder
# ./build-iso.sh base

Will result in: /fatdog-iso-builder/iso/"fd64.sfs"

Observed issues with fd64.sfs made with fatdog64-iso-builder-2022.10.tar.xz:

1- The "builder" downloads the files listed from "http://distro.ibiblio.org/fatdog/packages/800", however "fatdog-bins-813.0-x86_64-1.txz" according to the attached figure, was not being found. The system did not start automatically, because the "autologin" would have to be placed manually in /bin;
2- It didn't show the contents of an SFS, it gave an error message and mounted it in the /mnt folder;
3- It didn't show the expanded initrd, it just indicated the path in /tmp;
4- The tested browsers (Chrome and Firefox) crashed and closed when trying to download a picture from the internet or send a picture to illustrate a comment on the Puppy Forum; and
5- I tried several ways to remaster fd64.sfs, it solved one thing, another broke....

Solution found:
1- I replaced the build-iso.sh of fatdog64-iso-builder-2022.10.tar.xz with the build-iso.sh from previous version (fatdog64-iso-builder-2021.11.tar.xz);
2- I edited lines 13,14,15,16 regarding the identification of version 813;
3- I redid the process of creating fd64.sfs; and
4- I was successful, with a base file with 220 Mb!

Someone will ask themselves: Why so much work?

Large apps or apps that swell over time, I use them in the form of ROXapps, external to the system on another HD partition (example: LibreOffice, Gimp, Wine, PortableApps, Clamav Anti-virus).
They install with symlinks. Browsers, with one click install a copy in spot, single folder, not scattering files throughout the system.
I don't use savefiles, everything is loaded into RAM and when turning off the PC, everything is brand new!

[jamesbond]

Thanks Duprate for testing.

The particular missing packages were not uploaded yet at the time you tested.
It has since been updated, and building with standard package list should work (I just tested it - I got t working fd64.sfs as well as a bootable ISO).

I however have re-uploaded fatdog-iso-builder-2022.10.tar.xz, as I found a problem with "runsfs.sh" (apparently a long-standing problem that nobody noticed) and I have fixed it in the newly uploaded package (dated 17 Oct, the old one was dated 7 Oct). If you don't use runsfs.sh for testing then there is no need for re-upload.

[Duprate]

The fatdog-iso-builder of the 17th Oct 2022, fixed all the previously presented problems. Now the base file is perfect!

However, using fd64-devx_813.sfs, when trying to compile the 5.19.16 kernel, it presented a new problem.
1- I downloaded the tarball from https://kernel.org/;
2- I unzipped it in an appropriate place, renamed it to linux, created a symbolic link in /usr/src/;
3- I created a folder with the name 5.19.16, I created a symbolic link in /lib/modules;
4- From the 5.19.14 kernel .config I created a .config for 5.19.16;
At the terminal:
1- # cd /usr/src/linux
2- # make -j2
I got a file not found error message at:
/usr/include/x86_64-linux-gnu/*(as per image-1)
/usr/lib/gcc/x86_64-linux-gnu/7.3.0/*(as per image-2)

I unzipped fd64-devx_813.sfs

It turns out that all these files already exist in /usr/include/
So I created the folder in /include/x86_64-linux-gnu, and copied the files (from image-1) into /x86_64-linux-gnu

What was missing in /usr/lib/ the "gcc" folder, is located in /usr/lib64/gcc/x86_64-linux-gnu/7.3.0/* which I copied to /usr/lib/

I could also do all this by creating symbolic links in their proper places.

After that was complete, I repackaged fd64-devx_813.sfs.

It turned out great, and I've already compiled the 5.10.148 LTS kernel and 5.19.16 kernel, with the new fd64-devx_813.sfs.

[je55eah]

Do you have links to a good writeup about roxapps? I was looking for that a few weeks ago.

This is pretty in depth. Does it work now or do we all need to study and repeat this procedure to make an iso remaster? The issue of missing files came up when I was testing remastering and tried to build a remaster from a system installed by a remaster. Did that issue stem from the same foundational problem?

[Duprate]

Good Morning! I will prepare an answer that also serves as a tutorial ....

[step]

Do you have links to a good writeup about roxapps? I was looking for that a few weeks ago.

While Duprate is writing his answer/tutorial, here's an overview, application directories online manual, which is the same manual you can open by pressing F1 in a rox window. You could also try to search for roxapp or appdir and similar terms in the old forum.

[Duprate]

Do you have links to a good writeup about roxapps? I was looking for that a few weeks ago.

Hi!
Examples of ROXapps are already included in the system itself in /usr/local/apps. In common, they all have a script (AppRun) and an image (.DirIcon)
Also, the folder and its contents must have the same properties (such as spot or root).
Making a web browser like ROXapps, which will run inside a single folder, in /home/spot/ without spreading files throughout the system:

First, download the browser (in the example, Firefox) in the language of your choice;
With UExtract, extract the contents and rename the folder to firefox-install;
Now you have a folder "firefox-install" and inside it one named "firefox";
Save time and work right there, at /home/spot/Downloads;
In the "firefox" folder create inside it folders (one inside the other) ".cache/mozila/firefox/" and ".mozilla/firefox/", an image ".DirIcon" and, with Geany, a script "AppRun" according text below:

Code: Select all

#!/bin/sh
#script to run $APP as spot...
APP=$(readlink -e $0)
[ "$APP" ] || APP=$0
export APPDIR=$(dirname "$APP")
[ "$APPDIR" = "." ] && APPDIR=$(pwd)
APPDIR="$APPDIR/firefox"
P="$APPDIR"
[ -x "$P" ] && apulse run-as-spot "$P"
exit 1

Now, level up and in the "firefox-install" folder create a ".DirIcon" image, another "AppRun" script that will install the Browser every time you click in "firefox-install", according to the text below:

Code: Select all

#!/bin/bash
DIR="`dirname \"$0\"`"
DIR="`( cd \"$DIR\" && readlink -f $(pwd) )`"
echo "DIR: $DIR"
export APPDIR=$DIR
cp -aR /$DIR/firefox /home/spot
ln -s /home/spot/firefox/.cache/mozilla/firefox /home/spot/.cache/mozilla
ln -s /home/spot/firefox/.mozilla/firefox /home/spot/.mozilla
rox --RPC << EOF
<?xml version="1.0"?>
<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope">
<env:Body xmlns="http://rox.sourceforge.net/SOAP/ROX-Filer">
<PinboardAdd>
<Path>/home/spot/firefox</Path>
<X>1800</X>
<Y>980</Y>
<Label></Label>
</PinboardAdd>
</env:Body>
</env:Envelope>
EOF
exit 1

Put your ROXapps in the place you prefer, on another HD partition; The first time you install and use the browser, configure it, customize it and when you like it, go to where ROXapps is, click on it with the right mouse button, delete the "file "firefox" and replace it with "firefox" which is in /home/spot/ . Ready! This is how the browser is updated on first use and later on updates! Every time you use it, it will be brand new and just the way you like it!
For your safety, after installing the browser you must unmount all partitions on the disk before using it.
Other apps are made like this, some install a copy of the app, others create symlinks (libreoffice, wine, gimp, anti-virus...) and, in this case, the source partition remains mounted while using the app.

[Duprate]

If there is interest, later I can explain about libreoffice, wine, gimp, anti-virus ... and how I converted them into ROXapps (almost an .AppImage ..... what not!)

[Duprate]

I forgot to say something important: This way of using the applications, only make sense when you don't use savefile. The first time I used FatDog, I created a savefile with the basic choices (language, timezone, keyboard, hostname, wallpaper, etc...). Then I converted it to a 03-changes-813.sfs which I haven't changed anymore! In the overlayfs system, we can load and unload some .sfs modules and others like fd64-devx.sfs still didn't work. Therefore, the best way to load extra modules is through ROXapps.
In the case of the browser, it's the safest way to use it, both on AUFS and Overlayfs systems, as long as you don't use savefiles and it's a frugal installation.

[je55eah]

@Duprate

This is a better tutorial than the one Rox Desktop published.

I modified your script slightly:

Code: Select all

#!/bin/sh
#script to run $APP as spot...
APP=$(readlink -e $0)
[ "$APP" ] || APP=$0
export APPDIR=$(dirname "$APP")
[ "$APPDIR" = "." ] && APPDIR=$(pwd)
P="$APPDIR/firefox"
[ -x "$P" ] && apulse run-as-spot "$P"
exit 1

My understanding is that this serves the same purpose as a .desktop file or whatever the method is to add a program to the start menu on fatdog.

What is the best method to add an entry to the start menu and the right click desktop menu? I think it is hand typed into the openbox settings. What is the role of LXQT/LXDE on Fatdog? Is JWM just hanging around doing nothing?

In order to get it to run it was necessary to also install gtk3-3.24.31-x86_64-1 as you mentioned. I did this with gslapt.

I built the RoxApp installer as you specified also. It worked, but not from an exfat formatted partition. This is specific to your strategy as it does just like you said. It copies the Firefox folder to home and symlinks the cache and whatever to the folder on the external partition so that your browser history and settings are kept after you destroy the ram loaded fatdog session.

I have attached a nifty icon that I made for this.

Typical users may prefer to skip the firefox-install scheme and simply copy the firefox folder to /usr/local/apps like the other RoxApps. Firefox seems to create the cache and settings data files in home regardless of where the program is located. If it were a different app, and you wanted to follow your installer scheme, how would you locate all of the artifacts which the various apps pollute the system with? How did you know which files needed to be symlinked for safe keeping?

The first time you install and use the browser, configure it, customize it and when you like it, go to where ROXapps is, click on it with the right mouse button, delete the "file "firefox" and replace it with "firefox" which is in /home/spot/ . Ready! This is how the browser is updated on first use and later on updates!

Do you mean the whole firefox folder? It makes sense that way. It sounds like this manual procedure is necessary to keep the updates pushed out by mozilla and some of the configuration choices.

ROX is quite a thing. I started looking at this site and it seems like Rox is being underutilized. It could be a distro unto itself.

https://rox.sourceforge.net/desktop/software.html

If i uninstalled Rox, what would break on the Fatdog system? Could I replace it with something like Equinox Desktop Environment?

I forgot to say something important...

I understand. Unfortunately I haven't found a configuration that works the way I would like yet. My goal is to run from ram with no devices attached, but to have the option of plugging in a drive and saving my changes if I want to. Save files don't allow me to unplug and multisession files introduce a host of mysterious errors which break virtualbox and god knows what else.

Thanks for the deep dive. I've learned a lot from this exercise.

[Duprate]

@Duprate

"This is a better tutorial than the one Rox Desktop published.

I modified your script slightly:"

Good Morning! Glad you like! Soon, I will make a tutorial on libreoffice. I like your installer icon (I'll copy it)! The description of the method I use, serves my purposes (frugal installation, overlay system, no savefiles). It's just an example. Everyone must do what they need to get what they need! Adapt, modify and improve, according to your interests. Good luck!

My knowledge is limited, complicated questions I won't have answers but I'm lucky and insistent......

"Constant repetition of movements over decades leads to perfection! This is Kung Fu!
Or maybe you just have tendinitis........"