Calculate Forum

Несколько систем + grub2 + работа в subvolume

Давно использую генту. Выработал свой стиль. Решил воспользоваться родственным дистрибутивом Calculate Linux, но так и не смог найти пограничное решение.

Вначале опишу иерархию ранее применяемых системы - чистой генту. (Понимаю, что в Calculate Linux придется идти на компромиссы)

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

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

У меня загрузчик grub не входит в состав системы. Он устанавливается в отдельный раздел. Устанавливается с загрузочного диска и может оттуда быть обновлен (с нового образа).
Для загрузчика выделяется отдельный раздел, где размещаются компоненты, которыми можно управлять самим загрузчиком и администратором системы (но никакими утилитами/пакетными менеджерами). Здесь могут быть расположены образы LiveCD. (В качестве реального примера долгое время использовался SystemRescueCD, который был построен на том же генту). Но в этом разделе не место ядрам и инитрамам. Почему? Потому что ими управляет система пакетов. Потому что состояние корневой файловой системы должно быть консистентно включая ядро.

Загрузчики в последнее время спокойно могут брать файлы с других файловых систем. (Даже можно сказать больше, что в CL это используется. Смотри далее по тексту пример с unicode.pf2). Раньше, когда деревья были большими, а загрузчики маленькими, то получить доступ к загружаемому образу было проблематично. Даже самому загружаемому образу получить доступ к корневой системе можно было после определенных действий. Именно для этих целей были всякие инитрам, позволяющие создать окружение для доступа к реальной файловой системе. А пока не получен доступ к корневой фс обеспечить доступность к разным компонентам необходимым ядру - например, прошивкам (фирмваре).
Это время потихоньку стало проходить, мир стал меняться, но только на мой взгляд не с той стороны. Например, движуха со слиянием /bin и /usr/bin. Аргумент, что прошли те времена, когда доступность частей корневой системы была функцией времени загрузки. С другой стороны инитрам/инитрд не прекращают своего использования. Остается этап запуска системы, когда доступность полной корневой системы ограничена. Значит разделение между /bin и /usr/bin (которое будет смонтировано позднее) осталось актуальным, но в другом выражении: в реальной корневой системе или в ининрам.

Итак, загрузчик может получить загружаемый образ с большинства файловых систем. (Я понимаю аргумент с шифрованной корневой системой, и даже с сетевой, но в большинстве обыденных случаев большой необходимости шифровать системный раздел не возникает необходимости, а в домашних условиях кажется странным загрузка системы по сети.) Значит, можно консистентно зависимые части - корневая ФС и ядро держать в едином разделе. Который в свою очередь можно защищать снимками и не волноваться в нарушении целостности этих двух частей при восстановлении.

Выработанная система оказалось утрированно простой.

Разделы
GRUB - домашний раздел grub. Содержит конфигурацию grub.
SYS1- первый системный раздел. В каталоге /boot содержит загружаемое ядро (+/- инитрам)
SYS2 - второй системный раздел. Здесь чуть позднее рассмотрим ситуацию сложнее.
DATA - дополнительный раздел с домашними каталогами и прочим. Необходим уже для входа пользователя и запуска конкретных сервисов (если с разных систем, то в пределах согласованности версий пакетов этих самих сервисов).

Теперь про SYS2.
С появлением btrfs и их subvolume открылось “второе дыхание”. Стало возможным располагать по множеству систем на одном разделе. Вначале я использовал только для создание точек отката системы, затем для возможности запуска отдельно установленной системы.
В корне файловой системы создается подтом SYSTEM_A. Тогда ядро этой системы доступно для grub по пути /hdX/SYSTEM_A/boot/ .
В случае, если есть желание создать снимок системы, то пара корневая_система-ядро остается целостным. Да, понимаю, что есть вопросы к содержимому fstab. Но если просто снимок SYSTEM_A-20210102 вернуть на прежнее название, то система не имеет проблем загружаться. В противном случае ничего не мешает изменить содержимое /SYSTEM_A-20210102/etc/fstab в требуемое состояние.
Отдельное восхищение вызывает “стоимость” операции снимка. Она производится прямо из работающей системы и занимает секунду.
Ничего не мешает рядом с SYSTEM_A расположить SYSTEM_B. Здесь можно развернуть и запускать с комфортом другую систему. Например, под тестируемый на реальном железе сервер с очень низкой производительностью (для emerge, всегда удобнее собирать по месту, чем заказывать сборки на билдсервере). Но это только пример. Было бы великолепно запустить совершенно инородный дистрибутив.

Теперь про Calculate Linux.
Понимая, что придется сосуществовать с загрузчиком системы пришлось установить систему на отдельный носитель. Минус еще один SSD. А можно ли такое позволить в ноутбуке? Новая система совершенно наплевала бы на принятые условности старого загрузчика, поэтому пришлось на время установки переключить источник загрузки на новый диск, а после окончания добавить в свой передачу загрузки на другой диск.

menuentry 'DISK2 loader'{
        echo   'DISK2 boot load ...'
        set root=hdX
        chainloader +1
}

Две системы оказались работоспособны.
Сейчас я понимаю, что мог бы свой конфигурационный файл разместить в (BOOT)/grub/custom.cfg .

После установки я задался вопросом использовать subvolume для системы. Перенос системы с (SYS1)/ в (SYS2)/CLD_20_6 был произведен успешно. Могу только дать 2 совета.

  1. Для клонирования системы следует учитывать xattr. Обнаружить их повреждение очень легко, но спросить у системы что повреждено практически нет способов. (У меня сразу из DM исчезла возможность выключить систему)
    Для клонирования системы использовал tar (rsync излишен по причине пустого подтома назначения).
    Придется единственный раз загрузится с внешнего носителя (это же без проблем, с него устанавливались только что)
mount /dev/sdXN /mnt/src
mount /dev/sdXM /mnt/dst     ## (*)
btrfs subvolume create /mnt/dst/CLD_20_6
cd /mnt/src
tar -cp --xattrs --xattrs-include='*.*' . | tar -xp --xattrs-include='*.*' -v -C /mnt/dst/CLD_20_6/
  1. При инсталляции Calculate Linux для переноса в subvolume настойчиво советую воздержаться от выбора "compressed btrfs". В этом случае к требуемым атрибутам добавится атрибут btrfs.compression="lzo" установленный у каждого файла и каталога.
    У btrfs есть особенность - при монтировании соседних subvolume невозможно изменить опцию монтирования "compress=" . Поэтому если смонтирован корень системы, то уже оперируя опцией нельзя задать иное отношение к компрессии на разделе. Эта особенность не фатальна, можно задать
btrfs property set /mnt/your-subvolume compression lzo

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

mount -ocompress=lzo /dev/sdXM /mnt/dst

Теперь осталась рутина:

  1. исправить в fstab UUID для /
    1.1. добавить опцию компрессии по желанию
  2. исправить конфигурацию grub
    Ищем в /boot/grub/grub.cfg "menuentry 'Calculate Linux Desktop KDE' ..."
    и в "linux /vmlinuz-..."
    2.1. изменяем "root=UUID=..." на UUID от SYS2
    2.2. добавляем "rootflags=subvol=CLD_20_6"

Остальные действия довершит система обновления после старта системы уже с подтома CLD_20_6. При обновлении конфигурации grub (изменении в ядре) будут обновлены остальные поля и приведены в порядок UUID.
FIXME. Если подскажите здесь соответствующую команду буду благодарен (чтобы не дожидаться обновления ядра).

Можно перезагрузиться.

И вот оно первое столкновение с grub2!
Он же потерял в конфигурации правильно установленную систему на SYS1. Что он может найти и правильно сконфигурировать у других систем?

Теперь подходим к сути проблемы.

Я хотел бы поставить вторую систему рядом. В последнее время у меня слишком много нареканий на работу KDE и хотелось бы рядом с CLD развернуть CLDX. Уверенность в полной пригодности CLDX нет по причине подбора приложений. Разворачивание обоих DE в одной установке приведет к доступности программ из обоих комплектов. Оставлять только один вариант - значит не иметь возможности просто перезагрузкой вернуться в привычное окружение и выполнить неотложную работу.

Задача минимум - установить систему в SYS1. (Но это отберет целый раздел, кстати ничего не мешает его совмещать с разделом под временные нужды или даже swap) Переход на новую систему может продлиться не один месяц.

Задача максимум - установить систему в (SYS2)/CLDX . Вроде бы на первый взгляд особых проблем нет.

Но оба подхода приводят к конкуренции за раздел GRUB.

Вот некоторые наблюдения:

В ходе последнего обновления при замене ядра был изменен initramfs-5.4.81-calculate.img. А кто сказал, что этот файл находится в единоличном пользовании текущей системы?

При установке второй системы у grub довольно пренебрежительное отношение к соседней системе “какая-то там система на sdx …”. Были случаи, когда эта система просто переставала загружаться (разбираться не стал, подробности были на тот момент не важны, но факт помню отчетливо).

Загрузчик лезет в основную систему за шрифтом

if loadfont /CLD_20_6/usr/share/grub/unicode.pf2 ;

Для этого производятся прыжки корня граба по разделам. Сначала к шрифтам

search --no-floppy --fs-uuid --set=root --hint-bios=hd5,gpt3 --hint-efi=hd5,gpt3 --hint-baremetal=ahci5,gpt3  ...
...
set root='hd5,gpt3'

А при загрузке ядра обратно

search --no-floppy --fs-uuid --set=root --hint-bios=hd5,gpt2 --hint-efi=hd5,gpt2 --hint-baremetal=ahci5,gpt2 ...

И куда он будет лезть если я решу именно эту систему уничтожить?

Ну и последний случай. Достаточно косвенно затрагивающий тему.
При последнем обновлении исчез параметр "real_resume=UUID=". Но он исчез не только для нового ядра, но и для старых тоже.

Про запрет в настройках /etc/calculate/ini.env удалять старое ядро я в курсе.

#============================ Настройки системы ==============================
[system]
# Удалить ядро и модули при удалении пакета sys-kernel/calculate-sources
remove_old_kernel = off

Частично помогает.

Что бы помогло в большей степени.
Установить grub прямо в раздел SYS1, чтобы ядра располагались (SYS1)/CLD_20_6/boot, а конфигурация формировалась в (SYS1)/CLD_20_6/boot/grub/ . Перезагрузить grub с новой конфигурацией вроде бы особых проблем нет.

Тогда двухступенчатая загрузка (GRUB)/grub --> (SYS1)/CLD_20_6/boot/grub должна бы позволить и волкам быть сытым, и овцам целым.

Хм, весьма познавательно!
Я бы с ходу посоветовал замаскать груб в кальке на текущей версии, что бы он вообще не обновлялся. И обновлять ядро только вручную без установки его в /boot, потом руками копировать, что бы не ломать всю схему.
По поводу установки - хз, что можно сделать. Установщик кальки не предназначен для такого, в нём нельзя не указать диск для установки загрузчика, по-моему.
Обновление в сабвольюм тоже не поддерживается сейчас. Т.е. если сильно нужно, можно ковырнуть утилиты, что бы они не проверяли разделы для установки на свои шаблоны соответствия, но это уже больше для прогера работа.

Да, автоматизации нет, но обновление происходит без проблем. Просто руками приходится делать snapshot.
Беда, что снимок теряет связь с ядром и конфигурацией загрузчика для него. Здесь потребуется больше знаний чтобы вернуться в прежнее состояние.
Можно задуматься о смещении каталога монтирования у grub + зафиксировать grub.
Только установка соседнего дистрибутива поставит ведь grub из своего инталлятора …
Ох, не хочется по-живому ломать, надо бы в витуалке поэкспериментировать.

Просто галку не ставлю при выборе диска для установки grub, при условии что идёт установка второй - третьей системы, после перехожу в установленную ранее где есть загрузчик и обновляю grub.config. А если в системе пара физ. дисков указываю второй на котором нет grub загрузчика и далее переход в основную систс. и обновление grub.conf.

А чего же тогда граб не видит нормально установленную систему, которую я только что клонировал на соседний раздел?

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

Провел эксперимент на VBox. Поставил 2 системы в разные разделы.

Выбрал специально образы, собранные в разное время

Загрузился с CLD

  1. Создал разделы sda1=32M, sda2=1G, sda3=10G, sda4=10G
  2. В sda2 поставил grub
mkfs.ext3 -L BOOT -m0 /dev/sda2
mkdir /mnt/boot
mount -L BOOT /mnt/boot
grub-install --boot-directory=/mnt/boot /dev/sda
  1. Поставил CLD. При установки снял отметку устанавливать загрузчик. Ставил в один раздел /dev/sda4.
  2. Создал grub.cfg для grub на /dev/sda2
set timeout=5
set default=0

insmod part_gpt
insmod btrfs

menuentry 'Calculate XFCE from SYS1'{
    configfile (hd0,gpt3)/boot/grub/grub.cfg
}

menuentry 'Calculate KDE from SYS2'{
    configfile (hd0,gpt4)/boot/grub/grub.cfg
}
  1. Перезагрузился

В установленной системе CLD

Сначала загружается первый grub. Здесь 2 пункта. При выборе загружается конфигурация grub с раздела, где установлена система. Конфигурация достаточно “жесткая”, с настройкой видеорежима, своими шрифтами, подложкой и всё равно пытающейся “попрыгать” по разделам, хотя он и один.

Возможно было бы полезнее добавить еще

set root='hd0,gpt4'

но в начале конфигурационного перед обращением к разделу (системы и его grub) уже есть set root

Система нормально загрузилась.

Загрузился с CLDX

Поставил систему аналогично CLD, но в раздел /dev/sda3

Перезагрузился.

Итог

Всё работает.
Загружаются обе системы.
Конфигурации и ядра своих систем держат раздельно.

Продолжение следует …

Проведу эксперимент до конца - размещу обе установки в соседних подтомах btrfs. В первом эксперименте мало выделил под виртуальный диск. Придется повторить.

Проблемы

  1. Конфигурация загрузчика второй системы видит первую, но опять не очень уважительно :wink:, а первая - нет. Думаю в подтомах они совсем “потеряют” друг друга.

  2. При установке система не стала вписывать grub в загрузочный сектор (и это правильно, я не просил). Но команда cl-setup-boot из загруженной системы сделала запись (я не просил это делать, а как попросить это не делать по справке команды не понятно). Исправляется grub-install идентично описанному ранее.


Примечание. Команды (кроме конфигурации grub) писал по памяти, возможны опечатки.

Достигнут положительный результат.
По результатам создана статься Установка нескольких дистрибутивов в единый Btrfs subvolume

Если есть какие-то комментарии к статье, то с интересом выслушаю их здесь и постараюсь ответить.

Кстати, в ходе подготовки статьи заметил, что у других дистрибутивов уже появилась поддержка подтомов btrfs. При установке на такой раздел btrfs система ставится в subvolume.

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

© 2007-2020 Calculate Ltd.
Mastodon Mastodon