Making 2nd HD part of the primary filesystem.

All,

I'm running Kubutu 14.04 LTS on my server and have a 2nd 3TB hard drive installed. In my fstab file I have:

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda1 during installation
UUID=dbcfef7d-37d4-408e-8ea2-3c06bf3ae093       /        ext4    errors=remount-ro  0       1
# swap was on /dev/sda5 during installation
UUID=2cf62a67-06d8-42da-85c1-7e5469dfdd4d none           swap    sw                 0       0
/dev/sdb1                                       /mnt/3T  ext4    defaults           0       0

There is a way to add this 2nd HD seemlessly to the primary filesystem, but have forgotten the exact syntax to add it here. My primary HD is 80GB or 73.5 GB after boot and swap declarations.

I'm getting disk full errors, so need the 3TB in the primary to stop this.

Cheers!

TBNK

Are you using LVM2? If not, unfortunately the best you can do is mount the new drive at a point in the filesystem, say /home.

What is the output of

fdisk -l device

where device is your "primary" drive.

I noticed you have /dev/sdb1 in your fstab file with mount point /mnt/3T. Everything does look good and it should be mounted at /mnt/3T if this directory was created.
You can also configure it the way the designers tell you in the paragraph above of the configuration file, it's not very descriptive but just run command:

sudo blkid /dev/sdb1

The output should look similar to the example below and the colored section is the combination of digits you would put after: UUID=

/dev/nvme0n1p6: UUID="b1ae2552-d194-4ea1-a16a-e4f0c02d490f" TYPE="ext4" PARTLABEL="Debian" PARTUUID="5a879d6b-db09-3569-a004-6758534c0700"

Adding the drive this way will only give you a "DATA" drive, to use it for the directories in the / that are filling things up you would have to link those directories to the 3T drive.

There may be another underlying issue if 73.5 GB is not enough, unless it is normal for new data to continuously be created and stored, hard to say as the purpose of the server is not disclosed.

We just went through this in another thread recently, turned out the poster of that thread did not format the partition. Just figured I would mention this so this thread does not become as long as that other one. Ensure /dev/sdb1 partition exists and is formatted to ext4.

Originally Posted by TBotNik I'm running Kubutu 14.04 LTS on my server and have a 2nd 3TB hard drive installed. In my fstab file I have: # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # <file system> <mount point> <type> <options> <dump> <pass> # / was on /dev/sda1 during installation UUID=dbcfef7d-37d4-408e-8ea2-3c06bf3ae093 / ext4 errors=remount-ro 0 1 # swap was on /dev/sda5 during installation UUID=2cf62a67-06d8-42da-85c1-7e5469dfdd4d none swap sw 0 0 /dev/sdb1 /mnt/3T ext4 defaults 0 0 There is a way to add this 2nd HD seemlessly to the primary filesystem, but have forgotten the exact syntax to add it here. My primary HD is 80GB or 73.5 GB after boot and swap declarations. I'm getting disk full errors, so need the 3TB in the primary to stop this.

simplest solution (imo):
- be root in a non-graphical system (e.g. reboot into recovery)
- copy your home folder (completely with hidden files & correct permissions & recursively, i think 'cp -a' will do that) to that 3T drive.
- rename your current /home folder
- adjust your fstab to
a) use UUID please
b) maybe better that the drive name does not start with a number?
c) is mounted at /home

All,

The way you are answering is like I do not have the HD mounted. It's mounted, that's not the problem.

Problem:
When the secondary HDs mount they must be part of the "/" root filesystem. Can not be on another separate filesystem.

We used to do this all the time, when drives were smaller and much more expensive. I remember shelling down $500 for a 40GB drive and when we needed a seamless filesystem Linux would do this, but disks are so cheap now most start with large primary HDs, so wondering if this is a "lost skill". Back in the day, the "seamless filesystem" was the primary reason for using a Linux Server over a Windows server. Not having to find files on "Drives" and unending seamless HD expansion were built into original versions of Unix/Linux.

Anyway I also remember we did some tricks with symlinks, but not sure if we just mounted the new secondary, created our data there and then symlinked them back to the primary, but know we got it done, just forgotten how!

Cheers!

TBNK

All,

Help!!!!!

What ever is going on with dpkg, especially the *.deb for upgrading MySQL to 5.7, is toast and has locked me completely out of my machine, with "disk full" errors. /dev/sda1 is @ 99% per df -h and deletion of many *.part and *.deb files does not clear the disk full errors.

Can not login at all so all the apt-get cmds are not available, and only able to use recovery mode + networking (to put HD into r/w) and run:

find / -name *.ext

using *.part and *.deb to trying to delete downloaded large files. Do not know what file dpkg creates so can not delete it and attempt to fix the filesystem, using dpkg from the recovery mode, just pulls in this MySQL 5.7 config. The multiple unsuccessful attempts to install MySQL 5.7 have caused the disk full scenario.

Evidently both the wget downloads and the file(s) created by dpkg, are filling up the drive, but can not find any of the files with the above find cmd.

Not enough disk space to run any sophisticated cmds, just need to know whether my swap is also full, thus causing additional issues.

Cheers!

TBNK

All,

Tried using the HOWTO at:

https://ubuntuforums.org/showthread.php?t=1180100

using cmd:

dpkg-reconfigure -f mysql

get messages:

debconf: falling back to frontend: Noninteractive /usr/sbin/dpkg-reconfigure: please specify a package to reconfigure

Note:
Searching the computer in recovery mode only the "find" command is available for searching and "find" only searches the primary filesystem, and no extension filesystem, so can not ever search my 3T drive for anything.
The way I need the 3T to mount as part of the primary filesystem, "find" will see everything on the server.

Cheers!

TBNK

All,

Have deleted several directories, I found as duplicates, including a copy of my 14GB Dropbox directory and nothing changes per df -h where /dev/sda1 stays at 99% full regardless of what I delete. Does df -h have a refresh cmd?d

Cheers!

TBNK

Since by default 5% of an ext2/3/4 filesystem is reserved by root you need to delete 5% and get the used space below 95% before you will see the numbers changes. If any file deleted is still in use by the system or an application then the used space will not change until that file is closed.

You can use symlinks, bind mounts or move almost any directory to a new partition but unless your using RAID or LVM etc I do not know how to seamlessly add a secondary drive to your existing / partition. By using the find command you should be able to find the directories with the largest files.

Please post the output of "df -h", without any actual numbers to work off of we're just flying blind and can't really help you.

"Merging filesystems" typically means RAID or LVM, are you talking about one of those? If not then I don't know what you're referring to. You don't NEED to merge multiple partitions into a single filesystem to make use of the second drive though. You can very easily move your largest directories onto the other drive and symlink them back into place. The system will function exactly as it does now, nothing has to change in how you use it.

To find where the disk is going, open a terminal as root, go to "/", and run the following to find the largest directories:

du -shx * | sort -h

Go into the largest directory and run the same command again, keep tracing it down until you find whatever files are eating up your space.
If you can't boot into your system due to the full filesystem, then use another machine to create a bootable live USB of whatever Linux distro you feel like, boot into that, mount your root drive, and then use the steps above to identify and remove whatever files are eating up your space.

There is no question in my mind that you should always(!) use LVM, for precisely these reasons.

The usual operations – adding space, dealing with drives that have begun to make those dreaded "clicking sounds" and so-forth – become very, very easy. LVM elegantly separates the logical picture (as seen by the operating system and applications) from the physical one. And you don't even have to reboot the computer.

All,

After working through my other problems, it finally dawned on me that we set all the subsequent drives up, mounted then, moved all the file directories to them and then symlinked them back to the "/" file system, as symlink only keep an index of the files, so takes up little disk space but the symlink makes the directories appear as though part of the root filesystem.

When I'm finally back up, will do it that way and see how this goes.

Cheers!

TBNK

Gentlebeing ... if you are not now using LVM ... take the time now to switch to it!

There is simply no substitute for this vital system-management facility, and, IMHO, no valid excuse for not using it.