Почему мой корневой раздел отображается как полный в gparted?

Question

Я немного знаю о файловых системах, но не очень. У меня есть только общее представление о том, что такое LVM, хотя, очевидно, именно это я и использую в качестве корневого раздела.

У меня в компьютере один жесткий диск емкостью 1 ТБ. Я запускаю Ubuntu 14.04.

Я пошел сегодня установить некоторые обновления и мне сообщили, что у меня недостаточно места в разделе /boot .

Я решил освободить место с графическим интерфейсом gparted с живого CD, но заметил, что моя корневая файловая система отображается как заполненная:

Согласно df однако:

Filesystem                  1K-blocks     Used Available Use% Mounted on
/dev/mapper/ubuntu--vg-root 954367812 10720604 895145040   2% /
none                                4        0         4   0% /sys/fs/cgroup
udev                          2995912       12   2995900   1% /dev
tmpfs                          608016     1312    606704   1% /run
none                             5120        0      5120   0% /run/lock
none                          3040072    17312   3022760   1% /run/shm
none                           102400       52    102348   1% /run/user
/dev/sda2                      241965   118221    111252  52% /boot
/dev/sda1                      523248     3428    519820   1% /boot/efi
tmpfs                         3040072        4   3040068   1% /var/lib/polkit-1/localauthority/90-mandatory.d

Что с этим? Почему gparted считает, что мой раздел заполнен?

---

У меня также есть дополнительный вопрос. Кто-нибудь знает, в чем разница между /boot/efi и /boot , и нужны ли мне оба?

Answer 1

Я нахожу, что результаты gparted и df различаются, но не в такой степени: я подозреваю, что gparted неправильно интерпретирует ваше содержимое lvm2 .

Ваша проблема в том, что /boot монтируется на отдельный диск емкостью 0,25 ГБ, и это то, что не хватает места. Я не уверен, как вы попали в это состояние или как из него выйти: возможно, grub не очень хорошо загружается из файловых систем lvm2 .

Сначала нужно удалить все ядра, кроме текущего и предыдущего (вам никогда не понадобится более одного резервного ядра). Тип:

ls -l /boot/initrd*
uname -a

Это покажет все установленные версии ядра и ваше работающее ядро. Затем вам нужно удалить все, кроме двух последних. Я предпочитаю использовать synaptic для этого: выберите Installed и в поле поиска установите поочередно числовую часть каждого из выпусков, которые вы хотите удалить, затем нажмите Ctrl-a чтобы выбрать все, и щелкните правой кнопкой мыши и выберите Mark for Complete Removal (убедившись, что вы не удалите свой текущий выпуск!). После прохождения каждого из ядер, которые нужно удалить, нажмите Apply .

В Ubuntu 15.04 с двумя установленными ядрами размер моего каталога /boot составляет чуть более 120 МБ, поэтому у вас должно быть место для двух выпусков, пока вы устанавливаете третий в /dev/sda2 (и не забывайте удалять самый старый выпуск каждый раз, когда вы это делаете этот).

Если это не решит вашу проблему, то у вас есть два варианта:

1. Увеличьте размер /dev/sda2 , переместив границу между ним и /dev/sda3 .
2. Поищите в интернете grub lvm2 и следуйте советам там.

Чтобы ответить на ваш вспомогательный вопрос, /boot - это место, где находятся загрузочные файлы ядра, и обычно оно находится в той же файловой системе, что и / , но grub должен определить, где находятся загрузочные файлы EFI, и это делается путем монтирования загрузки EFI. раздел в /boot/efi . Другими словами, /boot/efi - это точка монтирования для отдельной файловой системы, но сама по себе /boot не является точкой монтирования. Вам нужно и то, и другое, если только вы не загружаетесь с помощью устаревшего BIOS.

Answer 2

Между ними AFH и Ромео Нинов в основном имеют ответ, но его нужно объединить.

Ваш раздел /boot является отдельным, потому что это по существу требуется для использования LVM (который является не файловой системой, а контейнером для логических томов, которые сами содержат файловые системы). Размер раздела LVM можно изменить; см. здесь, чтобы обрисовать в общих чертах, что требуется. Я не уверен, что пойду туда, хотя ....

Вы сообщаете, что ваш процесс обновления жалуется на недостаток места в вашем 244 МБ /boot разделе, но этот раздел в настоящее время используется только на 52%. Распределения, которые обычно создают отдельные /boot разделы, обычно делают их примерно в два раза больше ваших, но все равно странно, что ваши обновления будут пытаться почти удвоить количество используемого там пространства. При установке Ubuntu 14.04, на которой я это печатаю, используется всего 80 МБ в /boot . Поэтому вы можете проверить, что там. Введите ls -lh /boot . Вот что я вижу в своей системе:

$ ls -lh /boot
total 70M
-rw-r--r--  1 root root 1.2M Feb 14 17:06 abi-3.13.0-45-generic
-rw-r--r--  1 root root 1.2M May  4 01:09 abi-3.13.0-52-generic
-rw-r--r--  1 root root 162K Feb 14 17:06 config-3.13.0-45-generic
-rw-r--r--  1 root root 162K May  4 01:09 config-3.13.0-52-generic
drwxr-xr-x 10 root root 4.0K Dec 31  1969 efi
drwxr-xr-x  3 root root 1.0K May  7 11:30 extlinux
drwxr-xr-x  5 root root 1.0K Mar 12 20:08 grub
drwxr-xr-x  2 root root 1.0K Feb 14 17:06 grub.bak
-rw-r--r--  1 root root  20M Feb 26 18:39 initrd.img-3.13.0-45-generic
-rw-r--r--  1 root root  20M May  7 11:28 initrd.img-3.13.0-52-generic
drwx------  2 root root  12K Feb 14 17:05 lost+found
-rw-r--r--  1 root root 173K Feb 14 17:06 memtest86+.bin
-rw-r--r--  1 root root 174K Feb 14 17:06 memtest86+.elf
-rw-r--r--  1 root root 175K Feb 14 17:06 memtest86+_multiboot.bin
-rw-r--r--  1 root root  227 Feb 14 17:06 refind_linux.conf
-rw-------  1 root root 3.3M Feb 14 17:06 System.map-3.13.0-45-generic
-rw-------  1 root root 3.3M May  4 01:09 System.map-3.13.0-52-generic
-rw-------  1 root root 5.6M Feb 14 17:06 vmlinuz-3.13.0-45-generic
-rw-r--r--  1 root root 5.6M Feb 19 21:38 vmlinuz-3.13.0-45-generic.efi.signed
-rw-------  1 root root 5.6M May  4 01:09 vmlinuz-3.13.0-52-generic
-rw-r--r--  1 root root 5.6M May 10 21:36 vmlinuz-3.13.0-52-generic.efi.signed

Это довольно типично (хотя с немного большим, чем некоторые системы). Если вы видите больше файлов разных типов, чем я показал здесь, возможно, что-то добавило что-то новое и постороннее, и такие файлы могут быть кандидатом на удаление - но если вы их не понимаете, спросите совета, прежде чем удаляя их.

Другая вещь, чтобы проверить это посторонние ядра. Это файлы с именами, которые начинаются с vmlinuz . (Они в паре с файлами initrd.img , которые вы искали в AFH.) Мой собственный пример показывает четыре файла ядра, но это действительно подписанные и неподписанные версии всего двух ядер. Если вы видите более трех версий ядра (каждая из которых может быть доступна в подписанной и неподписанной форме), попробуйте следующую команду:

sudo apt-get autoremove

Эта команда должна удалить все, кроме исходного и двух самых последних ядер из вашей системы, что должно очистить некоторое пространство.

Если вам нужно изменить размер разделов, может быть безопаснее сжать системный раздел EFI (ESP; /dev/sda1 в вашем случае) и расширить /boot в это пространство, чем возиться с настройкой LVM. Я бы не рекомендовал изменять размеры более чем на 200 МБ, и вам обязательно следует создать резервную копию обоих разделов на съемном носителе, прежде чем продолжить, потому что оба раздела имеют решающее значение для загрузки, поэтому, если что-то пойдет не так, у вас будут большие проблемы. Также имейте в виду, что некоторые EFI могут быть привередливы в отношении файловых систем FAT на своих ESP. Некоторые (в основном более старые EFI, начиная с 2012 года) будут плохо реагировать на ESP FAT32, который меньше 512 МБ. Таким образом, если вы попытаетесь изменить размер таким образом, начните с сокращения ESP, а затем выполните тестовую загрузку. Если вы можете загрузиться, разверните /boot в освободившееся пространство и попробуйте загрузиться снова. Если у вас возникли проблемы после сжатия ESP, используйте аварийную систему, чтобы расширить ее до первоначального размера.

Answer 3

Потому что на экране вы видите PV (физический том), а не файловую систему. И весь PV назначен на VG. проведение

df

вы увидите статус файловой системы