Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.) [SOLVED]

On 11/1/19 3:03 PM, home user wrote: * I did not forget your suggestion of re-partitioning to shift space from /home and using that for a new /var partition. Currently, I don't think any media I have has space for /home. And doing the re-partitioning would take more help from this list than

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.) [SOLVED]

Good afternoon, everyone. After wrestling this for 17 days, here's where things stand: --- -bash.9[~]: du -hx -d1 / 5.4G    /var 4.0K    /system-upgrade-root 4.0K    /srv 17G    /usr 16K    /lost+found 51M    /etc 4.0K    /sysroot 4.0K    /mnt 1.4G    /root 4.0K    /media 238M   

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

(replying to Ed) > Yes, make life easier on yourself and others.  I doubt > anyone would spend any time on an RFE of this sort. So, > just place this two line script in /etc/cron.weekly > #!/usr/bin/bash > find /var/cache/akmods/nvidia/ -type f -mtime +10 -exec rm -f {} \; > (etc) On my system,

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

On 10/31/19 11:37 PM, home user wrote: Any other suggestions Yes, make life easier on yourself and others.  I doubt anyone would spend any time on an RFE of this sort. So, just place this two line script in /etc/cron.weekly #!/usr/bin/bash find /var/cache/akmods/nvidia/ -type f -mtime +10

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

On Thu, 2019-10-31 at 09:37 -0600, home user wrote: > By the way, what does "RFE" stand for? Google: bugzill what does rfe stand for? "Request for Enhancement" asking to add more features to something. -- uname -rsvp Linux 3.10.0-1062.4.1.el7.x86_64 #1 SMP Fri Oct 18 17:15:30 UTC 2019

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

(me) > > How can this be automated such that each week, when > > I do my patches (dnf upgrade), those files are > > automatically deleted if the patches succeed?  Would > > this require enhancements to dnf? (Ed) > It has nothing to do with dnf.  Potentially you could file > a bugzilla with

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

(responding to Ed) > Why?  I said the *entire* /var/cache/system-upgrade/ > directory can be deleted. I said it is no longer used. I did not understand it that way.  My apologies. /var/cache/system-upgrade/ deleted. > Google is your friend. I've had better friends!  And many people would agree

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

On 10/27/19 8:43 AM, home user wrote: (responding to Ed) > > Question 1 > > (/var/cache/system-upgrade/updates/packages/ > That entire directory can be deleted.  It was used by fedup, > the forerunner to "dnf system-upgrade". No longer used, > no longer needed. I did "rm -rf

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

(responding to Ed) > > Question 1 > > (/var/cache/system-upgrade/updates/packages/ > That entire directory can be deleted.  It was used by fedup, > the forerunner to "dnf system-upgrade". No longer used, > no longer needed. I did "rm -rf /var/cache/system-upgrade/updates/packages/". -

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

On 10/27/19 2:49 AM, home user wrote: Question 1: /var/cache/system-upgrade/updates/packages/ takes up 1.6G and appears to be full of rpm's (1083 of them), each dated 2015 (various months).  I do not know the fine details of dnf and rpm.  Can I safely delete them, or might that break  future 

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

As of mid-day Saturday, Oct. 26, here is what '/' filesystem space use looks like on this work station: === bash.2[/]: df -hP Filesystem  Size  Used Avail Use% Mounted on tmpfs   7.8G  1.7M  7.8G   1% /run /dev/sda6    50G   24G   23G  52% / /dev/sda7   904G  7.6G 

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

As of mid-day Saturday, Oct. 26, here is what '/' filesystem space use looks like on this work station: === bash.2[/]: df -hP Filesystem  Size  Used Avail Use% Mounted on tmpfs   7.8G  1.7M  7.8G   1% /run /dev/sda6    50G   24G   23G  52% / /dev/sda7   904G  7.6G 

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

(replying to Ed and Samuel) (regarding /usr/bin/sh, /bin/sh, and bash being the same) ok.  Thank-you. line changed to "#!/usr/bin/bash". > This line is redundant. ... ok.  Thank-you. line deleted. > (when the script is run) Though the odds are very slim, I want to be sure the delete doesn't

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

On 10/25/19 7:56 PM, home user wrote: The script looks like this: - #!/usr/bin/sh # clean out files left behind by the compiling that follows patching or # updating the kernel and/or the driver for the nvidia graphics card. rm -rf /var/cache/akmods/nvidia/* exit $? This line is

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

On 10/26/19 10:56 AM, home user wrote: (responding to Ed) > The easiest way... done. The script looks like this: - #!/usr/bin/sh # clean out files left behind by the compiling that follows patching or # updating the kernel and/or the driver for the nvidia graphics card. rm -rf

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

(responding to Ed) > The easiest way... done. The script looks like this: - #!/usr/bin/sh # clean out files left behind by the compiling that follows patching or # updating the kernel and/or the driver for the nvidia graphics card. rm -rf /var/cache/akmods/nvidia/* exit $? # done! -

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

On 10/25/19 4:14 AM, home user wrote: The thing I'm now trying to do is automate the cleaning out of things left behind by akmod(?) after the weekly patch (dnf upgrade).  A cron job seems like the most natural way to do this.  Since the patches are weekly, I believe the cron job should be

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

The thing I'm now trying to do is automate the cleaning out of things left behind by akmod(?) after the weekly patch (dnf upgrade).  A cron job seems like the most natural way to do this.  Since the patches are weekly, I believe the cron job should be weekly, scheduled for a day and time when

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

On 23/10/2019 21:36, Joe Zeff wrote: On 10/23/2019 02:13 PM, home user wrote: installation was easy. usage in root was mostly easy; between 40 and 50 MB recovered. That's because you'd already cleaned up a lot of the cruft.  If you wait until just before your next upgrade, you may be

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

On 10/23/2019 02:13 PM, home user wrote: installation was easy. usage in root was mostly easy; between 40 and 50 MB recovered. That's because you'd already cleaned up a lot of the cruft. If you wait until just before your next upgrade, you may be surprised at how much you recover. I have

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

(responding to Joe) > ... bleachbit ... done. installation was easy. usage in root was mostly easy; between 40 and 50 MB recovered. Control over localizations was tedious.  Suggest either (better) a way to disable localization checks, or (not as good) a single check box equivalent to checking

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

(responding to Ed) > Yes, of course, but that *wasn't* the point. ... My apologies.  Now I see what you were saying. I worked for 17 years on the "AWIPS"(*) project, in which logging was split into different files based on date and application.  It was an excellent, easy to use (both in

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

On 10/23/19 12:55 AM, home user wrote: > My "work" system" ... I see this as individual preferences. Yes, of course, but that *wasn't* the point.  You listed how you use your system.  I was simply contrasting  my usage pattern and how much information is contained v.s. space taken As for

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

On 10/22/2019 11:18 AM, home user wrote: What are other list members' experiences with bleachbit run as root or a non-root admin. user?  Are the space gains worth the time and effort? Has it caused problems by deleting things that shouldn't be deleted, or changing things inappropriately?  Is

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

(addressed to everyone) (responding to Joe) > So run bleachbit with gksudo ... That way, you can clean up parts of your system > that your regular user can't write to. HTH, HAND. What are other list members' experiences with bleachbit run as root or a non-root admin. user?  Are the space

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

(replying to myself) > So after backing up "/etc/systemd/journald.conf", ... After those three edits, > I can save and reboot, or did I miss something? I did the back-up and the edits.  I noted current stats on '/', /var/, and /var/log/, re-booted, and looked again and the stats. No

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

On 10/22/19 9:50 AM, home user wrote: (responding to Samuel and Ed; regarding journald mamagement) Since: 1. I shut down every night, and power up every morning; 2, I patch once every week; 3. when I patch, the system keeps the last two patches; 4. half of my one 2TB hard drive "belongs" to

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

(responding to Samuel and Ed; regarding journald mamagement) Since: 1. I shut down every night, and power up every morning; 2, I patch once every week; 3. when I patch, the system keeps the last two patches; 4. half of my one 2TB hard drive "belongs" to windows-7; So I'm thinkin this would be

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

On Mon, 21 Oct 2019 at 00:32, home user wrote: > > The key to getting good answers is to ask good questions. > Apparently, I'm not quite asking "good questions" this weekend. > > I was looking for a more integrated view of journald so I could > differentiate the advice given in this thread, and

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

On 10/21/19 11:32 AM, home user wrote: > The key to getting good answers is to ask good questions. Apparently, I'm not quite asking "good questions" this weekend. I was looking for a more integrated view of journald so I could differentiate the advice given in this thread, and see how the two

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

On 10/20/19 8:32 PM, home user wrote: My first question: If I use journald.conf to, say (hypothetical values for now): * have the system start a new journald file each day, and * delete journald files once they're a month old, would I still need to do B above, or will A automatically cause the

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

> The key to getting good answers is to ask good questions. Apparently, I'm not quite asking "good questions" this weekend. I was looking for a more integrated view of journald so I could differentiate the advice given in this thread, and see how the two approaches provided in this thread

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.) (home user

On Sun, 2019-10-20 at 00:06 +, George R Goffe via users wrote: > > Hi, > > Just my 2 cents. > > first: I'm sure you remember that even if you find a huge file and remove it, > the space it occupies will not be available IF the file is still open. I had > a /var file system full some time

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

On 10/20/19 9:45 AM, home user wrote: Is there something more focused on the management and control aspects of this sub-system? Well, the management and control of the journal is defined in journald.conf. So, how about reading "man journald.conf"? -- The key to getting good answers is to

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

(responding to Patrick) > You mean journalctl: https://www.digitalocean.com/community/tutorials/how-to-use-journalctl-to... Thank-you. Is there something more focused on the

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.) (home user

Hi, Just my 2 cents. first: I'm sure you remember that even if you find a huge file and remove it, the space it occupies will not be available IF the file is still open. I had a /var file system full some time ago and it was /var/log/messages that was HUGE. Removing it didn't help until I

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

On Sat, 2019-10-19 at 12:40 -0600, home user wrote: > Now, I'd like to turn to the logs (journal). I've examined the Fedora > sys. admin. manual on this, and I've read the man pages suggested by > posters in this thread. What I believe would be useful to me now is a > good tutorial on

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

Now, I'd like to turn to the logs (journal).  I've examined the Fedora sys. admin. manual on this, and I've read the man pages suggested by posters in this thread.  What I believe would be useful to me now is a good tutorial on journal(d?).  Not a 5-credit PhD course, not a one-page brief

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

On 10/18/19 9:14 PM, home user wrote: -bash.14[/]: du -sh | grep G The grep is unnecessary here. You will only get the one line anyway (other than the errors). Also the result of this command is pretty much irrelevant anyway because it includes everything including /home. You can better

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

On 10/19/19 10:49 AM, home user wrote: Some of the links seem to point to somewhere under /.build-id/", but I'm suspicious that the process used above might be mis-leading us on this.  I don't see a ".build-id" under '/' on my system. FWIW, "locate" is your friend.  Just use: locate

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

(responding to Ed) > You only want to delete the links.  You don't want to delete > what the links are pointing to. > The "rm" will only remove the links. > Nothing under /var/cache/abrt-di is vital to the operation of the system. Just after sending my last post, basically the same thing

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

On 10/19/19 10:49 AM, home user wrote: So how do I safely get rid of everything under /var/cache/abrt-di/usr/, including what the 13800+ links are pointing to? You only want to delete the links.  You don't want to delete what the links are pointing to. The "rm" will only remove the links.

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

(responding to Ed) > From memory. > I recall they link places such as > /usr/include and others which would be needed > to properly generate a stack trace. Hmmm...  This gives me an idear.  Let me try something.  I'll vi the output from ls -alR | grep "^l" > output.txt I'll list my steps

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

On 10/19/19 4:00 AM, Samuel Sieb wrote: On 10/18/19 12:40 PM, home user wrote: It occurred to me overnight that the delete that I almost did would remove links, but probably not what they're pointing to.  There are 13800+ links there.  I don't know how much space the real files on the other

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

(responding to Samuel) > Where do they link to? I've been wondering about that too.  A bunch of places.  The output from ls -alR | grep "^l" is showing links as relative paths, not absolute paths.  And it's 13800+ lines!  How do get the output as absolute paths, sort it, and boil it way down?

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

(responding to Samuel) > I didn't see any timestamps for that data. Was any of it recent > or was it just all old junk that never got cleaned up before? > There was a mention in that bug that abrt will limit the amount of > storage it uses by cleaning up old data as it creates more. I looked at

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

On 10/18/19 12:40 PM, home user wrote: It occurred to me overnight that the delete that I almost did would remove links, but probably not what they're pointing to.  There are 13800+ links there.  I don't know how much space the real files on the other end of those links take up, and I haven't

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

A few times, I almost did the "rm -rf /var/cache/abrt-di/usr/". (Ed said) > I wouldn't delete the directory but all the contents below it. I'm glad I hesitated! It occurred to me overnight that the delete that I almost did would remove links, but probably not what they're pointing to.  There

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

On 10/18/19 12:21 PM, home user wrote: (responding to Samuel) https://bugzilla.redhat.com/show_bug.cgi?id=811978 Thank-you, Samuel.  I just added a comment to that bug saying that I too I experiencing problems, and referencing this thread. I didn't see any timestamps for that data. Was any

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

(responding to Samuel) https://bugzilla.redhat.com/show_bug.cgi?id=811978 Thank-you, Samuel.  I just added a comment to that bug saying that I too I experiencing problems, and referencing this thread. ___ users mailing list --

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

> I'm BA-A-A-a-a-ack! > > > Please hold off on discussion/suggestions about journal files and other > things until we get this > "/var/cache/abrt-di/usr/" done! > > thanks > Bill. "... until 'we' get this ..." ?! yup. I'm too searching for someone in "standby-mode" how is willing to manage

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

On 10/17/19 8:42 PM, home user wrote: (Ed and Samuel) > As noted by Samuel, I too don't have that directory. > Just delete it. ok.  But let's not do "half a job". There must be something more fundamental going on here.  I never knowingly or willfully did anything to create

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

On 10/18/19 11:42 AM, home user wrote: (Ed and Samuel) > As noted by Samuel, I too don't have that directory. > Just delete it. ok.  But let's not do "half a job". There must be something more fundamental going on here.  I never knowingly or willfully did anything to create

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

(Ed and Samuel) > As noted by Samuel, I too don't have that directory. > Just delete it. ok.  But let's not do "half a job". There must be something more fundamental going on here.  I never knowingly or willfully did anything to create "/var/cache/abrt-di/usr/" or anything under it, or

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

On 10/18/19 6:03 AM, home user wrote: Please hold off on discussion/suggestions about journal files and other things  until we get this "/var/cache/abrt-di/usr/" done! Those are just files needed it a debug is to be done and a BZ to be submitted. As noted by Samuel, I too don't have that

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

On 10/17/2019 04:03 PM, home user wrote: To answer Joe (about bleachbit), I did look at its wikipedia page quickly.  My impression is that it focuses on personal space (/home/...) rather than system space.  What was needed here was a huge amount system space.  I seriously doubt that bleachbit

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

I'm BA-A-A-a-a-ack! To answer Joe (about bleachbit), I did look at its wikipedia page quickly.  My impression is that it focuses on personal space (/home/...) rather than system space.  What was needed here was a huge amount system space.  I seriously doubt that bleachbit would have helped 

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

> On Wed, 2019-10-16 at 17:35 +, sixpack13 wrote: > > I wouldn't do that. At this time, /var/tmp is expected to be on > permanent storage, some things might expect data to remain available. > Some things might generate more temp files than your RAM (especially if > you burn DVDs or

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

On Wed, 2019-10-16 at 17:35 +, sixpack13 wrote: > if you want to have an automatical cleanage for /var/tmp: > = > 1. add the following line to your /etc/fstab > > "tmpfs /var/tmp tmpfsdefaults,nosuid,nodev,noexec,mode=1777 > 0 0" > > -

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

On 10/17/19 6:15 AM, home user wrote: I'm having to put this aside until tomorrow afternoon.  I have personal business and commitments this evening and tomorrow morning; I'll do my weekly incremental back-up; scans, and patches tomorrow midday.  (another working  lunch) Here's what's been 

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

On 10/16/2019 04:15 PM, home user wrote: I'm having to put this aside until tomorrow afternoon.  I have personal business and commitments this evening and tomorrow morning; I'll do my weekly incremental back-up; scans, and patches tomorrow midday. (another working lunch) Have you tried

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

I'm having to put this aside until tomorrow afternoon.  I have personal business and commitments this evening and tomorrow morning; I'll do my weekly incremental back-up; scans, and patches tomorrow midday.  (another working lunch) Here's what's been accomplished so far: ---

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

On 10/17/19 3:11 AM, Samuel Sieb wrote: On 10/16/19 10:51 AM,   sixpack13 wrote: On 10/16/19 8:33 AM,   sixpack13 wrote: journald is pretty good about cleaning up after itself. obviously NOT by an size of 4.5 GB  (not MB !) That depends on what you want.  I'm happy to have lots of logs,

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

okay, thanks for clarification ! ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

> (responding to sixpack13) ... > But I'm not sure I should do anything that affects current journal > files, and there are a few.  I looked at the man page. Maybe I'm > incorrectly understanding the --rotate, --update-catalog, and --sync, > but it looks like it will affect currently active log

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

On Wed, Oct 16, 2019 at 05:51:16PM -, sixpack13 wrote: > > journald is pretty good about cleaning up after itself. > obviously NOT by an size of 4.5 GB (not MB !) This is because the default is to base the limit on the size and free space on the filesystem used for the journal. This is

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

On 10/16/19 10:51 AM, sixpack13 wrote: On 10/16/19 8:33 AM, sixpack13 wrote: journald is pretty good about cleaning up after itself. obviously NOT by an size of 4.5 GB (not MB !) That depends on what you want. I'm happy to have lots of logs, I've run into situations where the log

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

(responding to Samuel) > No need. As you can see, most of it is really old. > You can delete everything in there except the systemd-private* ones. done. thanks, Bill. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

> On 10/16/19 8:33 AM, sixpack13 wrote: > > journald is pretty good about cleaning up after itself. obviously NOT by an size of 4.5 GB (not MB !) ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

(responding to sixpack13) > journal/ 4.5 GB 101 > I do clean up my /var/log/journal/ via following commands (maybe imperfect !): > sudo journalctl --flush --rotate; > sudo rm -rfv /var/log/journal/*/*@*; > sudo journalctl --update-catalog --sync; I agree that there's a lot there that can and

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

as I said just one comment before your's. it is save to do sudo rm -rf /var/tmp/* as you can see in /var/tmp/ are mostly old temporary files in: - they care "tmp" in it's name - are generated from akmod during compile of your module for your nvidia graphic card - the most current

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

On 10/16/19 8:33 AM, sixpack13 wrote: ... "https://paste.fedoraproject.org/paste/0itNgq0umG~nGgd92LZ~kQ;. journal/ 4.5 GB 101 I do clean up my /var/log/journal/ via following commands (maybe imperfect !): sudo journalctl --flush --rotate; sudo rm -rfv

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

On 10/16/19 9:36 AM, sixpack13 wrote: ... "https://paste.fedoraproject.org/paste/0itNgq0umG~nGgd92LZ~kQ;. /var/tmp/ 1.9 GB 1403 sudo rm -rf /var/tmp/* I would not recommend that. systemd services use that space for temp files. You're likely to cause a problem

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

On 10/16/19 9:54 AM, home user wrote: (responding to Samuel) > /var/cache/tmp has a lot of space. I don't even have that directory. What's in there. I have no such directory.  Do you mean "/var/tmp"? - bash.57[tmp]: pwd /var/tmp bash.58[tmp]: ls -la total 220 - I can fpaste an "ls

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

On 10/16/19 9:29 AM, home user wrote: (responding to Ed) > Since you're at F30 you should also have a /var/cache/PackageKit/30 directory structure > which is now being used. I don't have it.  This might relate to actions taken in my December 2018 thread "unwanted checks for updates".  I'd

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

(responding to Samuel) > The first big wins are to delete the 28 and 29 from under PackageKit done. > You don't show what's really under /var/cache/yum, but anything under there can be deleted. bash.49[yum]: ls -la - total 16 drwxr-xr-x.  3 root root 4096 May 21 10:44 . drwxr-xr-x. 26

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

... > "https://paste.fedoraproject.org/paste/0itNgq0umG~nGgd92LZ~kQ;. > /var/tmp/ 1.9 GB 1403 sudo rm -rf /var/tmp/* ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

(responding to Ed) > So, the 28 is no longer being used and can be removed. Done. > Since you're at F30 you should also have a /var/cache/PackageKit/30 directory structure > which is now being used. I don't have it.  This might relate to actions taken in my December 2018 thread "unwanted

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

... > "https://paste.fedoraproject.org/paste/0itNgq0umG~nGgd92LZ~kQ;. > journal/ 4.5 GB 101 I do clean up my /var/log/journal/ via following commands (maybe imperfect !): sudo journalctl --flush --rotate; sudo rm -rfv /var/log/journal/*/*@*; sudo journalctl --update-catalog

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

On 10/16/19 1:15 AM, Patrick O'Callaghan wrote: On Tue, 2019-10-15 at 19:06 -0700, ToddAndMargo via users wrote: How they get baobab out of "Gnome Disk Analyzer" is beyond me. Whimsical names are Linux (and especially GNU) tradition. The baobab is a tree with a complex root system, so it's

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

On Tue, 2019-10-15 at 19:06 -0700, ToddAndMargo via users wrote: > How they get baobab out of "Gnome Disk Analyzer" is beyond me. Whimsical names are Linux (and especially GNU) tradition. The baobab is a tree with a complex root system, so it's appropriate in a way.

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

On 10/15/19 7:13 PM, home user wrote: (replying to Samuel) > What I would recommend... Well, I simply did "su -", and then "baobab".  Unfortunately, I can't directly put that into a post in this list, and fpaste doesn't take images (screen captures).  So I manually typed up the data in a text

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

On 10/16/19 11:58 AM, Tim via users wrote: On Wed, 2019-10-16 at 07:50 +0800, Ed Greshko wrote: You can delete them all, especially the log files. Didn't we used to have log rotate daemon to manage that kind of thing for us? Oh, follow-up. If one wants to file a RFE bugzilla to

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

On 10/16/19 11:58 AM, Tim via users wrote: On Wed, 2019-10-16 at 07:50 +0800, Ed Greshko wrote: You can delete them all, especially the log files. Didn't we used to have log rotate daemon to manage that kind of thing for us? Well, yes.  One could add a file in /etc/logrotate.d with the

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

On Wed, 2019-10-16 at 07:50 +0800, Ed Greshko wrote: > You can delete them all, especially the log files. Didn't we used to have log rotate daemon to manage that kind of thing for us? -- uname -rsvp Linux 3.10.0-1062.1.2.el7.x86_64 #1 SMP Mon Sep 30 14:19:46 UTC 2019 x86_64 Boilerplate:

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

On 10/16/19 10:13 AM, home user wrote: Well, I simply did "su -", and then "baobab".  Unfortunately, I can't directly put that into a post in this list, and fpaste doesn't take images (screen captures).  So I manually typed up the data in a text file.  I added output from "du -h | sort -hr |

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

(replying to Samuel) > What I would recommend... Well, I simply did "su -", and then "baobab".  Unfortunately, I can't directly put that into a post in this list, and fpaste doesn't take images (screen captures).  So I manually typed up the data in a text file.  I added output from "du -h |

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

On 10/15/19 3:45 PM, Samuel Sieb wrote: I would recommend is just using the Gnome disk analyzer Hi Samuel, I just tried it out. It has a petty interface. I have been using xdiskusage, which has a miserable interface, but it works over "ssh -X". # dnf install baobab How they get baobab

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

On 10/16/19 8:38 AM, home user wrote: (responding to Ed) > Actually, none. ... You can delete them all, especially the log files. ... Thank-you, Ed. Done.  I'll put new statistics in a response to Samuel. How can this be automated such that each week, when I do my patches (dnf upgrade), those

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

(responding to Ed) > Actually, none. ... You can delete them all, especially the log files. ... Thank-you, Ed. Done.  I'll put new statistics in a response to Samuel. How can this be automated such that each week, when I do my patches (dnf upgrade), those files are automatically deleted if

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

On 10/16/19 7:25 AM, home user wrote: (picking up from Ed's suggestion in the old thread) > For example, if you use the akmod package for nVidia drivers > they are automatically rebuilt on each new kernel.  But the > directory where the rpm's are kept (/var/cache/akmods/nvidia) > isn't clean up

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

(picking up from Ed's suggestion in the old thread) > For example, if you use the akmod package for nVidia drivers > they are automatically rebuilt on each new kernel.  But the > directory where the rpm's are kept (/var/cache/akmods/nvidia) > isn't clean up and will grow with time. Ed appears to

Re: too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

On 10/15/19 3:13 PM, home user wrote: -bash.14[/]: du -hx -d1 / 23G    /var 4.0K    /system-upgrade-root 4.0K    /srv 17G    /usr 16K    /lost+found 51M    /etc 4.0K    /sysroot 4.0K    /mnt 1.4G    /root 4.0K    /media 238M    /opt 4.0K    /.cache 41G    / starting questions ==

too-nearly-full filesystem '/'. (was upgrade problem: space on '/' filesystem.)

(Fedora-30; x86-64; personal workstation) This problem goes back to last Thursday, so a brief review might be good. brief background Last Thursday, I tried to upgrade from Fedora-29 to Fedora-30.  dnf complained it didn't have enough space in the '/' filesystem.  List members