Decreasing Disk Space?
-
I can only assume that it’s also being used for something else if 18GB magically appeared over night.
-
Temporarily it could be fixed by minimizing the reserved space on that partition/filesystem.
tune2fs -m 1 /dev/mapper/FogController-root
That will give you some of the space that’s “missing” between 880G and 926G. But you need to find the source of increasing usage, otherwise it will fill up further. Maybe something weird in /var/log?
That’s why one would use not only a single root filesystem.
-
@Wayne-Workman said in Decreasing Disk Space?:
du -h / | grep ‘[0-9.]+G’
Thanks again for the help. Here is the output in two screens.
This server is dedicated to only running our FOG application.
-
@Chuck2000 What’s the output of df -h /media
-
Here it is:
Thanks again.
-
@Chuck2000 So just a guess, but you usually have a USB stick connected?
Cause right now that’s whats eating up your space.
YOu might think about removing the files in the subdirectories please.
-
well, in the OP, the output of
df -h
showed that/media/usbdrive
is on it’s own partition already.It could be that
/dev/sdb
is failing to mount to/media/usbdrive
sometimes.And it looks like
/media/usbdrive
is used for image backups. If a backup was done without the drive being connected, then it would go to/
instead and fill it up.We can help you to do image backups using your network instead of a external drive, it’s quite easy to do. You don’t even need to worry about some external USB hdd working right or not.
-
I used umount to remove the USB backup drive and then deleted some more old images from the FOG server. I freed up about 4GB of disk space. I then used the reboot command. After rebooting, I can’t access via the web interface or putty SSH. However, I can ping the machine. When I try accessing with putty, the error is “Network error, connection refused” Hopefully there is an easy solution to this???
Plan B:
I just learned that we already have a newer FOG server built with no images on it. It is FOG version 1.2 running on Ubuntu 14. This is a virtual machine running on VMWare. It was built about a year ago with the intention of replacing our current FOG server. Our current FOG server is a physical machine.
However, when I powered it on and accessed the web interface, I got prompted to run the database schema installer / updater. When I ran it, I got a long list of Database SQL errors.
Can this be fixed? If so, I was wondering if I can transfer our existing images to this server. I have them on an external USB hard drive. I realize we would probably lose our existing client database, but we can accept that.
Plan
If this schema error can’t be fixed, then I guess I am going to have to do a new FOG install and transfer the images. Could I just delete the current FOG install and reinstall on the same VMWare Ubuntu 14 server? I really don’t want to also have to build a new Ubuntu server unless it is absolutely necessary.
I know that is a lot – thanks for the help. -
@Chuck2000 said in Decreasing Disk Space?:
Plan
If this schema error can’t be fixed, then I guess I am going to have to do a new FOG install and transfer the images. Could I just delete the current FOG install and reinstall on the same VMWare Ubuntu 14 server? I really don’t want to also have to build a new Ubuntu server unless it is absolutely necessary.
I know that is a lot – thanks for the help.I think it’s in your best interests to build a new server. Why? Even if the schema error could be fixed, you don’t really want to use 1.2.0 today. There is a very long list of reasons for not using 1.2.0 and to instead use FOG 1.3.0 Release Candidate with something newer than Ubuntu 14… Like Ubuntu 16. Why you are sweating this, I don’t know. This is a very simple process.
- Install Ubuntu 16.04 (Only use the very latest lts version of Ubuntu for FOG, which is currently 16.4). You can download Ubuntu 16.04 from here: https://www.ubuntu.com/download
- Access the terminal
- Become root with
sudo -i
- issue this “Mega Command” which will do everything necessary to completely setup a totally finished FOG 1.3.0 RC server:
apt-get update -y;apt-get upgrade -y;apt-get dist-upgrade -y;apt-get install git -y;git clone https://github.com/FOGProject/fogproject.git /root/fogproject;cd /root/fogproject/bin;./installfog.sh -y
- Change your existing DHCP option 066 to the new server’s IP address.
- Start using FOG to get work done.
Total time - maybe an hour. And that’s an hour of the machine’s time, not yours. You get to stay productive and go do something else while it’s going.
As far as the old server goes, it’d be nice if you could save the images. Sounds like you will need to be standing in front of it since SSH doesn’t work, and you could quite simply move all images to the new server via SCP.
From the old server:
scp -r /images/* username@x.x.x.x:/images/
Where x.x.x.x is the new server’s IP address and username is a valid username.
After completing this transfer, manually create each of the images using the correct settings (such as OS, resizable or not, correct image path which is case sensitive), and set these old images to use partimage instead of partclone and then you’re in business. -
OK - thank you. I didn’t know it was that easy. I will build a new server as you suggested. I will post an update when finished.
-
This thread has gone off topic and has been forked to here:
https://forums.fogproject.org/topic/9001/partimage-for-old-images -
This issue is resolved. I built a new server as you and Tom suggested. Thanks for the help.