[youssefbasha]

Hello, iam facing this problem while trying to update and upgrade my Ubuntu 16.04
E: Failed to fetch https://download.docker.com/linux/ubuntu...4/Packages  Could not open file /var/lib/apt/lists/partial/download.docker.com_linux_ubuntu_dists_xenial_edge_binary-amd64_Packages - open (28: No space left on device)
W: Some index files failed to download. They have been ignored, or old ones used instead.
E: Couldn't create temporary file to work with /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_xenial_InRelease - mkstemp (28: No space left on device)
E: The package lists or status file could not be parsed or opened.
root@vps4:~# sudo apt-get upgrade
Reading package lists... Error!
E: Couldn't create temporary file to work with /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_xenial_InRelease - mkstemp (28: No space left on device)
E: The package lists or status file could not be parsed or opened.
root@vps4:~#
I have space.. 
8.12 GB of 200 GB Used / 191.88 GB Free
Please help me

[Littlemaster]

I think the below listed topics will help you out.
https://ubuntuforums.org/showthread.php?t=2177876
https://ubuntuforums.org/showthread.php?t=2210977

[Mashiro]

@Littlemaster

OP has a OpenVZ VPS and thus he cannot have the same issues described in the topics you linked to. OpenVZ containers have no own kernel and therefore also no real boot partition where the kernel files could be stored to be filled up.

Mind the path in the error messages. It is not even the boot partition with the kernel files that is the issue in this case. It is the /var folder in the OpenVZ root filesystem. That's a major failure on some side.


@youssefbasha

Just because the control panel of your VPS says you have over 100 GB free disk space it doesn't mean you really have it! You're running on a OpenVZ VPS that gets no real reports from the host OS about real disk usage on the node.

What does it mean for you? The host node could be full while your VPSs only uses a small bit of space of your allowance. OpenVZ allows overselling without limits on CPU, RAM, disk space and network. So if the host node disk is full your VPS cannot really see this.

What happens? Despite your VPS showing free disk space you don't really have any free disk space left. Thus your updates, installations and so on will fail.


Another sign of a full host node disk is when you have a high usage percentage of disk space in "df -h" output even though you only used a small bit.

e.g: You have a 100 GB disk. You used 10 GB (10%) of it really. You run a report with df -h and it says the following:
Used: 10 GB (99%)
Free: 90 GB (1%)
Total: 100 GB

In the example above the host node disk is so full that nothing fits into it anymore and your free 90 GB become absolutely useless because you cannot use them.

Welcome to the world of massively overselling providers, bad performance, downtime and a lot of fun.

[deanhills]

@"Hidden Refuge".  Didn't know this - wow! 

@youssefbasha In addition to HR's comment that is worth checking up on I checked for a tutorial how to upgrade to Ubuntu 16.4 and this paragraph from Dibital Ocean is worth noting - it's always better to install an upgrade of an OS from scratch rather than upgrading it, and if one upgrades it it is better to test it first in a staging environment before doing it on the VPS.  The tutorial below by digital ocean for how to upgrade to Ubuntu 16.4 is really great and worth checking out:

Potential Pitfalls
Although many systems can be upgraded in place without incident, it is often safer and more predictable to migrate to a major new release by installing the distribution from scratch, configuring services with careful testing along the way, and migrating application or user data as a separate step.

You should never upgrade a production system without first testing all of your deployed software and services against the upgrade in a staging environment. Keep in mind that libraries, languages, and system services may have changed substantially. In Ubuntu 16.04, important changes since the preceding LTS release include a transition to the systemd init system in place of Upstart, an emphasis on Python 3 support, and PHP 7 in place of PHP 5.

Source: https://www.digitalocean.com/community/t...-16-04-lts

[Mashiro]

@deanhills

Usually apt-get update && apt-get upgrade don't perform major version upgrades of the OS. These two commands refresh the local package database to see whether updates are available and if updates are available the packages affected are then updated to the new available versions.

In order to perform a major upgrade you'd need to do a little more work than these two commands. You need to update the sources in /etc/apt/source.list to the one from the release you want to upgrade to. And then run apt-get update && apt-get dist-upgrade to perform a "distribution upgrade".

There is also another trick that however may not always work as intended. When you update sources.list to the new version and run apt-get update && apt-get upgrade you will be able to simply update your packages to the version from the newer release of Ubuntu without a major distribution upgrade. This may however not always work due to compatibility and it isn't safe! Why? It would also attempt to upgrade some system packages that are vital but this will mostly break during such updates and the whole OS would collapse.

You probably knew that already though .


Long story short: I guess OP was just performing a normal update of packages instead of what you thought could be a distribution upgrade to a higher version. That said distribution upgrades on OpenVZ are possible. I could upgrade Debian 7 to Debian 8 without issues but Debian 8 to Debian 9 unfortunately didn't work 100%. Never tried Ubuntu.

[youssefbasha]

root@vps4:~# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/ploop53480p1 197G 8.3G 179G 5% /
tmpfs 32G 0 32G 0% /sys/fs/cgroup
devtmpfs 32G 0 32G 0% /dev
tmpfs 32G 0 32G 0% /dev/shm
tmpfs 32G 9.3M 32G 1% /run
tmpfs 32G 16K 32G 1% /run/lock
none 32G 0 32G 0% /run/shm
tmpfs 615M 0 615M 0% /run/user/0
root@vps4:~# df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/ploop53480p1 13107200 208208 12898992 2% /
tmpfs 8213156 10 8213146 1% /sys/fs/cgroup
devtmpfs 8213156 61 8213095 1% /dev
tmpfs 8213156 1 8213155 1% /dev/shm
tmpfs 8213156 248 8212908 1% /run
tmpfs 8213156 15 8213141 1% /run/lock
none 8213156 1 8213155 1% /run/shm
tmpfs 786432 4 786428 1% /run/user/0
root@vps4:~# df -ih
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/ploop53480p1 13M 204K 13M 2% /
tmpfs 7.9M 10 7.9M 1% /sys/fs/cgroup
devtmpfs 7.9M 61 7.9M 1% /dev
tmpfs 7.9M 1 7.9M 1% /dev/shm
tmpfs 7.9M 248 7.9M 1% /run
tmpfs 7.9M 15 7.9M 1% /run/lock
none 7.9M 1 7.9M 1% /run/shm
tmpfs 768K 4 768K 1% /run/user/0
root@vps4:~#

---

root@vps4:~# du -h --max-depth=1 | sort -hr
669M .
200M ./Python-3.6.0
176M ./.local
124M ./parallels
44M ./.cache
25M ./ioncube
11M ./.npm
864K ./2ndB
488K ./OpenDPY
16K ./.gdrive
16K ./.config
16K ./backups
12K ./DS
8.0K ./.nano
8.0K ./.autoinstaller
root@vps4:~#

---

root@vps4:~# dpkg -l | grep linux-image
root@vps4:~# ls -la /boot
total 8
drwxr-xr-x 2 root root 4096 Nov 26 2016 .
drwxr-xr-x 24 root root 4096 Jun 18 03:37 ..
root@vps4:~#

[Mashiro]

Alright. So it looks like the issue with disk space I described is not at fault here because the stats of df output do look absolutely normally and show no sign of a full host node disk as it is known to happen in OpenVZ.

inode count also looks good. ploop filesystem gives you a bit of a more real filesystem than the old OpenVZ simfs filesystem. A more isolated filesystem with more beyond it than a folder on the host node.

That's really strange then. I have to admit that I've never seen this error beforehand. The things I would generally check and look at to pinpoint the issue all look fine.


Docker... do you have second level quota enabled? The error might not even come directly from the update but rather from a Docker package during the update. Docker is a container virtualization much like OpenVZ but with prepackged systems and other goodies. It may need second level quota for the filesystem of the Docker containers.

[youssefbasha]

then what shall i do? even if i restarted my vps it wont start again, it was down for 3 days..

[Mashiro]

Oh. Why didn't you mention this before? There might just simply be a issue with your VPS that has somehow damaged it. I would open a support thread here and ask for the staff to ask the provider for support to resolve this.

Provide as much information as possible as such as the results that you posted here. The exact error message, df outputs and etc. So that the provider can see that there is something wrong even though it looks all fine inside the VPS.

[AmirGT]

then what shall i do? even if i restarted my vps it wont start again, it was down for 3 days..

Why don't you try to backup the important things to another VPS using scp and reinstall the server?
Guide: https://unix.stackexchange.com/questions...-using-ssh