firmware & driver cutter - removing unwanted firmware and drivers

[mikeslr]

Thirteen years ago the very capable technosaurus with assistance from the very capable amigo published a pet which "... should remove... unneeded modules from your zdrv", https://oldforum.puppylinux.com/viewtop ... a7#p383851. Both that post suggests, and IIRC, at that time both drivers and firmware were always located in the zdrv. I've attached an unaltered version of the last pet published.

zdrv_cutter-0.3.pet

(2.13 KiB) Downloaded 42 times

I have no doubt that at the time it was published it properly performed its intended function. I think I may have successfully used it once. But since its last iteration things have changed. Puppys then were only 32-bit. Now there are 32 and 64 bit Puppys. That circumstance is further complicated by the different routes slackware and debian/ubuntu took in handling libraries: slackware locating 64-bit libraries in folders named lib64; debian/ubuntu in folders named x86_64-linux-gnu. And recently debian/ubuntu have imposed a rule that the top-level /lib folders can not be used other than by the original publisher(s) of an OS.

Another change is that 13 years ago both the RAM and Storage media available to a user were magnitudes smaller. On the other hand, so was the size of the included libraries. technosaurus wrote of a 20 Mb zdrv. Today, there are fdrv's which (being exclusive of drivers) are in the 300 Mbs range. While the need to reduce firmware and drivers in a system to just those actually useful may have lessened, it still occasionally exists. And as technosaurus put it, some of us are "just the minimalist at heart".

As you may know, I can't program my way out of a paper bag. But I have a fair grasp of how systems function and on at least 2 occasions recently removing unneeded drivers and firmware could have assisted in providing a solution to a problem posed in the Beginners of Users Section.

Before I recommend employment of a 'cutter', would someone who does know his or her way around code be interested in examining that of the attached pet and determining if it, or a modification of it, would function?

[Jasper]

@mikeslr

Thanks for sharing this and I only stumbled across your thread as I was curious to see what the end result would be if I tried it.

I used my existing FP64-95 fdrv (48mb) and run the script and it provided me with a new fdrv.sfs which was approximately 6mb. No input from me as the script ran by itself.

Swapped over the new SFS and rebooted and the audio/video worked using MPV but no WiFi adapter/connectivity available to me.

Very surprised and it is a shame the original creator is not onboard to ask questions on it's usage.

[Jasper]

I tried the same experiment again with the latest JammyPup-beta D.

This time I remained online so that I knew the WiFi adapter was being used. My thinking was that activated modules might be retained.

Swapped over the fdrv SFS file and got my desktop and tested once again with MPV. Audio and video playback available.......... still no WiFi connectivity.

[Keef]

Is the wifi module not loaded, or is it missing firmware? The script can find loaded modules ok, but the list of firmware is 'hard coded', so some is likely to be missed.

[Jasper]

@Keef

The WiFi module is loaded but for some reason it removes it.

I did not check the wired network or Bluetooth connection either.

MInd you, if they were identified they could have been simply copied over to the newly created SFSes.

[amigo]

Thanks for the Honorable Mention -I just stumbled over this. I'm less capable these days than in 2010, but I'll try to be helpful.

As I recall, the zdrv was just kernel modules, at least that was what my code addressed. Third party firmware was and is a separate matter, and neither has anything to do with libraries -except that their directory paths are under a lib directory. Around that same time I had begun working on routines to sort out firmware also -which was and is more difficult.

I supplied a very generic way to handle just kernel modules, whch are still under the 'official' /lib/modules. Technosaurus script in the .pet includes that bit, but goes further into the puppy specifics, and so is more elaborate and tricky. I can't judge how the pet would perform on any system. But I'll post here a version of what I gave back then -except that this one will not move or copy anything. It only lists the kernel modules needed by the current running system and should work on ~any~ sort of linux.

Code: Select all

#!/bin/bash
# cheers from Gilbert @2023
CWD=$(pwd)

# set this to the name of a temp dir:
# since we don't copy modules, we don't need this
#TMP=/tmp/mymodules

# create the module directory in the TMP dir:
mkdir -p $TMP

# get the version of your kernel
KVERS=$(uname -r)

lsmod |tail +2 |cut -f1 -d' ' > $CWD/mods

cd /
for module in $(cat $CWD/mods) ; do
	# I have uncommented the first and comment the second one to just see the list
	 find lib/modules/$KVERS -type f -name "$module*\.o"
	#find lib/modules/$KVERS -type f -name "$module*\.o" -exec cp --parents {} $TMP/ \;
done

# I have also commented this so this script won't alter your system at all
#depmod -b $TMP/lib/modules/$KVERS -e -F /path/to/kernel/System.map

Handling firmware blobs is another matter -it's more difficult to discern which blobs are being used. As part of my own package format/manager/builder, I did some work on creating individual packages for each blob (or blob group), using a pretty-fied list of the firmware which comes with the firmware bundle.

Hope that was helpful.

[rockedge]

@amigo I am experimenting with this code to further the work on ways to trim the kernel modules SFS in KLV-Airedale. KLV is Void Linux based and supplies a lot modules and firmware, which are in a firmware SFS.

@wiak and @fredx181 both have worked with experimental utility scripts that work on trimming the modules SFS. Early on in FirstRib models pre-Kennel Linux, fredx181's script could reduce the modules SFS from 80+ mb to around 16-20 mb but at the time was a quick solution to keep the kernel components a "reasonable" size

There is also a script I believe that trims the firmware SFS that is experimental and was not quite finished to a polish.