Назад | Перейти на главную страницу

Загрузитесь с другого корневого раздела, чтобы уменьшить исходную корневую файловую систему на LVM

Как я могу изменить корневой раздел для загрузки Debian 10?

Я хотел бы уменьшить размер моей корневой файловой системы, которая находится на логическом томе LVM удаленно, то есть только через SSH и без загрузки с Live CD.

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

Я пробовал использовать виртуальную машину с Ubuntu Server 18.04, поскольку AFAIK использует ту же «загрузочную цепочку», что и Debain 10. Однако я не смог надежно установить клонированный раздел как root. После перезагрузки проверил с mount и исходный корень все еще используется, хотя

Текущая конфигурация

/etc/fstab был изменен соответственно (заменен путь к устройству сопоставления).

До сих пор я rsync 'весь старый корень aaa к новому корню bbb, Я заменил все вхождения UUID aaa и xxx с участием bbb и yyy в /boot/grub/grub.cfg (Примечание: я не использую grub2 или загрузка UEFI).

initramfs был обновлен с использованием update-initramfs -u (после исправления /etc/initramfs-tools/conf.d/resume).

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

update-grub признал newroot том и добавил соответствующие записи в grub.cfgвыбор их вручную при загрузке в моей тестовой виртуальной машине (невозможно через SSH ...) также загрузил старый корень.

Я также видел, что есть ROOT вариант для /etc/initramfs-tools/initramfs.conf для жесткого кодирования корневого раздела:

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

Но так как у меня есть bootarg для root grub.cfg этот параметр не должен действовать.

Что еще нужно настроить, чтобы использовать другой UUID в качестве root при следующей загрузке?

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

  1. Создать снимок корневого раздела. Убедитесь, что для него выделено немного места, так как вы будете его менять.
  2. fsck снимок.
  3. Измените размер снимка (уменьшите его) и убедитесь, что между вершиной файловой системы и границей целевого размера LV есть буфер - просто на всякий случай.
  4. Слейте снимок обратно в rootfs LV.
  5. Перезагрузка. Слияние фактически выполняется на этом этапе (вероятно, во время загрузки).
  6. После перезагрузки - сожмите том rootfs и, возможно, снова измените размер rootfs, чтобы он заполнил любое пространство до верхней части LV.

Есть один недостаток: вы ПОТЕРЯЕТЕ некоторые данные между шагами 1 и 5 и МОЖЕТЕ иметь некоторые несоответствия (в зависимости от используемой файловой системы) на шаге 1 - когда вы делаете снимок в действующей файловой системе.

У меня это сработало на удивление хорошо.

В идеале шаг 1 должен быть выполнен во время загрузки, перед повторным монтированием rootfs rw, поэтому снимок будет чистым. Я не понял, как это сделать из дракута - инструменты, которые я пытался использовать, у меня там не работали.

Оказывается, я забыл заменить root = bootarg в /boot/grub/grub.cfg...

Для полноты:

Как переместить корневой раздел на другой PV в LVM через SSH без Live системы

Примечание. Всегда делайте резервную копию важных данных! Этот метод является взломом и не должен использоваться в производственных системах. В любом случае данные, записанные между клонированием LV и загрузкой из нового корневого раздела, всегда будут потеряны.

Создать новый LVM на другом диске

fdisk /dev/sdb #Create new partition for PV (sdb1)
pvcreate /dev/sdb1
vgcreate vg1 /dev/sdb1
lvcreate -n newroot -L10G vg1 #Size has to be larger than effective usage on current root
mkfs.ext4 -L newroot /dev/mapper/vg1-newroot

Соберите информацию о новом LVM

lvdisplay
vgdisplay
pvdisplay
blkid

Следующие команды будут ссылаться на информацию, представленную здесь, как:

  • $ pv0uuid = UUID старого PV
  • $ pv1uuid = UUID нового PV
  • $ vg {0,1} uuid = UUID {старого, нового} VG
  • $ lv {0,1} UUID = UUID {старого, нового} LV
  • $ root {0,1} UUID = UUID {старой, новой} корневой файловой системы
  • $ vg {0,1} = Имя {старый, новый} VG
  • $ lv {0,1} = Название {старый, новый} LV

И /etc/grub/grub.cfg будет представлен как $grubcfg. Для систем UEFI это, скорее всего, /boot/grub2/grub.cfg.

Я рекомендую установить их как переменные в bash с помощью pv0uuid=xxxxxx-xxxx... поэтому приведенные ниже команды можно скопировать.

Установите новый корень в конфигурации GRUB

Эти команды заменят текст в конфигурации GRUB:

sed -i "s/$pv0uuid/$pv1uuid/g" $grubcfg
sed -i "s/$vg0uuid/$vg1uuid/g" $grubcfg
sed -i "s/$lv0uuid/$lv1uuid/g" $grubcfg
sed -i "s/$root0uuid/$root1uuid/g" $grubcfg
sed -i "s/$vg0/$vg1/g" $grubcfg #BEWARE COMMON NAMES
sed -i "s/$lv0/$lv1/g" $grubcfg #BEWARE COMMON NAMES
sed -i "s/\/dev\/mapper\/$vg0-$lv0/\/dev\/mapper\/$vg1-$lv1/g" /etc/fstab #BEWARE COMMON NAMES

ОСТОРОЖНО ОБЫЧНЫХ ИМЕН: sed заменит каждый совпадения текста, поэтому рекомендуется внести эти изменения вручную, так как заменяя такие слова, как root использование в другом месте конфигурации GRUB или fstab сделает его недействительным!

Рекомендую использовать nano и поиск (CTRL+W) для имен VG и LV и замените их вручную. Также рекомендуется поиск по имени фотоэлектрического устройства, на всякий случай ...

Клонировать корневой том

mount /dev/mapper/$vg1-$lv1 /mnt
rsync -rAa --one-file-system / /mnt/
umount /mnt

перезагрузка

Перезагрузитесь (и молитесь). Убедитесь, что новый LV монтируется на /.

Удалить старый LVM

lvremove /dev/$vg0/*
vgremove $vg0
pvremove /dev/sda2 #Path to $pv0uuid

Очистка

Необязательно, но рекомендуется

  • Наконец удалите старую VG из /etc/lvm/archive или он будет искать во время каждой загрузки и вызывать задержки
  • update-grub
  • update-initramfs -u

Ноты

Протестировано на Ubuntu 18.04, другие дистрибутивы могут по-разному обрабатывать конфигурацию GRUB (в отношении UUID и путей к устройствам и команд обновления).

Очевидно, заранее остановите все ненужные службы, чтобы минимизировать потерю данных.

Возможно, есть способ избежать (большей части) потери данных, используя цели systemd, пользовательские скрипты и снимки LVM. Придется синхронизировать данные из $lv0 к $lv1 снова в последний возможный момент перед перезагрузкой. За рамками этого поста ...

Если /boot это не отдельный раздел, проверьте еще раз $grubcfg на новом корне перед повторной перезагрузкой.