[PLUG] Ubuntu Mate 18.04 Root full...

[Chuck Hast]

Folks.
I went to do an update when it tried to upgrade things the whole thing
abended
with a batch of lines indicating that "root was almost full". I went to
look at it and
found the the directory had to be accessed as administrator, when I looked
into it
I did not see anything of large size. The root directory is 9.1G in size,
if I look at
it with gpartd it is shown as almost full. But I cannot find the offending
file(s).

I did a google on root full and it's variants (I have only seen this one on
Mate 18.04,
on 16.04 it never showed up). I am trying to figure out how to recover from
the bad
update as it will not even boot now.

One other thing which maybe related to this, the last log files are from
May?!?!

[Bill Barry]

Post by Chuck Hast
Folks.
I went to do an update when it tried to upgrade things the whole thing
abended
with a batch of lines indicating that "root was almost full". I went to
look at it and
found the the directory had to be accessed as administrator, when I looked
into it
I did not see anything of large size. The root directory is 9.1G in size,
if I look at
it with gpartd it is shown as almost full. But I cannot find the offending
file(s).
I did a google on root full and it's variants (I have only seen this one on
Mate 18.04,
on 16.04 it never showed up). I am trying to figure out how to recover from
the bad
update as it will not even boot now.
One other thing which maybe related to this, the last log files are from
May?!?!
apt-get purge

might clean some unneeded packages out.

Bill Barry

[Nat Taylor]

cd /
du . | sort -n

Post by Chuck Hast

Post by Chuck Hast
Folks.
I went to do an update when it tried to upgrade things the whole thing
abended
with a batch of lines indicating that "root was almost full". I went to
look at it and
found the the directory had to be accessed as administrator, when I

looked

Post by Chuck Hast
into it
I did not see anything of large size. The root directory is 9.1G in size,
if I look at
it with gpartd it is shown as almost full. But I cannot find the

offending

Post by Chuck Hast
file(s).
I did a google on root full and it's variants (I have only seen this one

on

Post by Chuck Hast
Mate 18.04,
on 16.04 it never showed up). I am trying to figure out how to recover

from

Post by Chuck Hast
the bad
update as it will not even boot now.
One other thing which maybe related to this, the last log files are from
May?!?!
apt-get purge

might clean some unneeded packages out.
Bill Barry
_______________________________________________
PLUG mailing list
http://lists.pdxlinux.org/mailman/listinfo/plug

[Chuck Hast]

I went in and was able to boot to the previous image. The recovery offered
to remove all
unneeded files, then did the update. I was able to restart it. For
some reason it reported
that root was full, but (I double checked this) it was saying "root". There
is a "root " directory
in the boot directory, it is normally only accessed by root I do a chmod to
it to get into it, then
I change it back once done. There is not much in there. So seems the real
issue is boot.

I have purged out all old images, but seems that boot should not come near
filling up a
9.1G directory, at least to me. I see a lot of stuff but not sure what. I
think I am going to
increase the size of boot so that this doesn't happen again again. I
generally try to keep no
more than 2 older kernels.

Post by Chuck Hast

Post by Chuck Hast
Folks.
I went to do an update when it tried to upgrade things the whole thing
abended
with a batch of lines indicating that "root was almost full". I went to
look at it and
found the the directory had to be accessed as administrator, when I

looked

Post by Chuck Hast
into it
I did not see anything of large size. The root directory is 9.1G in size,
if I look at
it with gpartd it is shown as almost full. But I cannot find the

offending

Post by Chuck Hast
file(s).
I did a google on root full and it's variants (I have only seen this one

on

Post by Chuck Hast
Mate 18.04,
on 16.04 it never showed up). I am trying to figure out how to recover

from

Post by Chuck Hast
the bad
update as it will not even boot now.
One other thing which maybe related to this, the last log files are from
May?!?!
apt-get purge

might clean some unneeded packages out.
Bill Barry
_______________________________________________
PLUG mailing list
http://lists.pdxlinux.org/mailman/listinfo/plug

[Bill Barry]

Post by Chuck Hast
I went in and was able to boot to the previous image. The recovery offered
to remove all
unneeded files, then did the update. I was able to restart it. For
some reason it reported
that root was full, but (I double checked this) it was saying "root". There
is a "root " directory
in the boot directory, it is normally only accessed by root I do a chmod to
it to get into it, then
I change it back once done. There is not much in there. So seems the real
issue is boot.
I have purged out all old images, but seems that boot should not come near
filling up a
9.1G directory, at least to me. I see a lot of stuff but not sure what. I
think I am going to
increase the size of boot so that this doesn't happen again again. I
generally try to keep no
more than 2 older kernels.
Only partitions get full, not directories. Is /boot in a separate

partition than / ? If not then check your partition structure and see which
partition is full and clean it out or make it bigger.

Bill

[Larry Brigman]

Use 'df' to see what partitions are in use and percentage.

Post by Chuck Hast

Post by Chuck Hast
I went in and was able to boot to the previous image. The recovery

offered

Post by Chuck Hast
to remove all
unneeded files, then did the update. I was able to restart it. For
some reason it reported
that root was full, but (I double checked this) it was saying "root".

There

Post by Chuck Hast
is a "root " directory
in the boot directory, it is normally only accessed by root I do a chmod

to

Post by Chuck Hast
it to get into it, then
I change it back once done. There is not much in there. So seems the real
issue is boot.
I have purged out all old images, but seems that boot should not come

near

Post by Chuck Hast
filling up a
9.1G directory, at least to me. I see a lot of stuff but not sure what. I
think I am going to
increase the size of boot so that this doesn't happen again again. I
generally try to keep no
more than 2 older kernels.
Only partitions get full, not directories. Is /boot in a separate

partition than / ? If not then check your partition structure and see which
partition is full and clean it out or make it bigger.
Bill
_______________________________________________
PLUG mailing list
http://lists.pdxlinux.org/mailman/listinfo/plug

[Chuck Hast]

Well, doing a df I see that / is the 9.1G partition and the other one is
/home.

Prior to cleaning, the partition was 9.05G full, after doing the cleanup it
is now down to 8.7G.
so I have got to see what all is in it. Or I will have to make it bigger. I
have a boat load of empty
space on the HD so I can shrink home a bit and give it some more space, but
if it is just going
to eat that up with some blackhole files I need to find out what they are
and see what can be
trimmed.
/ is /dev/sda1
/home is /dev/sda5

Here is what df returns
***@kp4djt64:~$ df
Filesystem 1K-blocks Used Available Use%
Mounted on
udev 10193624 0 10193624 0% /dev
tmpfs 2044984 1468 2043516 1% /run
/dev/sda1 9649432 8647828 491716 95% /
tmpfs 10224912 41984 10182928 1%
/dev/shm
tmpfs 5120 8 5112 1%
/run/lock
tmpfs 10224912 0 10224912 0%
/sys/fs/cgroup
/dev/loop0 89472 89472 0 100%
/snap/ubuntu-mate-welcome/217
/dev/loop1 89984 89984 0 100%
/snap/core/5742
/dev/loop2 89216 89216 0 100%
/snap/ubuntu-mate-welcome/199
/dev/loop3 7808 7808 0 100%
/snap/pulsemixer/8
/dev/loop5 73472 73472 0 100%
/snap/software-boutique/31
/dev/loop4 8192 8192 0 100%
/snap/pulsemixer/23
/dev/loop6 89984 89984 0 100%
/snap/core/5662
/dev/loop7 89984 89984 0 100%
/snap/core/5548
/dev/loop8 89472 89472 0 100%
/snap/ubuntu-mate-welcome/208
/dev/sda5 462268272 231803916 206912664 53% /home
tmpfs 2044980 44 2044936 1%
/run/user/1000
/dev/sdb2 483946 245149 213812 54%
/media/kp4djt/172b795b-0a64-4265-a747-c5d65c6f606d
/dev/mapper/ubuntu--mate--vg-root 952137676 255183348 648565416 29%
/media/kp4djt/9b4c4135-80c2-42c3-a2ac-8376e6964e7a

Post by Larry Brigman
Use 'df' to see what partitions are in use and percentage.

Post by Chuck Hast

Post by Chuck Hast
I went in and was able to boot to the previous image. The recovery

offered

Post by Chuck Hast
to remove all
unneeded files, then did the update. I was able to restart it. For
some reason it reported
that root was full, but (I double checked this) it was saying "root".

There

Post by Chuck Hast
is a "root " directory
in the boot directory, it is normally only accessed by root I do a

chmod

Post by Chuck Hast
to

Post by Chuck Hast
it to get into it, then
I change it back once done. There is not much in there. So seems the

real

Post by Chuck Hast

Post by Chuck Hast
issue is boot.
I have purged out all old images, but seems that boot should not come

near

Post by Chuck Hast
filling up a
9.1G directory, at least to me. I see a lot of stuff but not sure

what. I

Post by Chuck Hast

Post by Chuck Hast
think I am going to
increase the size of boot so that this doesn't happen again again. I
generally try to keep no
more than 2 older kernels.
Only partitions get full, not directories. Is /boot in a separate

partition than / ? If not then check your partition structure and see

which

Post by Chuck Hast
partition is full and clean it out or make it bigger.
Bill
_______________________________________________
PLUG mailing list
http://lists.pdxlinux.org/mailman/listinfo/plug

_______________________________________________
PLUG mailing list
http://lists.pdxlinux.org/mailman/listinfo/plug

[King Beowulf]

Post by Chuck Hast
Well, doing a df I see that / is the 9.1G partition and the other one is
/home.
Prior to cleaning, the partition was 9.05G full, after doing the cleanup it
is now down to 8.7G.
so I have got to see what all is in it. Or I will have to make it bigger. I
have a boat load of empty
space on the HD so I can shrink home a bit and give it some more space, but
if it is just going
to eat that up with some blackhole files I need to find out what they are
and see what can be
trimmed.
/ is /dev/sda1
/home is /dev/sda5
Here is what df returns
Filesystem 1K-blocks Used Available Use%
Mounted on
udev 10193624 0 10193624 0% /dev
tmpfs 2044984 1468 2043516 1% /run
/dev/sda1 9649432 8647828 491716 95% /
...snip...

Where is '/tmp' and '/var'? On '/' which is '/dev/sda1'? If this is the
case, your root partition is way too small. You might just have a boat
load of temporary and log files. Also, package managers take up a bunch
of space so you should check there as well.

Consider also that when a distro claims "Minimum of X GB of Disk Space
to install" that is wishful thinking in the real world. You really need
to set aside at least 2X GB for any additional packages, logs, and temp
files.

-Ed

[Nat Taylor]

if you type
du / | sort -n

it will tell you the size of all the files and folders underneath /
(Everything!), and pipe it to the sort program, which will sort by size
when you give it the -n flag

you will need to wait a while for the operation to complete, and it won't
look into protected directories unless you run as root.

Post by Chuck Hast

Post by Chuck Hast
Well, doing a df I see that / is the 9.1G partition and the other one is
/home.
Prior to cleaning, the partition was 9.05G full, after doing the cleanup

it

Post by Chuck Hast
is now down to 8.7G.
so I have got to see what all is in it. Or I will have to make it

bigger. I

Post by Chuck Hast
have a boat load of empty
space on the HD so I can shrink home a bit and give it some more space,

but

Post by Chuck Hast
if it is just going
to eat that up with some blackhole files I need to find out what they are
and see what can be
trimmed.
/ is /dev/sda1
/home is /dev/sda5
Here is what df returns
Filesystem 1K-blocks Used Available Use%
Mounted on
udev 10193624 0 10193624 0% /dev
tmpfs 2044984 1468 2043516 1% /run
/dev/sda1 9649432 8647828 491716 95% /
...snip...

Where is '/tmp' and '/var'? On '/' which is '/dev/sda1'? If this is the
case, your root partition is way too small. You might just have a boat
load of temporary and log files. Also, package managers take up a bunch
of space so you should check there as well.
Consider also that when a distro claims "Minimum of X GB of Disk Space
to install" that is wishful thinking in the real world. You really need
to set aside at least 2X GB for any additional packages, logs, and temp
files.
-Ed
_______________________________________________
PLUG mailing list
http://lists.pdxlinux.org/mailman/listinfo/plug

[Rich Shepard]

Post by Nat Taylor
if you type
du / | sort -n

And, if you append the -sh options to the disk usage command the results
will be a summary for each section (e.g., directory) and in human-readable
format.

A second pass within a large directory, without the '-s' option will show
contents in human-readable format.

Rich

[Chuck Hast]

Select morsels of good data, thanks to you all. I went in and looked at the
9.1G partition,
it has /tmp and /var in there so yes those have a bunch of log files and
whatnot in there.

Now I will just re-size the thing when I get home (I am on the road in a
hotel tonight). I am
going to have to look hard at how these things get setup, I recall now that
when I did the new
disk I just told it to create two partitions
/
and
/home
I should have remembered that and gone in and fixed it when I got the time.
I let the auto
setup thingy do it's thing because I needed to get back up, but I should
have as soon as I
had the time gone in and done some work on it beyond moving the old home
directory's
to the new disk.

Anyhow a big thank you, and I am all ears if there is anything to add to
it.

Post by Rich Shepard

Post by Nat Taylor
if you type
du / | sort -n

And, if you append the -sh options to the disk usage command the results
will be a summary for each section (e.g., directory) and in human-readable
format.
A second pass within a large directory, without the '-s' option will show
contents in human-readable format.
Rich
_______________________________________________
PLUG mailing list
http://lists.pdxlinux.org/mailman/listinfo/plug

[Larry Brigman]

'fsresize' is your friend after you change your partition sizes.

Post by Chuck Hast
Select morsels of good data, thanks to you all. I went in and looked at the
9.1G partition,
it has /tmp and /var in there so yes those have a bunch of log files and
whatnot in there.
Now I will just re-size the thing when I get home (I am on the road in a
hotel tonight). I am
going to have to look hard at how these things get setup, I recall now that
when I did the new
disk I just told it to create two partitions
/
and
/home
I should have remembered that and gone in and fixed it when I got the time.
I let the auto
setup thingy do it's thing because I needed to get back up, but I should
have as soon as I
had the time gone in and done some work on it beyond moving the old home
directory's
to the new disk.
Anyhow a big thank you, and I am all ears if there is anything to add to
it.

Post by Rich Shepard

Post by Nat Taylor
if you type
du / | sort -n

And, if you append the -sh options to the disk usage command the

results

Post by Rich Shepard
will be a summary for each section (e.g., directory) and in

human-readable

Post by Rich Shepard
format.
A second pass within a large directory, without the '-s' option will show
contents in human-readable format.
Rich
_______________________________________________
PLUG mailing list
http://lists.pdxlinux.org/mailman/listinfo/plug

--
Chuck Hast -- KP4DJT --
I can do all things through Christ which strengtheneth me.
Ph 4:13 KJV
Todo lo puedo en Cristo que me fortalece.
Fil 4:13 RVR1960
_______________________________________________
PLUG mailing list
http://lists.pdxlinux.org/mailman/listinfo/plug