Linux увеличить размер boot

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 последних ядер я не удаляю)

Читайте также:  Удаление реестр активации windows

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

Мне на мыло раньше часто приходили предложения увеличить свой бут :)))

/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 вроде, это он делает, а не убунта. Или старые ядра/инитрд-образы не удаляются?

А почему они вдруг удалятся? Удалять нужно вручную.

Ответа на твой конкретный вопрос не знаю, но как уже было сказано сомневаюсь, что это будет работать. Удали лишние ядра — они тебе врядли нужны.

Читайте также:  Включить учетную администратора windows 10

Да не будет это работать, пойми. все фокусы вроде 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/

Читайте также:  Аналоги mysql workbench для linux

Наверное это не очень правильное решение, но /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 требованиям, предъявляемым к безопасности информации, ООО «РусБИтех-Астра» осуществляет выпуск очередных и оперативных обновлений.

Очередные обновления (версии) предназначены для:

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

Оперативные обновления предназначены для оперативного устранения уязвимостей в экземплярах, находящихся в эксплуатации, и представляют собой бюллетень безопасности, который доступен в виде:

  1. инструкций и методических указаний по настройке и особенностям эксплуатации ОС, содержащих сведения о компенсирующих мерах или ограничениях по примене- нию ОС при эксплуатации;
  2. отдельных программных компонентов из состава ОС, в которые внесены изменения с целью устранения уязвимостей, инструкций по их установке и настройке, а также информации, содержащей сведения о контрольных суммах всех файлов оперативного обновления;
  3. обновлений безопасности, представляющих собой файл с совокупностью программных компонентов из состава ОС, в которые внесены изменения с целью устранения уязвимостей, а также информации, содержащей сведения о контрольных суммах всех файлов обновлений безопасности, указания по установке, настройке и особенностям эксплуатации ОС с установленными обновлениями безопасности.

Ввиду совершенствования нормативно-правовых документов в области защиты информации и в целях обеспечения соответствия информационных актуальным требованиям безопасности информации, а также обеспечения их долговременной эксплуатации, в том числе работоспособности на современных средствах вычислительной техники, рекомендуется на регулярной основе планировать проведение мероприятий по применению очередных и оперативных обновлений операционной системы.

Источник

Оцените статью