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

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

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

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

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

Я попытался освободить немного места с помощью gpartedGUI с Live 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разделами и нужны ли мне оба?

решение1

По сути, у AFH и Romeo Ninov есть ответ, но его нужно объединить.

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

Вы сообщаете, что ваш процесс обновления жалуется на недостаточное пространство в вашем /bootразделе размером 244 МБ, но этот раздел в настоящее время используется только на 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, используйте аварийную систему, чтобы расширить его до исходного размера.

решение2

Я нахожу, что результаты 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.

решение3

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

df

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

Связанный контент