​

My Ubantu virtual machine couldn’t get up after I had a meal. Then after many inquiries, a wide collection of the world’s remedies, and finally found that the allocation of hardware space is insufficient. The phenomenon is as follows:

​

By looking at the

root@ubantu:/snap# df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            1.9G     0  1.9G   0% /dev
tmpfs           391M  2.1M  389M   1% /run
/dev/sda1        20G   18G  623M  97% /
tmpfs           2.0G     0  2.0G   0% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           2.0G     0  2.0G   0% /sys/fs/cgroup
/dev/loop0      384K  384K     0 100% /snap/gnome-characters/570
/dev/loop1      2.3M  2.3M     0 100% /snap/gnome-system-monitor/148
/dev/loop3      384K  384K     0 100% /snap/gnome-characters/550
/dev/loop2       56M   56M     0 100% /snap/core18/1944
/dev/loop4       65M   65M     0 100% /snap/gtk-common-themes/1514
/dev/loop6       99M   99M     0 100% /snap/core/10823
/dev/loop8      1.0M  1.0M     0 100% /snap/gnome-logs/100
/dev/loop5      218M  218M     0 100% /snap/gnome-3-34-1804/60
/dev/loop7      274M  274M     0 100% /snap/nextcloud/26119
/dev/loop10     2.5M  2.5M     0 100% /snap/gnome-calculator/826
/dev/loop9       56M   56M     0 100% /snap/core18/1988
/dev/loop11     2.5M  2.5M     0 100% /snap/gnome-calculator/884
/dev/loop13     640K  640K     0 100% /snap/gnome-logs/103
/dev/loop17     2.3M  2.3M     0 100% /snap/gnome-system-monitor/157
/dev/loop12     273M  273M     0 100% /snap/nextcloud/26049
/dev/loop14      63M   63M     0 100% /snap/gtk-common-themes/1506
/dev/loop15     100M  100M     0 100% /snap/core/10859
/dev/loop16     219M  219M     0 100% /snap/gnome-3-34-1804/66
tmpfs           391M   28K  391M   1% /run/user/121
tmpfs           391M   36K  391M   1% /run/user/1000
/dev/sr0        1.9G  1.9G     0 100% /media/toney/Ubuntu 18.04.2 LTS amd64
Copy the code

By looking at the disk usage, you can see that /dev/sda1 is almost completely used (97% because I deleted some files, otherwise 99%). By further positioning du, you can see that snap takes up a lot of space:

root@ubantu:/var# du -sh./* backups 158M./cache 4.0K./crash 2.8G./lib 4.0K./local 0./lock 805M./log 4.0k /metrics 4.0k./opt 0./run 6.9g./snap 52K./spool 52K./ TMPCopy the code

My disk is 20GB in total, and it takes 7 GB by itself, so I’ll just uninstall it

 sudo apt autoremove --purge snapd
Copy the code

After a period of time, the uninstallation is complete, and then check the disk usage:

root@ubantu:/# df -h Filesystem Size Used Avail Use% Mounted on udev 1.9g 0 1.9g 0% /dev TMPFS 391M 2.1m 389M 1% /run /dev/sda1 20G 7.6g 11G 41% / TMPFS 2.0g 0 2.0g 0% /dev/shm TMPFS 5.0m 4.0k 5.0m 1% /run/lock TMPFS 2.0g 0 2.0g 0% /sys/fs/cgroup TMPFS 391M 28K 391M 1% /run/user/121 TMPFS 391M 36K 391M 1% /run/user/1000 /dev/sr0 1.9g 1.9g 0 100% / media/toney/Ubuntu 18.04.2 LTS amd64Copy the code

Disk usage went straight from 97 percent to 41 percent. Since then, Mom doesn’t have to worry about Snap taking up disk space.

However, it should be noted that if the disk cannot meet the requirements and you do not want to recreate the VM to build various environments, it is better to use the capacity expansion technology to add another hard disk for the VM. In the future, new files or unimportant files can be put into the new disk.

In addition to uninstalling Snap, I also added a disk:

​

​