问题
显然我的根分区上的磁盘空间不足。在安装我的操作系统（虚拟机上的 openSUSE Leap 15）时，我选择了默认分区。现在我收到警告/错误“文件系统根目录”磁盘空间不足。当我启动系统时它会警告我，当我尝试编译大型项目时它会抛出错误。
分析
我们来检查一下存储情况：
报告文件系统磁盘空间使用情况：
$ df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 13G 0 13G 0% /dev
tmpfs 13G 34M 13G 1% /dev/shm
tmpfs 13G 82M 13G 1% /run
tmpfs 13G 0 13G 0% /sys/fs/cgroup
/dev/sda2 40G 38G 2.2G 95% /
/dev/sda2 40G 38G 2.2G 95% /root
/dev/sda2 40G 38G 2.2G 95% /boot/grub2/i386-pc
/dev/sda3 204G 165G 40G 81% /home
/dev/sda2 40G 38G 2.2G 95% /boot/grub2/x86_64-efi
/dev/sda1 500M 5.0M 495M 1% /boot/efi
/dev/sda2 40G 38G 2.2G 95% /usr/local
/dev/sda2 40G 38G 2.2G 95% /srv
/dev/sda2 40G 38G 2.2G 95% /opt
/dev/sda2 40G 38G 2.2G 95% /.snapshots
/dev/sda2 40G 38G 2.2G 95% /tmp
/dev/sda2 40G 38G 2.2G 95% /var
tmpfs 2.6G 20K 2.6G 1% /run/user/462
tmpfs 2.6G 48K 2.6G 1% /run/user/1000
估计文件空间使用情况：
$ sudo du -hsx /* | sort -rh | head -n 40
[sudo] password for root:
du: cannot access '/proc/8809/task/8809/fd/4': No such file or directory
du: cannot access '/proc/8809/task/8809/fdinfo/4': No such file or directory
du: cannot access '/proc/8809/fd/4': No such file or directory
du: cannot access '/proc/8809/fdinfo/4': No such file or directory
51G /home
5.5G /usr
972M /opt
894M /var
792M /lib
63M /boot
38M /tmp
24M /etc
18M /run
11M /sbin
11M /lib64
2.1M /bin
320K /root
0 /sys
0 /srv
0 /selinux
0 /proc
0 /mnt
0 /dev
$ sudo du -hsx /.snapshots
2.2M /.snapshots
$ sudo du -hs /.snapshots
129G /.snapshots
按照@Kamil Maciorowsk 的建议列出快照：
$ sudo snapper list
Type | # | Pre # | Date | User | Cleanup | Description | Userdata
-------+-----+-------+----------------------------------+------+---------+-----------------------+--------------
single | 0 | | | root | | current |
single | 1 | | Tue 02 Oct 2018 02:42:20 PM CEST | root | | first root filesystem |
pre | 74 | | Mon 08 Oct 2018 03:25:32 PM CEST | root | number | zypp(zypper) | important=yes
post | 75 | 74 | Mon 08 Oct 2018 03:27:17 PM CEST | root | number | | important=yes
pre | 82 | | Tue 16 Oct 2018 09:11:33 AM CEST | root | number | zypp(zypper) | important=yes
post | 83 | 82 | Tue 16 Oct 2018 09:12:04 AM CEST | root | number | | important=yes
pre | 108 | | Thu 01 Nov 2018 01:25:41 PM CET | root | number | zypp(zypper) | important=yes
post | 109 | 108 | Thu 01 Nov 2018 01:27:12 PM CET | root | number | | important=yes
pre | 122 | | Thu 08 Nov 2018 09:26:09 AM CET | root | number | zypp(zypper) | important=yes
post | 123 | 122 | Thu 08 Nov 2018 09:27:40 AM CET | root | number | | important=yes
pre | 128 | | Mon 12 Nov 2018 08:40:03 AM CET | root | number | zypp(zypper) | important=yes
post | 129 | 128 | Mon 12 Nov 2018 08:41:36 AM CET | root | number | | important=yes
pre | 144 | | Mon 19 Nov 2018 09:52:15 AM CET | root | number | zypp(zypper) | important=no
post | 145 | 144 | Mon 19 Nov 2018 09:54:33 AM CET | root | number | | important=no
pre | 146 | | Wed 21 Nov 2018 11:07:33 AM CET | root | number | zypp(zypper) | important=no
post | 147 | 146 | Wed 21 Nov 2018 11:07:56 AM CET | root | number | | important=no
pre | 148 | | Thu 22 Nov 2018 09:19:51 AM CET | root | number | zypp(zypper) | important=no
post | 149 | 148 | Thu 22 Nov 2018 09:19:54 AM CET | root | number | | important=no
pre | 150 | | Mon 26 Nov 2018 09:12:02 AM CET | root | number | zypp(zypper) | important=no
post | 151 | 150 | Mon 26 Nov 2018 09:12:19 AM CET | root | number | | important=no
pre | 152 | | Thu 29 Nov 2018 09:34:37 AM CET | root | number | zypp(zypper) | important=no
post | 153 | 152 | Thu 29 Nov 2018 09:35:22 AM CET | root | number | | important=no
我也听说过旧的未使用的内核，因此检查了一下并发现了这一点：
$ ls -la /lib/modules
total 0
drwxr-xr-x 1 root root 108 Nov 8 09:29 .
drwxr-xr-x 1 root root 78 Oct 4 16:13 ..
drwxr-xr-x 1 root root 354 Oct 16 09:11 4.12.14-lp150.12.22-default
drwxr-xr-x 1 root root 354 Nov 8 09:26 4.12.14-lp150.12.25-default
解决方案的想法：
- 调整根分区的大小。（给根分区再多 10 GB 就更好了）
- 删除旧内核版本并希望我不会破坏任何东西并且释放的 245 MB 现在就足够了。
我非常赞成给 root 更多的空间，但不知道该怎么做，或者是否应该这么做。您建议什么解决方案？我该怎么做？
答案1
/dev/sda2挂载到不同的挂载点（你应该有不同的内容）让我相信你正在使用 Btrfs。你还挂载了，/.snapshots这表明存在鲷鱼. 很有可能/.snapshots占用了大部分已用空间。
请注意，您的分析du -hsx /*甚至没有/.snapshots考虑到，因为*glob 不会扩展到以 开头的名称.。
我没有使用过 Snapper。我怀疑里面有 Btrfs 子卷（快照）/.snapshots。该命令du -hsx /.snapshots甚至可能0因为-x使用的选项而返回。另一方面，可能会返回一个巨大的值。它可能比的大小（即）du -hs /.snapshots大得多，因为您可能有多个共享磁盘空间的快照（这是 Btrfs 的工作方式），仍然会将它们视为单独的文件系统。/dev/sda240GiBdu
要进一步分析，您需要 Btrfs 专用工具和/或 Snapper 工具。我对 Btrfs 有一些经验，但对 Snapper 则不然。我无法判断您是否可以通过手动破坏 Snapper 创建的快照来混淆它，这可能是可能的；但我确信您无法通过使用 Snapper 来破坏 Btrfs。因此，安全的方法是使用 Snapper 提供的任何工具来处理这种情况，而不是直接使用 Btrfs 工具。
已经提到的教程给我们一些关于你可以做什么的提示：
列出默认配置（根）的所有快照
snapper list删除快照
删除默认（根）配置的第 65 个快照：
snapper delete 65
但是也：
自动快照清理机制
为了防止磁盘空间被占满，Snapper 会定期清理快照。默认情况下，此周期 = 1 天。
自动快照清理任务可以通过两种方式管理：
- cron 调度程序（
/etc/cron.daily/suse.de-snapper）。- systemd 定时器调度程序（
snapper-cleanup.timer和snapper-cleanup.servicesystemd 单元）。默认情况下使用 cron 机制。
这个清理机制可能出了问题？
正如我所说，我没有使用 Snapper 的经验，所以我无法为您提供更多帮助。但是，如果我是对的，现在您知道要调查什么了。总结一下：
- 您完全错过了
/.snapshots目录，很可能它占用了大部分使用的空间； - Btrfs 快照可能涉及；
- Snapper 可能也参与其中。
答案2
首先要备份所有重要信息。如果继续这样做，可能会造成数据丢失。以下是一些选项：
购买新的 USB SATA 硬盘。将 USB SATA 硬盘与机箱中的旧硬盘交换。将 Linux 重新安装到新的 SATA 硬盘上。每当您需要访问旧文件时，插入 USB 硬盘即可。
如果您已经使用 LVM 进行分区（SuSE 可能没有），那么看看您是否可以扩展（
lvmresize -L+10G /dev/mapper/whatever）斜线分区，然后调整大小（resize2fs /dev/mappper/whatever）。这是最简单的修复方法。如果你有硬分区（例如：根目录已打开
/dev/sda1），那么你可以尝试使用 Gparted Live 启动（https://gparted.org/livecd.php）并尝试扩展硬盘分区。通常，这里的成功取决于驱动器上剩余的空闲空间以及您如何分区购买新硬盘。容量相同或更大。插入并创建更大的分区（如果可能，使用 LVM）。新磁盘上的第一个分区应为 1G 大小（可以更小，但要简短），用于 Grub 兼容性。之后，启动旧磁盘并创建目录/安装新磁盘分区
/mnt/new_disk/；将所有旧分区 rsync 到新磁盘上。（例如：rsync -av / /mnt/new_disk/slash/; rsync -av /usr /mnt/new_disk/usr/;...）。完成后，您需要以某种方式在新磁盘上安装 grub。我通常使用 chroot 来执行此操作，/mnt/new_disk/slash/但这可能很困难。通常 grub.cfg 会对某些事情感到困惑。一定有更简单的方法可以做到这一点。