Алексей Федорчук
Первое, что нужно сделать для установки 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
предлагается по умолчанию:
Я, однако, после короткого увлечения модой, вернулся к старой доброй 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 из выпадающего меню:
После чего схема разметки для первого из устройств-участников (как, впрочем, и для второго) стала выглядеть так:
Маленький раздел на первом SSD с Id 83 (Linux native) я предполагал задействовать под каталог /boot
, а его двойника на втором — оставить про запас. Теоретически их можно было бы объединить в RAID Level 1 (softRAID Level 0 не может быть загрузочным устройством), как я некогда проделал для Saucy Salamander. Однако никаких преимуществ при этом я не обнаружил, а вот кое-какие осложнения можно было предвидеть. Например, невозможность загрузки системы через меню GRUB дистрибутива, softRAID не поддерживающего.
Оба больших раздела я планировал объединить в RAID Level 0, и первый шаг в этом направлении — установка соответствующего пакета:
# apt install mdadm
сопровождавшаяся предложением его настройки:
Поскольку настраивать у меня пока было нечего, в соответствующем поле можно было оставить значение по умолчанию — «всё, что потребуется впредь»:
Затем последовало создание программного массива:
# mdadm --create /dev/md0 --level=0 --raid-device=2 /dev/sd[b,c]2
и его разметка:
# cfsisk /dev/md0
с предварительным созданием таблицы разделов, поскольку устройство /dev/md0
воспринималось как целый диск, и выделением двух разделов, уже с Id 8173:
Первый из созданных на массиве разделов (/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
‘а пренебрегать не стоит: при установке простой узкоспециализированной системы с ограниченным набором пакетов и простыми их зависимостями, и при создании платформы для собственного респина, подлежащего тиражированию (или хотя бы установке на машины группы товарищей).
> Здесь опция -m 0 означает отказ от пятипроцентного резервирования
> объёма диска под доступ только root’у — для SSD, которые всё равно
> крайне нежелательно доводить до жизни такой
так и надо было вместо «0» нарисовать какое-нибудь число, чтобы по забывчивости не довести :-)
Совет не для этого конкретного случая (с пустым неформатированным sdc1 и полупустыми sdb1 md0), а вообще.
alex, а вот это очень интересный вопрос: а не выпадает ли зарезервированный объём из круговорота стирания/записи ячеек, увеличивая нагрузку на остальные?
На сайтах производителей ответа на него не найти, как и на остальные вопросы, как работает фирмварь SSD.
Помнится, когда я обзавёлся первой SSD’шкой имени товарища Корсара, вдохновлённый известной статьёй Тсо, искал у них на сайте данные про границу блока стирания. И наткнулся на интересную фразу. Сразу, к сожалению не записал, а потом найти не мог, но смысл был примерно такой: Ребята, не ломайте себе голову, наши инженеры всё уже придумали до вас. Так что выпивайте, закусывайте, наслаждайтесь быстродействием, и пусть вас не волнуют этих глупостей.
на этот вопрос, я думаю, смогут ответить только разработчики этих самых SSD и firmware к ним, мы можем только догадываться, что там происходит в «черном ящике» с секторами. Я оставляю место по старой памяти, семейство Unix использую на серверах, где это актуально.