Давно использую генту. Выработал свой стиль. Решил воспользоваться родственным дистрибутивом 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 совета.
- Для клонирования системы следует учитывать 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/
- При инсталляции 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
Теперь осталась рутина:
- исправить в fstab
UUIDдля/
1.1. добавить опцию компрессии по желанию - исправить конфигурацию 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 должна бы позволить и волкам быть сытым, и овцам целым.
, а первая - нет. Думаю в подтомах они совсем “потеряют” друг друга.