Моя дорогая Betsy. Нетрадиционные методы установки: debootstrap и softRAID

Алексей Федорчук

Первое, что нужно сделать для установки LMDE на softRAID методом debootstrap‘инга — это любым способом загрузить машину с любого из её официальных Live-носителей, десктоп в данном случае не имеет значения, важно только совпадение архитектуры носителя таковой целевой среды.

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

После этого открывается окно терминала — все дальнейшие действия будут выполняться в CLI. А поскольку все они потребуют привилегий администратора, их желательно получить «навечно», командой

$ sudo -i

или

$ sudo -s

В Live-режиме ни одна из них не потребует пароля, и результат их будет практически одинаков.

А теперь даю вводную установку. Описанные далее манипуляции я выполнял над двумя идентичными SSD SanDisk Extreme 120 GB, подключёнными ко 2-му и 3-му разъёмам SATA-III, то есть выступающими как устройства /dev/sdb и /dev/sdc, остальные накопители (а их у меня не мало) в деле не участвовали. Именно эти два диска с их разделами будут выступать в последующих примерах.

Отступление о fake RAID. Поскольку моя нынешняя материнка, ASRock H97M Anniversary, несёт на себе, как явствует из её имени, чипсет Intel H97, возникло желание пощупать руками реализацию в последнем поддержка fakeRAID: она, эта реализация, обещает сохранение прямого доступа к каждому из входящих в массив накопителей. Что полезно (а может, и необходимо?) для корректной работы таких технологий, как S.M.A.R.T. и TRIM: есть подозрение, что их включение в softRAID является чисто символическим жестом. Увы — вожделения мои не оправдались: скорфгурированный из указанных SSD RAID Level 0 не опознался не только в Live-режиме LMDE, но и ни одним из дистрибутивов, образы которых скопились на моём Zalman ZM-VE300 (об этом полезнейшем устройстве можно поглядеть вот здесь).

Так что далее ни о каком fake RAID говориться не будет. А разговор о softRAID, после получения прав администратора, я начал бы с обнуления таблицы разделов накопителей-участников — просто на всякий случай:

# dd if=/dev/zero of=/dev/sdb bs=512 count=1
# dd if=/dev/zero of=/dev/sdc bs=512 count=1

После чего можно заняться их разметкой. В этот раз я для разнообразия воспользовался утилитой cfdisk, и не пожалел: оказывается, с тех пор, как я применял её последний раз, она несколько изменилась. Так, после запуска командой

# cfdisk /dev/sdb

для начала предлагается создать таблицу разделов, причём gpt предлагается по умолчанию:

lmde_and_raid_01
Я, однако, после короткого увлечения модой, вернулся к старой доброй dos-схеме разметки (в причины вдаваться здесь неуместно), после чего создал на обоих дисках по два первичных раздела

/dev/sdb1 -- 512 МБ, 83 -- Linux
/dev/sdb2 -- 11,3 ГБ, fd -- Linux raid autodetect

/dev/sdc1 -- 512 МБ, 83 -- Linux
/dev/sdc2 -- 11,3 ГБ, fd -- Linux raid autodetect

Идентификатор типа файловой системы (в данном случае fd) выбирается через пункт меню Type из выпадающего меню:

lmde_and_raid_02
После чего схема разметки для первого из устройств-участников (как, впрочем, и для второго) стала выглядеть так:

lmde_and_raid_03
Маленький раздел на первом SSD с Id 83 (Linux native) я предполагал задействовать под каталог /boot, а его двойника на втором — оставить про запас. Теоретически их можно было бы объединить в RAID Level 1 (softRAID Level 0 не может быть загрузочным устройством), как я некогда проделал для Saucy Salamander. Однако никаких преимуществ при этом я не обнаружил, а вот кое-какие осложнения можно было предвидеть. Например, невозможность загрузки системы через меню GRUB дистрибутива, softRAID не поддерживающего.

Оба больших раздела я планировал объединить в RAID Level 0, и первый шаг в этом направлении — установка соответствующего пакета:

# apt install mdadm

сопровождавшаяся предложением его настройки:

lmde_and_raid_04
Поскольку настраивать у меня пока было нечего, в соответствующем поле можно было оставить значение по умолчанию — «всё, что потребуется впредь»:

lmde_and_raid_05
Затем последовало создание программного массива:

# mdadm --create /dev/md0 --level=0 --raid-device=2 /dev/sd[b,c]2

и его разметка:

# cfsisk /dev/md0

с предварительным созданием таблицы разделов, поскольку устройство /dev/md0 воспринималось как целый диск, и выделением двух разделов, уже с Id 8173:

lmde_and_raid_06
Первый из созданных на массиве разделов (/dev/md0p1, 48 ГБ) предназначался под корень файловой иерархии, второй (/dev/md0p2, на оставшиеся 170 с копейками гигабайт) — под каталог /home. Альтернативный вариант, с созданием двух массивов, каждый под свою ветвь файловой иерархии, будет рассмотрен в очерке про установку с mini.iso.

Теперь надлежало создать файловые системы, что я и проделал таким образом:

# mkfs.ext4 -m 0 -O ^has_journal /dev/sdb1
# mkfs.ext4 -m 0 /dev/md0p1
# mkfs.ext4 -m 0 /dev/md0p2

Здесь опция -m 0 означает отказ от пятипроцентного резервирования объёма диска под доступ только root’у — для SSD, которые всё равно крайне нежелательно доводить до жизни такой, это не имеет смысла. А опция -O ^has_journal отключает журналирование, которое на загрузочном разделе тоже не нужно.

Теперь наступает черёд монтирования файловых систем, первым делом, конечно, той, что будет выступать как корневая:

# mount /dev/md0p1 /mnt

Вслед за чем создаются точки монтирования для её ветвей:

# mkdir /mnt/boot
# mkdir /mnt/home

И в них монтируются соответствующие разделы:

# mount /dev/sdb1 /mnt/boot
# mount /dev/md0p2 /mnt/home

Плацдарм для развёртывания core system готов, можно приступать к его наполнению. Что первым делом потребует установки соответствующего пакета:

# apt install debootstrap

После чего выполняется собственно бутстраппинг:

# debootstrap jessie /mnt

Имя jessie указывается здесь за отсуствием собственного скрипта установки базовой системы Betsy. Как, впрочем, и всех других вариантов для дистрибутивов Mint, в чём легко убедиться, просмотрев каталог /usr/share/debootstrap/scripts/: все имеющиеся там имена относятся только к веткам Debian и Ubuntu.

Приближается время chroot — однако она требует некоторых предварительных действий. Во-первых, для упрощения жизни я копирую из материнской системы в целевую каталог с настройками для apt — не зря же я начал с определения самых быстрых зеркал репозиториев проекта Mint. Ткеперь они потребуются для превращения первозданной Jessie в будущую Betsy. Сначала удаляются следы старых конфигов чистого Debian’а:


# rm -Rf /mnt/etc/apt

А затем копируются новые, Mint’овские конфиги:


# cp -Rp /etc/apt /mnt/etc

С опцией -R всё понятно — она обеспечивает рекурсивное копирование вложенных подкаталогов (её можно заменить и опцией -r, но я действую по привычке и по старинке). И про опцию -p, сохраняющую атрибуты копируемых файлов, забывать не следует: файлы в /etc/apt должны иметь права доступа 644, а вложенные подкаталоги — 755, тогда как при копировании «в лоб» (в том числе и через Midnigth Commander) они скидываются до запрета на чтение и просмотр для всех, кроме root’а.

Кроме этого, в данной ситуации обычно рекомендуют скопировать из материнской системы файлы /etc/hostname и /etc/hosts, а также отредактировать файл /mnt/etc/network/interfaces (или ему подобный). Но в моём случае этого не требовалось — как и в любом случае подключения к Интернету через нормального провайдера, с нормальным DHCP.

Далее, желательно заранее отредактировать файл /mnt/etc/fstab — изначально в «debootstrap’нутой» системе он пуст. Монтируемые в него разделы можно прописать в него по именам верхнего уровня:

/dev/md0p1 / ext4 defaults,noatime,discard 0 1
/dev/sdb1 /boot ext4 defaults,noatime,discard 0 0
/dev/md0p2 /home ext4 defaults,noatime,discard 0 0

А можно, например, по именам by-id — их значения легко узнать такой командой:

# ls -l /dev/disk/by-id

На мой взгляд, этот путь предпочтительней принятого в Ubuntu’идах и унаследованный всеми дистрибутивами проекта Mint именования by-uuid, однако в чужой монастырь со своим устаном не лезут. И потому определяю UUID’ы всех нужных разделов, начиная с первого:

# sudo blkid /dev/sdb1
[sudo] password for alv: 
/dev/sdb1: LABEL="deboot" UUID="1efade1b-bdd0-4e7d-bce6-4ce5d5c84a4e" TYPE="ext4" PARTUUID="36e44b43-01"

А затем и для обоих разделов на RAID’е:

# sudo blkid /dev/md0p1
# sudo blkid /dev/md0p2

Впрочем, значения UUID можно посмотреть и проще:

# ls -l /dev/disk/by-uuid

Полученные тем или иным способом «простенькие» значения вписываются в /mnt/etc/fstab:

UUID=71ba9c60-... / ext4 rw,errors=remount-ro,noatime,discard 0 1

И так далее. Кроме того, я всегда добавляю и такую строку:

tmpfs /tmp tmpfs defaults,noatime 0 0

Она обеспечивает монтирование в каталог /tmp файловой системы в оперативной памяти, но это — сугубо дело вкуса.

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

# mount --bind /dev  /mnt/dev

То есть связанное монтирование каталога для файлов устройств (а имена их гененрируются автоматически) в будущую файловую систему. Одновременно рекомендуется поступить тем же образом и с двумя другими виртуальными файловыми системами:

# mount --bind /proc /mnt/proc
# mount --bind /sys  /mnt/sys

И вот теперь наступает волнующий момент смены корня:

# chroot /mnt /bin/bash --login

Сразу после чего надо обновить кеш доступных репозиториев — не зня же мы копировали конфиги apt‘а:

# apt-get update

Далее обеспечиваю себе работу с реализацией apt для Mint’а:

# apt-get install mintsystem

И теперь на команду apt будет откликаться не убогий /usr/bin/apt из оноимённого комплекта, а богатый /usr/local/bin/apt из только что инсталлированного пакета. Чем я немедленно и воспользовался, обновив для очистки совести кеш

# apt update

установил пакет для работы с softRAID:

# apt install mdadm

Проверка командой

# mdadm --detail /dev/md0

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

/dev/md0:
        Version : 1.2
  Creation Time : Thu Jun  4 18:42:42 2015
     Raid Level : raid0
     Array Size : 233259008 (222.45 GiB 238.86 GB)
   Raid Devices : 2
  Total Devices : 2
    Persistence : Superblock is persistent

    Update Time : Thu Jun  4 18:42:42 2015
          State : clean 
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

     Chunk Size : 512K

           Name : mint:0  (local to host mint)
           UUID : 357ddf5c:573c02c4:0b886267:d3409cbc
         Events : 0

    Number   Major   Minor   RaidDevice State
       0       8       18        0      active sync   /dev/sdb2
       1       8       34        1      active sync   /dev/sdc2

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

# apt install locales
# locale-gen en_US.UTF-8 ru_RU.UTF-8

Во-вторых, не худо установить ядро системы:

# apt install linux-image-amd64

И обеспечить возможность его загрузки путём установки загрузчика:

# apt install grub2-common grub-pc os-prober

В ходе этой процедуры будет предложено выбрать устройство для размещения кода GRUB stage1 — таковым следует назначить /dev/sdb, не забыв (заранее или в ходе будущей перезагрузки) соответствующим образом настроить BIOS.

Здесь опять же на всякий пожарный случай можно проверить, что загрузчик правильно опознаёт будущую корневую файловую систему:

# grub-probe /

Ответом на что в данном случае будет:

ext2

Видимо, так GRUB называет файловую систему ext4 с отключённым журналированием.

И теперь осталось только решить, в качестве кого мы будем авторизоваться в будущей системе. Обычно здесь рекомендуется ограничиться заданием пароля администратора командой

# passwd

и двухкратным вводом оного: поскольку команда эта не считает себя умней применителя, то докучать моралью строгой, на счёт краткости пароля или его слабости, она не будет, скушав секретное слово хоть в виде 123 (только не подумайте, что я рекомендую использовать именно такое — каждый сам для себя находит компромисс между боязнью мировых злодеев и комфортом работы).

Однако, с точки зрения идеологии дистрибутивов Mint, анаследованной от Ubuntu, это позорно и преступно. Поэтому, помятуя всё ту же пословицу про устав и монстырь, я отказался от пароля для доступа к root-аккаунту, а вместо этого создал пользовательский аккаунт для себя, любимого, дав команду

# adduser alv

Которая ответила мне таким выводом:

Adding user `alv' ...
Adding new group `alv' (1000) ...
Adding new user `alv' (1000) with group `alv' ...
Creating home directory `/home/alv' ...
Copying files from `/etc/skel' ...

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

А вот о чём нельзя забыть ни в коем случае — это о команде sudo, установив одноимённый пакет (в core system он не входит):

# apt install sudo

Столь же важно проверить файл /mnt/etc/sudoers — он должен, в числе прочих, обязательно содержать такие сторки:

Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
...
root ALL=(ALL:ALL) ALL
...
%sudo ALL=(ALL:ALL) ALL

Ну и на последок надо включить себя в члены дополнительных групп, обеспечивающих доступ к административным привилегиям (помимо основной, alv, членство в которой возникает по факту создания аккаунта):

usermod -G adm,sudo alv

На самом деле может потребоваться и принадлежность к другим дополнительным группам (например, audio и video, но это можно будет обеспечить потом, в рабочем порядке, и более комфортным способом, например, с помощью графической утилиты cinnamon-settings-users.

А пока можно завязывать с первичной установкой, выйдя из chroot-окружения:

# exit

Размонтировав все смонтированные ранее файловые системы:

# umount /mnt/home 
# umount /mnt/boot 
# umount /mnt/dev
# umount /mnt/proc
# umount /mnt/sys
# umount /mnt

И дав команду перезагрузки:

# reboot

Если всё было сделано правильно (и я в своём описании не забыл чего-то важного), то после этого должно появиться сначала меню GRUB’а, затем — приглашение ввести логин и пароль, а потом приглашение командной строки Bash.

Конечно, впереди — самый охмурёж, то есть наращивание системы мясом. Описывать всю процедуру я не буду. Скажу только, что занятие это долгое и скучное, требующее учёта множества мелочей и установки пакетов, о существовании которых я и не слышал. Причём автоматическое разрешение зависимостей, хотя и работает неизменно превосходно, в данной ситуации не спасает. Чтобы не упустить ни одну из этих самых важных мелочей, надо

или разрешить гуртом установку рекомендованных пакетов — и тогда окончательно распрощаться с мечтой о системе без всего лишнего,

или кропотливо выискивать и устанавливать нужные пакеты по одному — но в этом случае затраты времени переходят все разумные пределы; причём без гарантии, что ненужное таки пролезет сквозь самое мелкое сито как чья-то неприметная зависимость.

Поэтому, пройдя этим тернистым путём, я счёл, что, с одной стороны, «могём, начальник, кто сказал, что не могём?». Со стороны же другой, решил, что не стоит дивчинка вы… пардон, овчинка выделки, и обратился ко второму методу — установке с mini.iso. О чём — в следующем очерке.

Подводя же итог очерку этому, сформулирую своё ИМХО: debootstrap безусловно не оправдан как метод установки индивидуальной системы универсального назначения на одном отдельно взятом десктопе: как неоднократно говаривал мой коллега Сергей Голубев, удалить что-нибудь ненужное обычно проще и быстрее, чем это «что-нибудь» не установить. И в общем случае я с ним согласен. Но в двух ситуациях методом debootstrap‘а пренебрегать не стоит: при установке простой узкоспециализированной системы с ограниченным набором пакетов и простыми их зависимостями, и при создании платформы для собственного респина, подлежащего тиражированию (или хотя бы установке на машины группы товарищей).

Предварительное оглавление

Моя дорогая Betsy. Нетрадиционные методы установки: debootstrap и softRAID: 3 комментария

  1. > Здесь опция -m 0 означает отказ от пятипроцентного резервирования
    > объёма диска под доступ только root’у — для SSD, которые всё равно
    > крайне нежелательно доводить до жизни такой
    так и надо было вместо «0» нарисовать какое-нибудь число, чтобы по забывчивости не довести :-)
    Совет не для этого конкретного случая (с пустым неформатированным sdc1 и полупустыми sdb1 md0), а вообще.

  2. alex, а вот это очень интересный вопрос: а не выпадает ли зарезервированный объём из круговорота стирания/записи ячеек, увеличивая нагрузку на остальные?
    На сайтах производителей ответа на него не найти, как и на остальные вопросы, как работает фирмварь SSD.
    Помнится, когда я обзавёлся первой SSD’шкой имени товарища Корсара, вдохновлённый известной статьёй Тсо, искал у них на сайте данные про границу блока стирания. И наткнулся на интересную фразу. Сразу, к сожалению не записал, а потом найти не мог, но смысл был примерно такой: Ребята, не ломайте себе голову, наши инженеры всё уже придумали до вас. Так что выпивайте, закусывайте, наслаждайтесь быстродействием, и пусть вас не волнуют этих глупостей.

  3. на этот вопрос, я думаю, смогут ответить только разработчики этих самых SSD и firmware к ним, мы можем только догадываться, что там происходит в «черном ящике» с секторами. Я оставляю место по старой памяти, семейство Unix использую на серверах, где это актуально.

Добавить комментарий