Stripping Down a Puppy

[s243a]

This is a continuation of another thread. Anyway to start open up a puppy and find the bases sfs and mount it. Copy the files inside a folder called rootfs. The basic code is as follows:

Code: Select all

mkdir -p $curdir/$rootfs/proc;
mkdir -p $curdir/$rootfs/sys
mkdir -p $curdir/$rootfs/dev

 
mount -o rbind /proc $curdir/$rootfs/proc
mount -t sysfs none $curdir/$rootfs/sys
mount -o rbind /dev $curdir/$rootfs/dev
cp -f /etc/resolv.conf $curdir/$rootfs/etc/resolv.conf

chroot $curdir/$rootfs /bin/bash

https://pastebin.com/zrdGa2fV
(I removed some intializations and if blocks from the above code but not in the above link). Use whatever you want for the system shell in the last line such as bash or ash)

Once mounted you can open the puppy package manager with the command:

Code: Select all

xwin & Open a second terminal to uninstall stuff
dotpup

and then select the install tab.

From there you can see what packages are installed, you can even download the packages with all the dependencies. You might want to do the latter if you want to port puppy aps to another distro (or even another version of puppy).

Now if you try uninstalling a package from the command line

Code: Select all

petget -leafpad

you get the following error

No file named leafpad.files found in /root.packages/folder

/usr/local/petget/removepreview.sh
refusing cowardly to remove the package

Possible suggestions: No pkgs beginning with I found
Possible solutions: Edit /root/.packages/user-installed-packages to match the package and start again

There is a file called "~/.packages/buitin_files/leafpad". I wonder if we could just move this file up one level and add a .files to the end of the file name and try again.

There is also a tool with puppy to remove built-in packages but I don't know if it works properly or not in a chroot enviornment.

Another issue is when I get above said error that it opens up geany. Perhaps in a minimal system I want to uninstall geany, in which case I want to open nano instead. Maybe the fix is to edit the default text editor file or alternatively maybe I can make a script called geany and have it open nano instead in a new terminal.

Anyway, once you are done you can make an ISO if you want. Here is a script that is approxamitly what we want to make said iso:

make_ISO_Fm_slitaz-rootfs - TazPup64 Build Kit

I'll need to check through it though to make sure that it is looking in all the right places. For instances I need to replace "slitaz-rootfs" with "$root_fs" and I need to set prefix to an empty string. The script in the last link was mast on mistfires built-kit for tazpup.

Similarly I might want to change the default file manager to midnight commander.

Edit: wiak wanted me to add the following to this post:

What would really be cool for me is a method whereby one can open all the applications one use on a regular basis and any others one wants to keep in the base sfs/ones specific network and printing connections, take a snapshot of the things running (including the firmware/modules/libs/configurations, etc. currently in use) and then rebuild the base sfs to include ONLY the things currently running and in use.

This comment inspired me to start a related thread, since a lot could be said about this and can also I feel be regarded as a subtopic of "Stripping Down a Puppy".

I'd be grateful therefore if, s243a, you could put a link to the following as a subtopic in your first post, which could be usefully explored in parallel (but, being in separate thread, not swamp your main thread):

Determining "device drivers" (in kernel, external modules, in conjunction sometimes with firmware for hardware devices) used by your computer and how to remove unneeded ones

http://www.murga-linux.com/puppy/viewtopic.php?t=115717

wiak

[oui]

Hi s243a

Very interesting observations. But I find the only right way, especially for those having the intention to change heavily the classic mixture of Puppy (no rox, no jwm, no seamonkey, no mplayer but vlc, etc or from very different sources and use (rox in the iso named busterpup!) would be to always process and publish two separate versions, a one-bone classic and her full "rantings" (I hope the word is right, comes from translate.google.com!)... Only that permit don't to have tonnes and tonnes of avoidable dependencies completing later a stripped down Puppy...

which was the last one-bone in Puppy (pls link)?

Kind regards

[s243a]

Hi s243a

Very interesting observations. But I find the only right way, especially for those having the intention to change heavily the classic mixture of Puppy (no rox, no jwm, no seamonkey, no mplayer but vlc, etc or from very different sources and use (rox in the iso named busterpup!) would be to always process and publish two separate versions, a one-bone classic and her full "rantings" (I hope the word is right, comes from translate.google.com!)... Only that permit don't to have tonnes and tonnes of avoidable dependencies completing later a stripped down Puppy...

which was the last one-bone in Puppy (pls link)?

Kind regards

Maybe LazY Unicorn:

LazY Unicorn Version 001

The LazY puppy series (and successors) are a good model for a barebones pup because a lot of stuff has been moved into sfs files. I recall that unicorn was a minimal version of tahrpup but I can't find the thread link. Granted I don't think that Unicorn is as minimal as you are asking.

[nic007]

What would really be cool for me is a method whereby one can open all the applications one use on a regular basis and any others one wants to keep in the base sfs/ones specific network and printing connections, take a snapshot of the things running (including the firmware/modules/libs/configurations, etc. currently in use) and then rebuild the base sfs to include ONLY the things currently running and in use.

[s243a]

What would really be cool for me is a method whereby one can open all the applications one use on a regular basis and any others one wants to keep in the base sfs/ones specific network and printing connections, take a snapshot of the things running (including the firmware/modules/libs/configurations, etc. currently in use) and then rebuild the base sfs to include ONLY the things currently running and in use.

That might be doable because the "ps" command often gives the file location of the program running. One could in said system block the removal of all packages that contain files listed by the ps command. A tool could take several snapshots with the ps command and merge them into a list of packages not to remove. Let's call this a block list.

One might also want to use the strace command for the formation of said block list.

[nic007]

It's relatively easy to remove software packages with their associated libs. A method to retain the specific modules, firmware, device drivers etc. in current use and exclude the rest will be cool.

[s243a]

It's relatively easy to remove software packages with their associated libs. A method to retain the specific modules, firmware, device drivers etc. in current use and exclude the rest will be cool.

That's more than I want to tackle but google brings up some stuff.

If you know what kernal modules you are using then you can use the modinfo command to see what firmware is being used by the module.
(See https://unix.stackexchange.com/question ... dule-needs )

Finding out what modules are required seems also possible but is much more difficult:

Actually, there seems to be a way to list processes that claim a module/driver - however, I haven't seen it advertised (outside of Linux kernel documentation), so I'll jot down my notes here:

First of all, many thanks for @haggai_e's answer; the pointer to the functions try_module_get and try_module_put as those responsible for managing the use count (refcount) was the key that allowed me to track down the procedure.

Looking further for this online, I somehow stumbled upon the post Linux-Kernel Archive: [PATCH 1/2] tracing: Reduce overhead of module tracepoints; which finally pointed to a facility present in the kernel, known as (I guess) "tracing"; the documentation for this is in the directory Documentation/trace - Linux kernel source tree. In particular, two files explain the tracing facility, events.txt and ftrace.txt.
....

https://stackoverflow.com/questions/448 ... nel-module

[nic007]

I think I'm going to use Pup-SysInfo and work from there. As far as software goes: stripping out an older browser from the base sfs is probably the only worthwhile thing to do as far as functionality and saving space is concerned.

[s243a]

I think I'm going to use Pup-SysInfo and work from there. As far as software goes: stripping out an older browser from the base sfs is probably the only worthwhile thing to do as far as functionality and saving space is concerned.

That would be the most relevant thing to strip out size wise and because older browsers become obsolete. That said I still want to look at the general problem. As for applicability, consider the case that someone is running multiple virtual machines at once but at the same time we can look at this as purely as an academic exercise.

[s243a]

Here is some skeleton code. which is neither finished nor tested:

Code: Select all

curdir=`pwd`
s_rootfs="root_fs" 
prefix=""
action="move"

#Let's remove these applications and maybe put them into an sfs
A=( "leafpad" "solitaire-minesweeper-1.3-i486" 
"gtkhash-0.6.0-i686-up" "leafpad" "MPlayer" "clipit" "geany" "get_java"
  "getflash" "get_libreoffice" "gnome-mplayer" "pfind" )
#Let's remove this desktop related stuff and move it into a different sfs
B=( "desk_icon_theme_blue_moon_Slacko" "desk_icon_theme_stardust" 
"desk_icon_theme_zabuton" "desktop-file-utils" "gnome-menus" )


for arr_name in A B; do
  eval "arr=( \"\${"$arr_name"[@]}\" ):
  arr_action=$"$arr_name"_action
  #Move is faster but perhaps copy is safer
  arr_action=${arr_action:-cp} 
  target=$"$arr_name"_target
  target=${target:-"$curdir/$arr_name"}
  for app in "$arr{[@]}"; do
      case "$arr_action" in
      cp)
          copy_built_in()
      ;;
      mv)
          move_built_in()
      ;;
      pet) #We might also want to convert to other package formats
          mk_pet_fm_built_in()
      ;;
      esac
      chroot "$curdir/s_rootfs" $remove_builtin "$app" #This tool is part of puppy
  done 
done

It looks like we can use the remove_builtin function from the command line.

Before we call this function I want to either move, copy or repackage the stuff we are removing in case we want it later (e.g. as a package for a buildsystem or as an sfs that we can load when needed). All built-ins in the above array are found in x-slacko slim. I thought X-Slacko slim was a good test candidate because it supports multile package formats (e.g. void linux and tinycore) as well as supporting pet repos for multiple versions of puppylinux.

The stuff that is architecture specif I'm more likely to want to remove.

Also note that we might need to add some post removal hacks to the loop. For example we might want to create a fake geany once it is removed that calls a terminal based text editor instead. And a fake rox or pcmanfm that calls midnight commander once either of those are removed. This might not be necessary though if all functions call /usr/local/bin/default"$apptype" rather than calling the application directly.

[nic007]

I removed the builtin old Palemoon browser from Tahr605 manually and saved about 30MB on base sfs size (maximum compression). Remove builtin packages does not work for me (applications are not removed from base sfs after a remaster). Actually, I'm going to try and use remove builtin packages again but this time using one of my alternative remaster scripts which works totally different from Puppy's builtin remaster script.

[s243a]

I removed the builtin old Palemoon browser from Tahr605 manually and saved about 30MB on base sfs size (maximum compression). Remove builtin packages does not work for me (applications are not removed from base sfs after a remaster).

That sounds like a bug in the remaster program.

[wiak]

What would really be cool for me is a method whereby one can open all the applications one use on a regular basis and any others one wants to keep in the base sfs/ones specific network and printing connections, take a snapshot of the things running (including the firmware/modules/libs/configurations, etc. currently in use) and then rebuild the base sfs to include ONLY the things currently running and in use.

This comment inspired me to start a related thread, since a lot could be said about this and can also I feel be regarded as a subtopic of "Stripping Down a Puppy".

I'd be grateful therefore if, s243a, you could put a link to the following as a subtopic in your first post, which could be usefully explored in parallel (but, being in separate thread, not swamp your main thread):

Determining "device drivers" (in kernel, external modules, in conjunction sometimes with firmware for hardware devices) used by your computer and how to remove unneeded ones

http://www.murga-linux.com/puppy/viewtopic.php?t=115717

wiak

[s243a]

I've made some progress:
https://pastebin.com/EbhGMD5N

the remove_builtin (of puppylinux) doesn't work if the list of files isn't given as full paths. This is an issue for leafpad:

Code: Select all

....
/usr/share/icons/hicolor/scalable/apps
 leafpad.svg
/usr/share/pixmaps
 leafpad.png
 leafpad.xpm

since only the directories are given as full paths. My script gets around this but I can't call remove_builtin to remove the files. Worse yet in older versions of puppy this tool doesn't work from the command line.

I think I"ll just incorporate what "remove-builtin does into my script rather than trying to utilize puppies version.

On another note if one wants to use the package manager in a chroot enviornment, one might not necessirly be able to call "dotpup" as I did in a x-slacko slim chroot. As an alternative one can call:

Code: Select all

/usr/local/petget/pkg_chooser.sh

This will populate all the files in /root/.packages based on "0setup <<<copied in by Woof"

Edit: I did a quick hack to get puppylinux remove_builtin to work with leafpad. What I did in my script is to re-write the list of files for leafpad located in:

Code: Select all

/root/.packages/builtin_files/

so that all entries had a full path given. After doing this then the remove_builtin functions works. The modified script is located at:
https://pastebin.com/yw0Z7kWH

I will modify the script so that you can use puppies built-in tool to remove built-in files or by changing a variable, use an external version of this script that will be written by me.

On another note, In the case where I'm using puppylinux built-in tool to remove built-in programs I will pass a list of programs to this function at once. Currently, I'm calling this script once per built-in that I want to remove. This slows things down because each time this function is called the menus are updated. This slows things down.

Also if we remove jwm then we don't want to update these menus.

[nic007]

Actually, remove builtin packages did work for me but the few I removed hardly made a dent in the size of the base sfs (that's why I thought it didn't work). So apart from removing the old browser as mentioned before, not really worthwhile removing any other software.

[mikeslr]

Actually, remove builtin packages did work for me but the few I removed hardly made a dent in the size of the base sfs (that's why I thought it didn't work). So apart from removing the old browser as mentioned before, not really worthwhile removing any other software.

In remastering Slacko 5.7.1 to create Slacko 5.7.2CE, my principal concern was to reduce the amount of RAM required to run the later. My original intention was to strip out rarely used or unusable (why have an document scanner application if you don't have a scanner) from the puppy_xxx.sfs and place those applications in an adrv or ydrv not included in the ISO but separately downloadable if wanted. So I did a lot of experimenting as to what could be safely removed via remove-builtins. I did not attempt to remove applications it listed until I located the corresponding menu-listing and found out what it did: not removing any which gave a warning that doing so would break some desired application nor removing any which, having no menu-listing, suggested it was part of the 'infra-structure'.

Before removing any applications I used gnewpet to preserve them for use in the adrv or ydrv. It was only by comparing RAM usage by booting both with and without those file-systems that I found out the actual impact removing applications from the puppy_xxx.sfs had had.

Essentially it appears to relate to the number of inodes Puppy creates for an application. Inodes take up RAM. Removal of an application increased the available RAM by between 1 and 2 Mbs. But my exploration was not so extensive as to reveal whether that increase depended on just the number of applications removed; the size of the application removed; or the complexity of the application removed --assuming complex applications would require creation of more inodes than simple applications.

I may still have the folder of the pets created with gnewpet and will hunt for it if you think knowing what pets could be safely removed from Slacko 5.7.1 will help.

One thing I do remember that I was updating geany. Petget --for reasons beyond me-- expected it to be the default text-editor. Before removing the old version of geany, leafpad had to be set as default text-editor. Otherwise pet-get no longer functions. [After installing the updated geany, it could be set as default text-editor and leafpad removed. The updated geany had originally been built under precisepup and did not overwrite the installed version; hence the need to remove the old version.].

[nic007]

You may want to consider loading your additional (or stripped) applications as extra sfs's and not as part of an adrv or ydrv. The reason for this is that the adrv and ydrv are normally automaticly loaded into RAM at bootup if you have enough RAM (unless you specify pfix=nocopy, I think) whereas extra sfs's are not loaded into RAM. On some of my systems I load extra sfs's automatically by way of commands in /etc/rc.d/rc.local or you can load them during a session when needed.

[s243a]

You may want to consider loading your additional (or stripped) applications as extra sfs's and not as part of an adrv or ydrv. The reason for this is that the adrv and ydrv are normally automaticly loaded into RAM at bootup if you have enough RAM (unless you specify pfix=nocopy, I think) whereas extra sfs's are not loaded into RAM. On some of my systems I load extra sfs's automatically by way of commands in /etc/rc.d/rc.local or you can load them during a session when needed.

I'll keep that in mind

[nosystemdthanks]

probably already known, but so far the only thing you miss without libLLVM is webkit-based browsers.

if your browser is gecko based, you can probably remove libLLVM or move it to a separate sfs.

it seems (very) possible that some other package besides webkit-based browsers need it, but i have yet to find one.

[nic007]

By only removing the old browser and libLLVM I got base sfs's of Tahr605, Precise571 and Racy55 down to 139Mb, 107Mb and 88Mb respectively. Racy does not have libLLVM. All using xz maximum compression. Seamonkey 2.48 works on Tahr and Precise so can share the same sfs between both, all my other sfs-addons also work on all the distributions I mentioned so can be shared.