Недостаточно места на диске при ошибке "Корень файловой системы" в openSUSE Leap 15

Question

проблема

Видимо, у меня мало места на диске в корневом разделе. Во время установки моей ОС (openSUSE Leap 15 на виртуальной машине) я выбрал разделение по умолчанию. Теперь я получаю предупреждение / ошибка Low Disk Space в "Корне файловой системы". Он предупреждает меня, когда я запускаю систему, и когда я пытаюсь скомпилировать большой проект, он выдает ошибку.

Анализ

Давайте проверим ситуацию с хранением:

Использование дискового пространства в файловой системе отчета:

$ 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

Идеи для решения:

1. Изменить размер корневого раздела. (было бы неплохо дать root еще 10 концертов)
2. Удалите старую версию ядра и надеюсь, что я не сломаю вещи, и освободившихся 245 МБ пока будет достаточно.

Я действительно одобряю просто дать root больше места, но не имею ни малейшего понятия, как это сделать, или если это хорошая идея, чтобы возиться с этим вообще. Какое решение вы бы предложили и как я могу это сделать?

Answer 1

Первое, что нужно сделать, это сделать резервную копию чего-нибудь важного. Дальнейшее продвижение по этому пути подразумевает действия, которые могут привести к потере данных. Некоторые варианты ниже:

• купить новый жесткий диск USB SATA. Поменяйте USB SATA диск со своим старым диском в вашем случае. Переустановите Linux на новый диск SATA. Всякий раз, когда вам нужен доступ к вашим старым файлам, подключите USB-накопитель, и они есть.

• Если вы разбили на разделы с помощью LVM (чего, вероятно, нет у SuSE), посмотрите, сможете ли вы расширить (lvmresize -L+10G /dev/mapper/whatever) раздел с косой чертой и затем изменить его размер (resize2fs /dev/mappper/whatever). Это самое простое решение.

• если у вас есть жесткие разделы (например, root находится на /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 запутывается в вещах. Должны быть более простые способы сделать это.

Answer 2

/dev/sda2 смонтированный в разных точках монтирования (где у вас должен быть другой контент), заставляет меня поверить, что вы используете Btrfs. У вас также есть /.snapshots который указывает на присутствие Snapper. Весьма вероятно, что /.snapshots занимает большую часть используемого пространства.

Обратите внимание, что ваш анализ с использованием du -hsx /* даже не принял во внимание /.snapshots потому что * glob не распространяется на имена, начинающиеся с . ,

У меня нет опыта работы со Снаппером. Я подозреваю, что внутри /.snapshots Btrfs (shapshots). Команда du -hsx /.snapshots может даже вернуть 0 из-за используемой опции -x . С другой стороны, du -hs /.snapshots , вероятно, вернет огромное значение. Это может быть намного больше, чем размер /dev/sda2 (который составляет 40GiB), потому что у вас, вероятно, есть несколько снимков, которые разделяют дисковое пространство (так работает Btrfs), но du будет считать их отдельными файловыми системами.

Для дальнейшего анализа вам нужны инструменты, специфичные для Btrfs и / или Snapper. У меня есть некоторый опыт работы с Btrfs, но не с Snapper. Я не могу сказать, можете ли вы запутать Snapper, вручную создавая созданные им снимки, это может быть возможно; но я уверен, что вы не можете сломать Btrfs с помощью Snapper. Поэтому безопасный подход заключается в том, чтобы справиться с ситуацией с помощью всего, что предоставляет Snapper, а не напрямую с помощью инструментов Btrfs.

Уже упоминавшийся урок дает нам некоторые советы о том, что вы можете сделать:

• Список всех снимков для конфигурации по умолчанию (root)

  snapper list
  

• Удаление снимков

  Удалите снимок 65 для конфигурации по умолчанию (root):

  snapper delete 65
  

Но также:

Механизмы автоматической очистки снимков

Чтобы предотвратить переполнение дискового пространства, Snapper периодически очищает снимки. По умолчанию этот период = 1 день.

Задачей автоматической очистки снимков можно управлять двумя способами:

1. планировщик cron (/etc/cron.daily/suse.de-snapper).
2. Планировщик системного таймера (snapper-cleanup.timer и snapper-cleanup.service).

По умолчанию используется механизм cron.

Может быть, что-то не так с этим механизмом очистки?

Как я уже сказал, у меня нет опыта работы со Снаппером, поэтому я не могу вам больше помочь. Однако, если я прав, теперь вы знаете, что расследовать. Подвести итоги:

• вы полностью пропустили каталог /.snapshots , скорее всего, он отвечает за большую часть используемого пространства;
• Снимки Btrfs, вероятно, участвуют;
• Снаппер, вероятно, участвует.