Ubuntu 14 running out of space on /dev/sda1

I don't see the attached image, can you provide the result of mount command?

df -k
Fdisk -l
Or parted -l
Lvmdisksan


Raw partition if that is what you have are difficult to adjust as compared to lvm as an example.

Thank you for your responses.   The following is the output of lsblk.      @Arnold, can I run these commands on a SSH session, or do I need to boot with an ISO and perform those steps?    This server is in a data center, so it makes it more challenging.




NAME                                     MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda                                        8:0    0    50G  0 disk
├─sda1                                     8:1    0   243M  0 part /boot
├─sda2                                     8:2    0     1K  0 part
└─sda5                                     8:5    0  49.8G  0 part
  ├─UbuntuBaseTemplate--vg-root (dm-0)   252:0    0  48.7G  0 lvm  /
  └─UbuntuBaseTemplate--vg-swap_1 (dm-1) 252:1    0  1020M  0 lvm  [SWAP]
sr0                                       11:0    1  1024M  0 rom
Ubuntu-Space.png

Attached is the output of the df -k output. I managed to remove old kernels and now are down to 77% disk utlization. Howerver, it would be great to increase space on /dev/sda1 from /sda5 which has 50 Gigs.
df--k.png

/dev/sda1 is your boot it does not need more space.

Usually, the space on /dev/sda1 is managed as you have through removal of old kernels.

All you really need is the current kernel that you retain when applying updates/upgrades.
Once you confirm the update/upgrade is successful. The old kernel can be deleted.
If you are going through an upgrade, the old kernel would often not work with the newer OS version.


As to your questions, all the commands I listed are terminal, console command where graphics are not required.

Much depends on your dcomfort, need, using an X-window application on your local system can provide you with a graphical interface when needed through an SSh tunnel.


250MB is a bit skimpy on the /boot /dev/sda1 partition in future the /boot should be between 500MB to 1 GB.
In the future consider using raided volumes including for the /boot.

Something else is taking space on /boot.

Just checked a machine with 3x Kernels with 50% of same size /boot as your machine.

Check carefully for files to remove of /boot + you'll be fine.

@Arnold and @ David Favor.

Thank you for your input.   I personally would be okay with your suggestions, but the client could not install some packages for an Alert Logic appliance because sda1 was 100% capacity.  If I run sudo apt-get update, I'm sure I'll go to 100% utilization again, so I'm hoping to somehow add more space to avoid future issues.

I'm just afraid to do this via CLI from a remote machine. I've done this botting with an ISO on a physical machine.    So, If I can run those commands via the CLI on an SSH session, I'm perfectly fine. I just don't wish to have an un-bootable machine after the fact.

Thank you again for your feedback.  If you can just confirm I can run these remote, I'll get started right away.

"
df -k
Fdisk -l
Or parted -l
Lvmdisksan
"

@Venture_Solutions

1)
Whenever I face disk space issue, used to execute following command:

df -h

Select allOpen in new window

or bdf -h based on Operating systems.
2)
Assume that the disk space being full at /boot directory

sudo find /boot/ -type f | grep -E "\.tgz$|\.bz$|\.gz$"
[sudo] password for murugesandins:

Select allOpen in new window

Before removing the file:
a)
obtain the approval from supervisor(for following action) and save that in svn/git/TFS DB and SMTP
b)
take a backup of existing OS (using vmplayer/...)
c)
Be sure that you can re-create existing OS using the backup
After obtaining approval you can move those *.gz/*.zip/... files to a directory at other block

If any of the steps intermediately fails, stop proceeding the next text

>> Check carefully for files to remove of /boot + you'll be fine.
as per comment from David favor

Read the comments inside the code which I executed using vmplayer.exe

$ sudo ls -ltrd $(sudo find /boot/ -type f | grep -E "\.tgz$|\.bz$|\.gz$")
-rw-r--r-- 1 root root  55808 Mar 16  2003 /boot/grub/splash.xpm.gz
-rw-r--r-- 1 root root 112656 Apr  2  2004 /boot/symvers-2.6.18-194.el5.gz
-rw-r--r-- 1 root root 118919 Jun 29  2005 /boot/symvers-2.6.18-419.0.0.0.2.el5.gz
-rw-r--r-- 1 root root 118017 Jun 29  2006 /boot/symvers-2.6.18-419.0.0.0.2.el5xen.gz
$ # I am the approver here for my vmplayer and all OS here. I have backup at other two external hard disks.
$ # since backup was done when I re-installed windows during 2016.
$ sudo mv -i /boot/grub/splash.xpm.gz /boot/symvers-2.6.18-194.el5.gz /boot/symvers-2.6.18-419.0.0.0.2.el5.gz /boot/symvers-2.6.18-419.0.0.0.2.el5xen.gz ~root/svn/
$ sudo init 6
Connection to 123.456.78.910 closed by remote host.
Connection to 123.456.78.910 closed.

Select allOpen in new window

a)
123.456.78.910 => I have modified my IPv4 address to 123.456.78.910 => since not interested to publish my IPv4.
b)
2003 2004 2005 2006 => I have changed the years.
c)
I have used full path for
sudo
ls
find
grep
mv
d)
Other than above changes at output, I have not changed anything else.

After reboot it is working now.
I have also verified the original files bakup available at
~root/svn/ directory.

Tip: There are many ways to do live resize of data partitions.

Many times they fail.

When I have to do something like this, here's how I approach the problem.

1) I'd check /boot + fix the problem without doing a resize.

When /boot fills up, it's almost always a slightly broken /boot config. If you resize /boot, then the problem will persist + /boot will continue to fill, till problem reoccurs.

2) If I did have to resize /boot, say to run custom or debug Kernels, which were larger than initial planning suggested...

I'd make a full backup of all data, then do a fresh install, obliterating all data + partitioning, then restore backup data.

In other words, I avoid attempts to do realtime partition resizing, preferring to do this only as part of an install... because this approach works 100% of the time.

Aside: Ubuntu 14 (Trusty Tahr) reached EOL (End of Life) April of 2019, which means sites built on this OS version are either hackable or will be hackable, with no hope of a fix.

If you must run Trusty, as I do for many old projects, install a machine with latest Ubuntu LTS (V20 Fossa releasing in a few weeks), so you have a patched Kernel running latest fixes.

Then run LXD with a Trusty LXD container.

This way you can partition your Trusty projects from other projects, so one hacked Trusty project can never leak hacks across other projects.

Be sure to make full container backups each night, so when your Trusty project is hacked, you can just restore the container to the previous night's backup.

Once your Trusty project is hacked, be sure to keep the clean/unhacked backup available for restore, as once hacked a site will be continually hacked.

You can move space from one partition to another as follows (I do this) one directory (tree) at a time. The general idea is to use bind mounts, e.g. my /etc/fstab contains

/sdb4/projects        /projects        none        bind             0   0
/nvme0n1p2/home/dunc  /home/dunc       none        bind             0   0
/nvme0n1p2/usr/gz     /usr/gz          none        bind             0   0
/nvme0n1p2/usr/iso    /usr/iso         none        bind             0   0
/nvme0n1p2/usr/src    /usr/src         none        bind             0   0
/nvme0n1p7/opt        /opt             none        bind             0   0
/nvme0n1p7/tmp        /tmp             none        bind             0   0

Select allOpen in new window

Be sure not to bind-mount anything that is required by the boot process before fstab is read.

@Venture_Solutions

Proceed any one or all comment/comments
>> after
a. Informing supervisor about the steps to be followed
b. obtaining approved email(SMTP) from supervisor
c. backup of existing OS
d. have a sample/valid/... testing when recovering backup OS at other location/system
e. updates at svn/git/TFS
f. update at DB (SQL/*.csv/...)

Thank you all for your valuable input!