I've got my changes made and tested, and I want to verify that I haven't got anything installed that isn't really needed. I tried lots of things in my efforts, and want to verify that I haven't left any unneeded code on the system.
Some things have been installed or removed via synaptic where possible, and others by hand where there was no package available, and I'd like to get a good list and check it before I create an ISO for my other systems.
BTW, there were surprisingly few changes needed.
I've attached a pic of the desktop, showing the conky and theme changes.
PS: I understand, no need to view, its just a matter of if sufficient space is available or not
topic title: [SOLVED]How to view the persistance files?
14 posts
• Page 1 of 1
-
Posts: 604
- Joined: 27 Feb 2009
#1
Last edited by thriftee on 09 Nov 2016, 07:27, edited 3 times in total.
-
Posts: 1,445
- Joined: 09 Feb 2012
#2
Viewing"the persistence files" won't be enlightening in regard to removing unneeded files which were preinstalled
but, in response to your title question... You can browse"files installed/updated during persisted sessions" via
sudo spacefm /live/aufs-ram/upper/
"want to verify that I haven't left any unneeded code on the system"
Is this want due to limited resources, or just pursuit of efficiency?
What was your starting point? antiX full?
If so, and you've retained LibreOffice, you can trim quite a bit by paring the preinstalled LibreOffice"examples" resource files.
In any event, I'll suggest:
run sudo dpkg-reconfigure locales and remove localizations you won't use,
then followup by installing debian package"localepurge"
and further followup by running"sudo bleachbit" and removing localization files.
If you install the tiny (cli/ncurses) utility"ncdu" (available as a debian package), you can use that to quickly browse/walk your filesystem directory tree and locate storage space hogs. I bet you'll find"plenty" of deletion candidates that way way ~~ e.g. multi Mb imagefiles (wallpapers) you'll never use, gobs of 256x256 icon imagefiles you'd probably never miss (I surely don't), along with 40Mb+ of locale-related files that bleachbit misses.
Beyond the above steps, how far down the rabbit hole would you like to chase? You could remove unneeded (by your system) kernel drivers, install a"lighter" kernel, pare down the content of /usr/share/doc/, uninstall non-essential desktop theme files n iconsets...
I don't publish it b/c it would be detrimental for anyone to blindly delete every listed item.
Besides, beyond the steps mentioned in this post, chasing the longtail deletion candidates provides"greatly diminishing returns".
but, in response to your title question... You can browse"files installed/updated during persisted sessions" via
sudo spacefm /live/aufs-ram/upper/
"want to verify that I haven't left any unneeded code on the system"
Is this want due to limited resources, or just pursuit of efficiency?
What was your starting point? antiX full?
If so, and you've retained LibreOffice, you can trim quite a bit by paring the preinstalled LibreOffice"examples" resource files.
In any event, I'll suggest:
run sudo dpkg-reconfigure locales and remove localizations you won't use,
then followup by installing debian package"localepurge"
and further followup by running"sudo bleachbit" and removing localization files.
If you install the tiny (cli/ncurses) utility"ncdu" (available as a debian package), you can use that to quickly browse/walk your filesystem directory tree and locate storage space hogs. I bet you'll find"plenty" of deletion candidates that way way ~~ e.g. multi Mb imagefiles (wallpapers) you'll never use, gobs of 256x256 icon imagefiles you'd probably never miss (I surely don't), along with 40Mb+ of locale-related files that bleachbit misses.
Beyond the above steps, how far down the rabbit hole would you like to chase? You could remove unneeded (by your system) kernel drivers, install a"lighter" kernel, pare down the content of /usr/share/doc/, uninstall non-essential desktop theme files n iconsets...
my accumulated multi-distro list of cleanup candidate target paths is 500+ lines long.I'd like to get a good list and check it
I don't publish it b/c it would be detrimental for anyone to blindly delete every listed item.
Besides, beyond the steps mentioned in this post, chasing the longtail deletion candidates provides"greatly diminishing returns".
-
Posts: 604
- Joined: 27 Feb 2009
#3
Thanks for the reply. I am running AntiX16 386 Full,, with full persistence, I like Icewm and prefer Spacefm to Rox filer. I really didn't need to install many packages, programs or files to get it setup the way I like it.
I added one Icewm theme, which I them modified, and removed the rest. I removed the unused GTK themes, too, but some specific ones are required by programs, too bad not all the same. My conky required a couple small utiitirs, and I added a small game. I added commonly used program icons to the tray to make them easy to run when needed.
I may add Openbox as long as I have it, anyway, but if I do, I'll probably tweak it back so it fits in seamlrssly like the other WM's.
All machines but one have either DVD or bootable USB, and that one only has a CD Rom drive and slow non-bootable USB, so I'm trying to keep it fitting on one CD.
IMO, maybe the locales desired should be specified at install, and then only the selected ones would actually get installed, but that wouldn't affect the size on CD.
Thanks for the other ideas. Maybe the libreoffice examples could be in a separate non-default package?
The biggest problem I was trying to address was that when I'd install one package, it might automatically install 3 more it depends on, and when you remove the one, the others remain. Do you know a way to easily identify those?
I added one Icewm theme, which I them modified, and removed the rest. I removed the unused GTK themes, too, but some specific ones are required by programs, too bad not all the same. My conky required a couple small utiitirs, and I added a small game. I added commonly used program icons to the tray to make them easy to run when needed.
I may add Openbox as long as I have it, anyway, but if I do, I'll probably tweak it back so it fits in seamlrssly like the other WM's.
All machines but one have either DVD or bootable USB, and that one only has a CD Rom drive and slow non-bootable USB, so I'm trying to keep it fitting on one CD.
IMO, maybe the locales desired should be specified at install, and then only the selected ones would actually get installed, but that wouldn't affect the size on CD.
Thanks for the other ideas. Maybe the libreoffice examples could be in a separate non-default package?
The biggest problem I was trying to address was that when I'd install one package, it might automatically install 3 more it depends on, and when you remove the one, the others remain. Do you know a way to easily identify those?
-
Posts: 1,445
- Joined: 09 Feb 2012
#4
I too with the LibreOffice examples resided in a separate, optional, package but seldom install LO, period.
Its packaging is an upstream decision. You could file a bug/request at
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=libreoffice"
linktext was:"https://bugs.debian.org/cgi-bin/pkgrepo ... ibreoffice"
====================================
Some are truly needed on your system; the utility may just be reporting those which no other installed debian package depends on.
For theme packages, iconset packages, etc. that are stated as dependencies, you can usually figure out which (often as few as ONE) specific icon(s) a program actually uses and, by referring to the"installed files" listed in synaptic, hunt down and manually delete all the unneeded files. Package manager will still"recognize" any such gutted packages as being installed. Caveat here is that all the stuff you delete manually will wind up being reinstalled if you ever upgrade the associated package. That's where (why) the looooong list (part of a"cleanup" shell script) mentioned in earlier post comes into play ~~ to perform periodic checking/cleaning, prior to running live-remaster.
Its packaging is an upstream decision. You could file a bug/request at
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=libreoffice"
linktext was:"https://bugs.debian.org/cgi-bin/pkgrepo ... ibreoffice"
====================================
Various prepackaged utilities dedicated to this task are available: apt-rdepends (cli),"deborphan" (cli),"gtkorphan" (gui). Take care when removing packages they identify as"orphans", though.The biggest problem I was trying to address was that when I'd install one package, it might automatically install 3 more it depends on,
and when you remove the one, the others remain. Do you know a way to easily identify those?
Some are truly needed on your system; the utility may just be reporting those which no other installed debian package depends on.
For theme packages, iconset packages, etc. that are stated as dependencies, you can usually figure out which (often as few as ONE) specific icon(s) a program actually uses and, by referring to the"installed files" listed in synaptic, hunt down and manually delete all the unneeded files. Package manager will still"recognize" any such gutted packages as being installed. Caveat here is that all the stuff you delete manually will wind up being reinstalled if you ever upgrade the associated package. That's where (why) the looooong list (part of a"cleanup" shell script) mentioned in earlier post comes into play ~~ to perform periodic checking/cleaning, prior to running live-remaster.
-
anticapitalista
Posts: 5,955
- Site Admin
- Joined: 11 Sep 2007
#5
re - locales on live cd. We want to support as many languages as possible on our live system so people can run live in their native language.
-
Posts: 604
- Joined: 27 Feb 2009
#6
Makes sense, Anti.
I see deborphan is on the system, so I ran it and one library I suspected came up as well as a couple others I don't recall seeing.
I see deborphan is on the system, so I ran it and one library I suspected came up as well as a couple others I don't recall seeing.
-
Posts: 604
- Joined: 27 Feb 2009
#7
BTW, skidoo, thanks for ncdu. Its very small and makes it easy to find the space hogs.
Now, how can I tell when the persistence files are running out of space BEFORE I crash and burn, LOL?
Thanks for any suggestions...
Now, how can I tell when the persistence files are running out of space BEFORE I crash and burn, LOL?
Thanks for any suggestions...
-
Posts: 1,445
- Joined: 09 Feb 2012
#8
here's what works for me (in terms of keeping track of"how much space left"):
I use dynamic root persistence, with"semi-automatic" save mode.
At any time, on-demand, can visit terminal prompt and type"persist-save".
GUI shows how much space used, how much needed etc.
You can click"No" to exit after reading the dialog; IOW, you're not forced to actually perform a save operation.
I use dynamic root persistence, with"semi-automatic" save mode.
At any time, on-demand, can visit terminal prompt and type"persist-save".
GUI shows how much space used, how much needed etc.
You can click"No" to exit after reading the dialog; IOW, you're not forced to actually perform a save operation.
-
Posts: 1,445
- Joined: 09 Feb 2012
#9
from terminal prompt
sudo spacefm /live/aufs-ram/upper
will enable you to browse the realtime content of the upper overlayfs layer.
What you see (t)here is whatall, minus anything enumerated within /usr/local/share/excludes/live-remaster-exclude.list
will be stored to rootfs if/when you perform persist-save.
The current content of /live/aufs-ram/upper is comprised of files loaded from rootfs (in my case) during boot plus files written during the current session.
sudo spacefm /live/aufs-ram/upper
will enable you to browse the realtime content of the upper overlayfs layer.
What you see (t)here is whatall, minus anything enumerated within /usr/local/share/excludes/live-remaster-exclude.list
will be stored to rootfs if/when you perform persist-save.
The current content of /live/aufs-ram/upper is comprised of files loaded from rootfs (in my case) during boot plus files written during the current session.
-
Posts: 604
- Joined: 27 Feb 2009
#10
Skidoo, thanks for a couple of great posts here. Hopefully that gives me what I need to figure it out. I think I want to add a monitor to my conky for them if I can figure out how...
-
Posts: 604
- Joined: 27 Feb 2009
#11
I took persist-save and modified it and called it persist-check to check for space, and instead of using 10%, I used 15%, figuring that I could pop up a message that point to avoid running out of space.
I used gparted to move the system to a 32gb flashdrive with an 8gb partition for the OS instead of 5, and used that to test my initial code to make sure it doesn't do anything real bad.
I'll have to try to learn more of the language to get it to pop up an error if its running low, and then incorporate that into my conky.
I posted the hacked code, but took it out since I'm rolling with it at this point.
I used gparted to move the system to a 32gb flashdrive with an 8gb partition for the OS instead of 5, and used that to test my initial code to make sure it doesn't do anything real bad.
I'll have to try to learn more of the language to get it to pop up an error if its running low, and then incorporate that into my conky.
I posted the hacked code, but took it out since I'm rolling with it at this point.
-
Posts: 604
- Joined: 27 Feb 2009
#12
Its a very tough language. I can't even get it to print the values of the variables to be able to figure out what is what. I'm ok as long as I have some documentation and some examples, but to be honest, the syntax makes no sense because I don't know the purpose of things, so can't even tweak it successfully. I found a bash tutorial, but it looks like it will take weeks just to understand the print lines. I was hoping to get it to print the values of each variable, but its a herculean task if you can't guess the syntax.
Code: Select all
bg_info_box -o"$PULSATE" \
"$TITLE" \
"" \
"$(gt"Checking for existing files and")" \
"$(gt"Checking if there is enough room ...")" \
excludes="$(rootfs_excludes $AUFS_RAM_MP)"
exclude_size="$(du_size $excludes)"
pdev_total=$(all_space $PERSIST_MP)
pdev_avail=$(free_space $PERSIST_MP)
rootfs_file_size=$(du_size $(readlink -f $PERSIST_FILE))
aufsrw_used=$(du_size $AUFS_RAM_MP)
rootfs_used=$(du_size $ROOTFS_MP)
rootfs_full=$(all_space $ROOTFS_MP)
# Reduce available size by 15% for a 5% extra safety margin and because
# the du and df commands give different sizes.
safe_full=$(( $rootfs_full * 90 / 100 ))
need_size=$(( $aufsrw_used - $exclude_size ))
xfer_size=$(( $need_size - $rootfs_used))
["$xfer_size" -lt"15" ] && xfer_size="?"
main_text=(
######## HOW DO I PRINT THE VALUE OF $ROOTFS_MP HERE? If someone could just tell where where to find the answer to that, I could figure out a lot from there...
"$(fmt_size"reported rootfs space" $rootfs_full)"
"$(fmt_size"total rootfs space" $safe_full)"
"$(fmt_size"used rootfs space" $rootfs_used)"
"$(fmt_size"excluded file size" $exclude_size)"
"$(fmt_size"required rootfs space" $need_size)"
"$(fmt_size"approx. transfer size" $xfer_size)"
""
"$(pf"%12s: %s" "`gt"persist device"`""[f]$PERSIST_DEV[/]")"
"$(pf"%12s: %s" "`gt"mounted at"`" "[f]$PERSIST_MP[/]")"
""
"$(fmt_size"persist device total" $pdev_total)"
"$(fmt_size"persist device free" $pdev_avail)"
)
for t in"${main_text[@]}"; do
vmsg"$t"
done
kill_bg_info_box
["$rootfs_full" -lt"$SAFETY_MARGIN" ] && \
error_box_pf"Available space, %s, is smaller than the margin of %s." \
"[n]$rootfs_full[/]""[n]$SAFETY_MARGIN[/]"
["$safe_full" -lt"$need_size" ] && \
error_box_pf"Insufficient space. Have: %s. Need: %s.""[n]$safe_full[/]""[n]$need_size[/]"
-
Posts: 1,445
- Joined: 09 Feb 2012
#13
Granted, it's very difficult to figure which end's up. Most of what you're seeing in the code, those are varnames
(their values populated at runtime and many of 'em concatenated via $() shell var expansion)
and
the apparent"commands" aren't part of any stock language ~~ they are named functions, defined yonder in sourced files
( e.g. /usr/local/lib/antiX/antiX-common.sh )
Things get even fuzzier when the antix scripts roll custom-named yad functions into the mix.
printf $ROOTFS_MP
to echo the value(s)
or you could (best way to learn/understand what's going on, IMO) skim through various sourced files to see where vars n paths are defined
OR
take a shortcut. During live session, inspect the contents of /live/config/initrd.out (the sibling files in that directory are interesting also)
FWIW, I backed away (backed down?) from the prospect of adding that to conky because i couldn't decide
"how full is too full?"
"should I specify du --apparent-size or...?"
Whatever threshold, the calculation(s) seems fuzzy to the point of meaningless-ness
so I'm content to just call up the existing persist-save dialog on-demand and glance at its"numbers".
Wait, didn't I send you a PM about this?
Hmm, I found the screencap that I thought I'd embedded into a PM, but find no record in PM Sent Items.
Anyhow, my point here is that a for-conky script could, for most of the values, just parse the output of the"du" command.
The persist-save script var $DU_EXCLUDES is really the only wildcard (over time, its value does vary wildly)
but i'd be reluctant to poll/calculate that more often than every 15min or so.
(their values populated at runtime and many of 'em concatenated via $() shell var expansion)
and
the apparent"commands" aren't part of any stock language ~~ they are named functions, defined yonder in sourced files
( e.g. /usr/local/lib/antiX/antiX-common.sh )
Things get even fuzzier when the antix scripts roll custom-named yad functions into the mix.
you can add lines likeHOW DO I PRINT THE VALUE OF $ROOTFS_MP HERE? If someone could just tell where where to find the answer to that, I could figure out a lot from there...
printf $ROOTFS_MP
to echo the value(s)
or you could (best way to learn/understand what's going on, IMO) skim through various sourced files to see where vars n paths are defined
OR
take a shortcut. During live session, inspect the contents of /live/config/initrd.out (the sibling files in that directory are interesting also)
FWIW, I backed away (backed down?) from the prospect of adding that to conky because i couldn't decide
"how full is too full?"
"should I specify du --apparent-size or...?"
Whatever threshold, the calculation(s) seems fuzzy to the point of meaningless-ness
so I'm content to just call up the existing persist-save dialog on-demand and glance at its"numbers".
Wait, didn't I send you a PM about this?
Hmm, I found the screencap that I thought I'd embedded into a PM, but find no record in PM Sent Items.
Anyhow, my point here is that a for-conky script could, for most of the values, just parse the output of the"du" command.
The persist-save script var $DU_EXCLUDES is really the only wildcard (over time, its value does vary wildly)
but i'd be reluctant to poll/calculate that more often than every 15min or so.
-
Posts: 604
- Joined: 27 Feb 2009
#14
Thanks much, skidoo, the how to print was what I didn't understand. Actually, theres a lot more there I don't understand, but thanks to your post I should be able to figure out what I need to for my conky.. I run old and slow machines intentionally sometimes just to make it easy to notice when I create something inefficient, so hopefully I can find a way to make it work better than crashing and burning because I'm not noticing when space is getting tight.