...
It was also used for the ordering of laying out files in the filesystem, when seek time was poor and that mattered. Knoppix was the last live distro to use such a idea, that is why a DVD sized anti-puppy colossus loads so quickly. Wish he will share HIS build system.

log all file accesses with lsof during startup, then add them to the squashfs in that order_________________Check out my github repositories. I may eventually get around to updating my blogspot.

If you want to find orphaned library dependencies for all binaries in your path (excluding those needed by dynamically loaded modules/plugins that are normally outside of PATH) you can use this little script that require objdump (it only lists direct dependencies, not everything that happened to be linked whether it was needed or not):

for each of the libraries in the list you'd want to get their dependencies also - repeat until no new dependencies are found (may take a while)

Then just iterate over all of the libraries in the library path and {re}move them if you can't grep them out of the audit file

I wrote that script a long time ago, these days I would use IFS=: instead of the ${PATH//://* } bashism ... which now that I look at it should have 2 for loops - 1 for each path in PATH and another for each binary in path/*
... I don't have a way to test it right now, so I hope this is enough for someone else to figure it out - if you try and get stuck, just post what you have and I'll help debug_________________Check out my github repositories. I may eventually get around to updating my blogspot.

You're likely the man to know technosaurus. Debian have utilities to remove unused libs (apt-get autoremove), and a script to run through and validate each file (crc type check so can pin down a possible virus for instance). But sadly I've not found a script/method to validate file permissions, to reset all system files back to correct permissions in the event of doing something silly like a recursive permissions change action (yep ... that's what I did). I ended up redoing from scratch ... newly install and all of the changes/updates ....etc.

Perhaps a new install should have a record made of all the system file permissions at the time kept back as a reference so at least a recursive change could be created to reset at least those files. Combined with adding to that record set when files were added/replaced.

...
It was also used for the ordering of laying out files in the filesystem, when seek time was poor and that mattered. Knoppix was the last live distro to use such a idea, that is why a DVD sized anti-puppy colossus loads so quickly. Wish he will share HIS build system.

log all file accesses with lsof during startup, then add them to the squashfs in that order

Just discovered strace

strace -f -e trace=open -o process.trace <command to start process>

that will list what was opened by a run of a command. So if you know what files/programs are being run and in what order you could deduce the associated files. But technosaurus' lsof is probably better/easier.

lsof that must have been the tool used. Not sure how it was evoked but I recall it was instigated so early in the boot process that the resulting tar tape at the end of process could be untarred on a fresh harddrive and get a working linux (unix) install. It was tared feeding the sorted access times file list.
The process worked well, and would work well to solve your issue, if the end result was a remaster 'thin' version of what you normally used puppy for.
Its a small dumb approach really, since there is no real value to id what to prune 'before' a real build. However its a REAL fix to remove unneeded bloat, secondly the speed to re-add missing libs never caused any problems in the real world. So I think it would be beneficial to rediscover method.
Since the construction of test cases is a big effort, not like we ever had a puppy QA team anyway (Like how would I know... my post count is SO low ). There maybe a project idea send in your file access logs and trust us its used for auto trimming a thinner puppy for all, maybe the ten or so active people left here really does not use 2/3rd of whats included anyway.

(...) But sadly I've not found a script/method to validate file permissions, to reset all system files back to correct permissions in the event of doing something silly like a recursive permissions change action (yep ... that's what I did). I ended up redoing from scratch ... newly install and all of the changes/updates ....etc.

Perhaps a new install should have a record made of all the system file permissions at the time kept back as a reference so at least a recursive change could be created to reset at least those files. Combined with adding to that record set when files were added/replaced.

???

Hi rufwoof.

I don't know about the other items in your question, but about the
permissions -- Can you not use something like:

Code:

cd /usr/bin
chmod -R -x *

for each main directory, to correct the situation?

I say "for each main directory" because I know from experience that your
Puppy will freeze badly if you try to do that from "/" (the absolute top of
your directory hierarchy). Tentative explanation: chmod doesn't like
changing the permission for itself, goes beserk and halts everything?

It's none of my business to recommend that you do anything, but:
it never hurts to do frequent backups of your pupsave file, and in this
particular case, just before you do this kind of major operation!

I don't know about the other items in your question, but about the
permissions -- Can you not use something like:

Code:

cd /usr/bin
chmod -R -x *

for each main directory, to correct the situation?

I say "for each main directory" because I know from experience that your
Puppy will freeze badly if you try to do that from "/" (the absolute top of
your directory hierarchy). Tentative explanation: chmod doesn't like
changing the permission for itself, goes beserk and halts everything?

It's none of my business to recommend that you do anything, but:
it never hurts to do frequent backups of your pupsave file, and in this
particular case, just before you do this kind of major operation!

The worst part about it was that this likely caused them all to be copied into his save file/partition. It may be better to iterate over the mounted sfs in /initrd/pup_ro* (or wherever it is?) and just remove the files from the save file/partition directly (not wrt '/' but /initrd/pup_rw) ... possibly omitting some directories where things were intentionally changed like /root (which should not be populated at all BTW - everything there is wrong and likely belongs in /etc somewhere)_________________Check out my github repositories. I may eventually get around to updating my blogspot.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum