Ubuntu 20 увеличение системного раздела
Предположим, что у нас есть виртуальная машина с установленной операционной системой Ubuntu и требуется увеличить размер раздела, например системного. В этой статье мы рассмотрим на примере Ubuntu 20 увеличение системного раздела без LVM.
Вводные данные
Наша Ubuntu 20 установлена на Hyper-V. Для начала проверим размер файловой системы, выполнив df -h (все команды выполняются от root пользователя):
Наш системный раздел, смонтированный в / имеет размер 24 Гб.
Посмотрим вывод fdisk -l:
В данном примере у нас 1 диск /dev/sda размером 25 гигабайт, который разбит на 3 логических: /dev/sda1, /dev/sda2 и /dev/sda3 с типом Linux filesystem – он нас и интересует.
Увеличение размера диска
В среде виртуализации увеличиваем размер жесткого диска нашей виртуальной машины. Скорее всего ваша система виртуализации попросит вас предварительно выключить ВМ. Я увеличил диск до 30 гигабайт, запускаем машину и проверяем:
Ubuntu 20 увеличение системного раздела
Внимание! Перед тем, как приступить к работам по расширению системного раздела, обязательно сделайте резервную копию данных!
После увеличения размера диска необходимо увеличить сам системный раздел. Выполним fdisk /dev/sda, где /dev/sda – метка нашего диска (Disk /dev/sda):
Вводим p, чтобы посмотреть на список разделов:
Чтобы расширить раздел требуется предварительно удалить информацию о нём. Для этого вводим d и указываем раздел (3 для /dev/sda3):
При этом удаляется только запись о разделе, сами данные остаются на диске!
Вводим n – создание нового раздела:
Далее указываем порядковый номер раздела:
Далее указываются начальный и конечный сектор. Обязательно проверьте, чтобы они совпадали со значениям, указанными через дефис. Таким образом мы используем все неразмеченное пространство:
Как видим, был создан раздел на 29.5 гигабайт с типом Linux filesystem.
Также будет задан вопрос, хотим ли мы удалить текущую файловую систему. Отвечаем отказом:
Осталось только сохранить таблицу разделов:
Перезагружаем виртуальную машину:
Теперь воспользуемся утилитой resize2fs (для ext4) для увеличения размера файловой системы:
Как видим, в Ubuntu 20 увеличение системного раздела – не такая уж и сложная задача.
Источник
Увеличение раздела /boot
Подскажите, как безопасно увеличить размер раздела /boot на ОС Xubuntu. При установке ОС поскромничал и задал разделу /boot размер в всего лишь 100 МБ. Теперь при установке обновления ксубунта ругается, что ей не хватает каких-то жалких 23 МБ на буте.
Разметка на диске такая (с начала в конец диска):
1. primary /boot 94.41 MiB 2. extended . /tmp 9.31 GiB — его-то я и хочу урезать в начале и увеличить в конце /boot.
Но как это сделать? Размонтировать /tmp не получается во время работы ОС.
Спасибо за помощь.
Загрузись с System Rescue CD (нагугли его) и меняй разделы как хочешь gparted’ом, если у теб нет LVM, либо командами lvm, если есть
Если просто не хватает места, можно удалить старые ядра.
LVM не ставил (уже пожалел), спасибо. Пойду искать.
Единственное замечание: когда работал в CD-версии ОСи, gparted почему-то глючил при размонтировании диска. Чтобы размонтировать диск нужно было его размонтировать и перезапустить gparted, иначе выдавал ошибку.
Пишу из-под ОСи, загруженной с СД 🙂
Ещё раз спасибо.
офф:
фигасе у убунты boot раздел!
я, когда ставил, выделил 40 МiB, и то, я считаю, что это много разметил (всё равно больше 20 не занято, и это при том, что 5 последних ядер я не удаляю)
А проблема, скорее всего, в том, что старые ядра не удаляются. А значит, через некоторое время и новый раздел забьётся, и придётся снова увеличивать размер раздела. Это не решение проблемы.
Мне на мыло раньше часто приходили предложения увеличить свой бут :)))
/boot на LVM обычно не делают и не рекомендуют, хотя это возможно
/boot на LVM обычно не делают и не рекомендуют, хотя это возможно
Согласен, но я исходил из того, что помимо /boot есть и другие разделы, причем не просто, а исключительно на LVM, и нет неразмеченного пространства вне LVM. То есть, чтобы увеличить /boot, нужно «подвинуть» LVM
Источник
Увеличить /boot с помощью mount
У меня закончилось место в /boot. Могу я его нарастить подмонтировав туда директорию с другого раздела? У команды mount вроде бы есть подходящие опции —bind —move. Но разница между ними не очень понятна. С какой опцией использовать mount?
#fstab
/boot /path/kuda/nado auto bind 0 0
вручную
mount -o bind /path /boot
Но загрузится ли это другой вопрос, попробуй, отпиши, самому интересно.
Решил попробовать, все ли правильно сказал, написал mount -o bind /boot /bin, как теперь /bin отмонтировать?? ТАм сейчас ядра(.
Бесполезно, потому что в работающей системе /boot вообще без надобности, а при загрузке —bind не работает. Лучше освободи место. Чем ты его вообще забил? Там обычно только одно ядро лежит и grub
Перезагрузи комп (с кнопки, потому что программно комп теперь не выключится) и больше так не делай. Хочешь экспериментов — создай временные папки и монтируй одну в другую
У меня в чруте есть. Сделал /chroot/bin/umount /boot.
Решил попробовать, все ли правильно сказал, написал mount -o bind /boot /bin, как теперь /bin отмонтировать?? ТАм сейчас ядра(.
У меня в чруте есть. Сделал /chroot/bin/umount /boot.
Можно стрелять себе в ногу, конечно, если есть другая нога :3
> Перезагрузи комп (с кнопки, потому что программно комп теперь не выключится)
MahMahoritos> Чем ты его вообще забил? Там обычно только одно ядро лежит и grub
Ты просто не видел что Убунту делает с /boot
Перенеси все старые ядра и initrd*, кроме двух последних, на другой раздел, подправь конфиг граба и живи спокойно. Часто ты грузишься с ядром годовой давности? Какой размер раздела? Мне 500Мб всегда с головой хватало даже на Убунте.
Я тоже попробовал mount —bind
/boot_ext/ /boot/ Контент директории /boot/ подменился контентом из
/boot_ext/ Вернуть обратно umount /boot/
Я не правильно вопрос сформулировал. Я когда Debian ставил, то разбивку диска выбрал поумолчанию. И под систему выделился раздел 300Mb. Т.е. там кроме boot-a еще несколько директорий. Сейчас все это дело подзабилось и не могу обновить ядро. Пишет, что место закончилось.
Наверное, если с bind, то можно какой-то из каталогов вынести на другой раздел и сказать mount —bind?
Допустим boot перенести в home и сказать mount —bind
> под систему выделился раздел 300Mb. Т.е. там кроме boot-a еще несколько директорий.
Так может быть дело не в /boot ? Почему в качестве жертвы был выбран именно он?
Там же груб2 вроде, это он делает, а не убунта. Или старые ядра/инитрд-образы не удаляются?
А почему они вдруг удалятся? Удалять нужно вручную.
Ответа на твой конкретный вопрос не знаю, но как уже было сказано сомневаюсь, что это будет работать. Удали лишние ядра — они тебе врядли нужны.
Да не будет это работать, пойми. все фокусы вроде bind работают в живой системе, а grub оперировать будет тем, что есть в настоящем boot. Лучше вынеси какие-нибудь не нужные в момент загрузки директории.
Ок. Т.е. bind может сработать, но вынести другие каталоги?
Наверное не в boot, просто время позднее было.
Увеличить /boot с помощью mount
Увеличить пинус с помощью страпона.
Когда происходит загрузка, grub работает с тем, что лежит непосредственно в /boot, т.е. если ты попробуешь использовать bind с фактическим расположением файла, например, в /usr или в /home — система не загрузиться, так загрузчик работает с файлами фактически расположенными в /boot.
Тебе предлагают вынести файлы не используемые при загрузке с этого раздела. Хотя я больше чем уверен, что у тебя там лежит три-четыре версии ядра и все они тебе не нужны. Я бы на твоем месте удалил два самых старых и никаких проблем бы не было.
du -sm /* | sort -n | tail
Вернее даже так:
du -smx /* | sort -n | tail
bash -c ‘du -smx /* | sort -n | tail’ 2>/dev/null
Вы разве не видели что она с /boot делает?
У меня они удаляются по aptitude purge linux-image-blabla
А разве проблема удалить лишние ядра?
В boot 1 ядро. Дело не в boot-е а в других директориях на разделе, я просто до вечера не могу посмотреть
Тогда это весьма интересно. С нетерпением жду вечера и ls /boot.
bind в любом случае сработает, только делать это надо по уму.
1) Выявить каталоги, не используемые до монтирования разделов, указанных в /etc/fstab.
2) Загрузиться с LiveCD (так будет аккуратнее)
3) Создать в свободном разделе каталоги, соответствующие переносимым
4) Скопировать ВСЕ содержимое из старого каталога в новый с сохранением атрибутов
5) Добавить в /etc/fstab пункты, описывающие монтирование перенесенных каталогов. При этом важно не перепутать старый и новый каталог местами (ЧТО монтировать КУДА), иначе получится ерунда.
А вам нужен ли /boot на отдельном разделе?
> Ты просто не видел что Убунту делает с /boot
И что? Вот что у меня там лежит, плюс каталог grub. Всего занято 93МБ, системе года три. Можно удалить лишние ядра, просто лень.
Я это и имел ввиду. Вручную значит не автоматически.
Как минимум это поможет системе обновиться. С фстаб я бы не заморачивался в этом случае. Да и вообще не мучался с биндом, проще содержимое бута (без грабовских файлов) куда-нить перенести и обновиться.
Как минимум это поможет системе обновиться. С фстаб я бы не заморачивался в этом случае. Да и вообще не мучался с биндом, проще содержимое бута (без грабовских файлов) куда-нить перенести и обновиться.
А, ну так себя и любимый дебиан ведет. Вполне логичное поведение.
Так себя ведет любой дистриб.
Всетаки дело было в старом ядре.
Я посмотрел с помощью df -h куда разделы смонтированы
Файловая система Размер Использовано Дост Использовано% Cмонтировано в
/dev/sda1 323M 268M 39M 88% /
tmpfs 5,0M 0 5,0M 0% /lib/init/rw
tmpfs 797M 744K 796M 1% /run
udev 3,9G 0 3,9G 0% /dev
tmpfs 1,6G 168K 1,6G 1% /run/shm
/dev/sda9 900G 84G 771G 10% /home
/dev/sda8 369M 17M 333M 5% /tmp
/dev/sda5 8,3G 6,6G 1,4G 84% /usr
/dev/sda6 2,8G 462M 2,2G 18% /var
/dev/sdb 3,8G 345M 3,5G 9% /media/41BE-38A3
Больше всего места на корневом разделе занимал /lib (190M)
в /lib/modules было 2 директории
/3.0.0-1-686-pae/ и /3.0.0-2-686-pae/
Наверное это не очень правильное решение, но /3.0.0-1-686-pae я просто удалил. И в /root еще кэш от firefox на 20 M был.
Теперь df -h
Файловая система Размер Использовано Дост Использовано% Cмонтировано в
/dev/sda1 323M 168M 139M 55% /
tmpfs 5,0M 0 5,0M 0% /lib/init/rw
tmpfs 797M 732K 796M 1% /run
udev 3,9G 0 3,9G 0% /dev
tmpfs 1,6G 104K 1,6G 1% /run/shm
/dev/sda9 900G 84G 772G 10% /home
/dev/sda8 369M 17M 333M 5% /tmp
/dev/sda5 8,3G 6,5G 1,4G 83% /usr
/dev/sda6 2,8G 600M 2,1G 23% /var
Источник
Операционные системы Astra Linux
Оперативные обновления и методические указания
Операционные системы Astra Linux предназначены для применения в составе информационных (автоматизированных) систем в целях обработки и защиты 1) информации любой категории доступа 2) : общедоступной информации, а также информации, доступ к которой ограничен федеральными законами (информации ограниченного доступа).
1) от несанкционированного доступа;
2) в соответствии с Федеральным законом от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации» (статья 5, пункт 2).
Операционные системы Astra Linux Common Edition и Astra Linux Special Edition разработаны коллективом открытого акционерного общества «Научно-производственное объединение Русские базовые информационные технологии» и основаны на свободном программном обеспечении. С 17 декабря 2019 года правообладателем, разработчиком и производителем операционной системы специального назначения «Astra Linux Special Edition» является ООО «РусБИТех-Астра».
На web-сайтах https://astralinux.ru/ и https://wiki.astralinux.ru представлена подробная информация о разработанных операционных системах семейства Astra Linux, а также техническая документация для пользователей операционных систем и разработчиков программного обеспечения.
Мы будем признательны Вам за вопросы и предложения, которые позволят совершенствовать наши изделия в Ваших интересах и адаптировать их под решаемые Вами задачи!
Репозитория открытого доступа в сети Интернет для операционной системы Astra Linux Special Edition нет. Операционная система распространяется посредством DVD-дисков.
Информацию о сетевых репозиториях операционной системы Astra Linux Common Edition Вы можете получить в статье Подключение репозиториев с пакетами в ОС Astra Linux и установка пакетов.
В целях обеспечения соответствия сертифицированных операционных систем Astra Linux Special Edition требованиям, предъявляемым к безопасности информации, ООО «РусБИтех-Астра» осуществляет выпуск очередных и оперативных обновлений.
Очередные обновления (версии) предназначены для:
- реализации и совершенствования функциональных возможностей;
- поддержки современного оборудования;
- обеспечения соответствия актуальным требованиям безопасности информации;
- повышения удобства использования, управления компонентами и другие.
Оперативные обновления предназначены для оперативного устранения уязвимостей в экземплярах, находящихся в эксплуатации, и представляют собой бюллетень безопасности, который доступен в виде:
- инструкций и методических указаний по настройке и особенностям эксплуатации ОС, содержащих сведения о компенсирующих мерах или ограничениях по примене- нию ОС при эксплуатации;
- отдельных программных компонентов из состава ОС, в которые внесены изменения с целью устранения уязвимостей, инструкций по их установке и настройке, а также информации, содержащей сведения о контрольных суммах всех файлов оперативного обновления;
- обновлений безопасности, представляющих собой файл с совокупностью программных компонентов из состава ОС, в которые внесены изменения с целью устранения уязвимостей, а также информации, содержащей сведения о контрольных суммах всех файлов обновлений безопасности, указания по установке, настройке и особенностям эксплуатации ОС с установленными обновлениями безопасности.
Ввиду совершенствования нормативно-правовых документов в области защиты информации и в целях обеспечения соответствия информационных актуальным требованиям безопасности информации, а также обеспечения их долговременной эксплуатации, в том числе работоспособности на современных средствах вычислительной техники, рекомендуется на регулярной основе планировать проведение мероприятий по применению очередных и оперативных обновлений операционной системы.
Источник