Переносной Arch

--= Предисловие =--
В связи с участившимися вопросами пользователей, предпринята попытка составить небольшое пособие по установке Arch Linux на съемный носитель. Статья делалась как обзорная к действиям , опробованным нами лично. Поэтому на полноту освещаемой темы оно не претендует. Также были добавлены некоторые интересные моменты, которые относятся к теме косвенно, но могут пригодится или снизить поток побочных вопросов к теме.
--= Исходные данные =--
1. Имеем установленную систему, готовую систему Arch Linux.
2. Имеем носитель в виде флешки (Размер и производитель выбираются исключительно из личных предпочтений и поставленных задач или др. исходных данных).
3. Список пакетов , которые должны быть установлены в систему, для работоспобности примеров из нашего текста. Опять же выбор софта, например для
разметки ЖД, носит избирательный характер.
extra/gparted
Графическая утилита разметки ЖД, кто не в курсе.
core/btrfs-progs
Собственно файловая система btrfs для вариантов с ее применением.
extra/rsync
Синхронизатор, который будет использован в качестве примеров резервирования и восстановления систем.
--= Соглашения =--
Все команды, идущие после приглашения "$", выполняются от обычного пользователя системы.
Все команды, идущие после приглашения "#", выполняются от пользователя root или др. пользователя, обладающего привелегиями администратора системы.
--= Поехали =--
1. Подготовка флешки
Вставляем флешку в аппарат с исходной системой (Arch Linux) и убеждаемся, что оборудование определилось ядром.
	$ lsusb
	...
	Bus 002 Device 004: ID 125f:385a A-DATA Technology Co.,Ltd.
Примечание: В данный момент показано , как может выглядить вывод у обладателей съемного носителя фирмы A-Data.
Создание разделов
Небольшой шаблон разметки, который будет использован далее по тексту:
Примечание: В скобках показаны данные, использовавшиеся в примере. Т.е. могут отличаться от Ваших данных и предпочтений.
1. FTEMP fat32 (1 Гб)
2. FBOOT /boot ext2 50 - 100 Мб
3. FROOT / btrfs или ext2 Все остальное (~6.5 Гб)
Первый раздел создан скорее на фсякий пожарный случай, чтобы без особых напильников применить флешку в обыденных целях на машинах Windows; также, проверенная временем система fat , дефакто, является самой распространненой среди поддерживаемых «из коробки» фс на современных ОС. Так что эдакий вменяемый, вездезаводимый буфер будет не лишним.
Второй раздел ext2 будет использован в качестве /boot раздела. Если читатель , в отличие от нас, не помышляет всякими джедайскими приемами вроде полного или не полного шифрования и прочего, то отдельный вариант не является обязательным.
Третий раздел - собственно сама система. В варианте с флешдрайвом мы пользуемся молодой btrfs со сжатием. Например, лептопная система одного из авторов (легкий/свежий вариант, буквально арч был раскручен 3 дня назад с нуля, для сугубо профилактических целей) имела размер 6-8Г , а теперь на флешносителе с btrfs занимает 1-3Г.
Сжатие уменьшает частоту обращения к диску, что увеличивает срок службы и производительность. (При использовании ext2 появлялись значительные фризы системы, а на Reiser4, со сжатием, проявлялось заметное торможение, хотя и меньше чем в варианте с ext2. Видимо btrfs лучше оптимизирована для работы с твердотельными накопителями.)
ВАЖНО (!): На данный момент btrfs считается нестабильной и не имеет средства для исправления ошибок ФС. Так что следует задуматься о ACKUP-ах. Один из авторов лично наткнулся на такой финт, в результате некоторых манипуляций, однако систему это не убило и она до сих пор работает в неотформатированном варианте.
Довольно привлекательной выглядит f2fs, созданная специально для твердотельных накопителей, добавленная в ядро 3.9. Не имеет функций сжатия анных налету. Нами пока не испытана.
Примечание: Примеры резервирования и восстановления будут показаны в конце статьи.
В случае другого носителя, прибегать к btrfs не обязательно. Например на usb-hdd, в который мы с успехом можем клонировать систему 1 в 1 без сжатия.
При необходимости выделите раздел для /home с ext2 или другой ФС, если есть желание можете вынести и др. разделы на отдельные партиции.

Напомним, что мы использовали gparted для практических действий с ЖД. Сейчас как раз самое подходящее время перейти к практике и разметить будущую флешку.

2. Установка базовых компонентов системы
С подготовкой usb носителя покончено, приступаем к установке системы на базе Arch Linux.
Монтируем корневой раздел в /mnt
	# mount -L FROOT /mnt -o compress-force,ssd
Примечание:
Опции compress, compress-force, compress=lzo позволяют выполнять прозрачное сжатие данных в файловой системе; опция force позволяет выполнять компрессию файлов, которые обычно имеют низкий коэффициент сжатия (таких, как сжатые аудио или видео форматы); lzo - алгоритм сжатия (поумолчанию zlib). Для работы lzo необходимо установить пакет lzo2. Опция ssd полезна для тех пользователей, которые имеют в своем распоряжении твердотельные накопители (SSD); она включает несколько способов оптимизации, которые повышают производительность этих already-speed устройств.
Монтирование второго раздела флешносителя в иерархию будущей системы как раздел /boot .
	# mkdir /mnt/boot
	# mount -L FBOOT /mnt/boot
Перед началом установки системы необходимо установить пакет arch-install-scripts с установочными скриптами.
Далее установка и настройка по Вики Установка базовой системы, учитывая настройки описанные ниже.

3. Конфигурирование системы на флеш
Приводим /etc/mkinitcpio.conf (/mnt/etc/mkinitcpio.conf) новой системы к сл. содержанию. Находим параметры HOOKS и убираем autodetect (необходимо, чтобы загрузочный образ не был привязан к железкам, на которых производится сборка). Остальное меняем на свой лад.
	HOOKS="base udev modconf block filesystems keyboard fsck"
	...
	COMPRESSION="xz"

При создании fstab необходимо пользоваться UUID для однозначного определения разделов на разном оборудовании.
	# genfstab -p -U /mnt >> /mnt/etc/fstab
Также чтобы на флешку записывалось меньше данных, можно монтировать /var/tmp и /var/log в оперативную память. Для этого добавляем в fstab строки:
tmpfs /tmp   tmpfs   nodev,nosuid   0   0
tmpfs /var/tmp tmpfs defaults 0 0
tmpfs /var/log tmpfs defaults 0 0

Далее перейдите в свою установленную систему с помощью chroot.
	# arch-chroot /mnt
И настройте систему в соответствии с Вики.
Установка grub2.
	# pacman -S grub
Генерация конфига
	# grub-mkconfig -o /boot/grub/grub.cfg
Закапываем гроб. Положите лопату товарищ, это была метафора. =)
Прописываем загрузчик в mbr флешдрайва.
ВАЖНО (!): Далее /dev/sdX - Ваша флешка (например /dev/sdg).
	# grub-install /dev/sdX
Пользователи
Установка пароля root.
	# passwd root
Добавление обычного пользователя можно подсмотреть здесь

И не забудьте установить netcfg или wicd, вобщем, то что используете для работы сети (и iputils, вдруг ping понадобится :)
Система готова к употреблению. Далее можно устанавливать необходимые пакеты, настраивать систему или ребутнуться на флешку и работать там.
Например, поставим открытые драйвера для видео систем на популярные случаи.
	# pacman -S xf86-video-vesa xf86-video-nouveau xf86-video-intel xf86-video-ati
Далее ставьте то, что нужно Вам. Необязательно сидеть, расчесывая свою тыковку, и вспоминать все. Доставить нужное Вы успеете потом в любое время.
Выходим из chroot обратно на светлую сторону...тьфу, в систему-донор/первоначальную систему.
	# exit
Отцепляем балласт.
	# umount /mnt/boot
	# umount /mnt
Пробуем загрузится с флешки.

ДОПОЛНЕНИЕ. "Примеры резервирования системы"
1. Первый на повестке способ, утилита dd.
Если флешка небольшая, то проще всего делать ее полный слепок с помощью dd.
Резервирование
	# dd if=/dev/sdX of=flasharch.img
Восстановление соответственно
	# dd if=flasharch.img of=/dev/sdX
Примечание: Данный метод имеет минусы. Копирование, а тем более восстановление, занимает много времени, даже для флешки в 2 гб. При больших размерах даже не рискуем пользоваться данным методом. Плюсом ,пожалуй, можно назвать простоту метода и отсутствие необходимости монирования флешносителя.
2. Второй по списку, но не по значению - rsync.
При первом (свежем) копировании время, затрачиваемое на выполнение операции, приблизительно схоже с предыдущим вариантом. Однако, начиная с второго раза, экономия времени видна невооруженным взглядом. Секрета тут нет никакого.
Знакомые с утилитой пользователи заметят, что в резервировании участвуют только файлы, подвергшиеся изменениям с момента последнего сеанса синхронизации.
Примечание: Минус - Необходимость монтирования флешки для бекапа, что бывает очень накладным делом, например, если объект бекапа зашифрован и др.
	# mount -L FROOT /mnt -o compress-force,ssd
	# mount -L FBOOT /mnt/boot
	$ mkdir /home/user/flashbackup
Примечание: Это директория для резервирования, как можно догадаться из названия. Она может находится где угодно, от текущего раздела ЖД, до удаленного сервера.
	# rsync -av --delete --delete-before  /home/user/flashbackup/
Примечание: интересная функция --delete для новичков, она позволяет удалять несуществующие файлы резервируемой системы. Говоря проще, для варианта 1 к 1.
	# umount /mnt/boot
	# umount /mnt
Процесс восстановления.
	# rsync -av --delete --delete-before  /home/user/flashbackup/ /mnt/
Аналогично можно копировать ОС с жесткого диска на флешку или usb hdd, после копирования произведите настройку выше описаных конфигурационных файлов (fstab, grub.conf и пр. описанные выше), не забудьте пересобрать загрузочный образ ядра и установить загрузчик.
Пример:
# mkdir /mnt/root
# mount --bind / /mnt/root
# mount --bind /boot /mnt/root/boot      # Если /boot на отдельном разделе
# rsync -av --delete --delete-before /mnt/root/ /mnt/flashroot/     # Где /mnt/flashroot путь к примонтированой флешке.
# umount /mnt/root/boot
# umount /mnt/root


Шифрование корня системы механизмами truecrypt

--= Атрибуты =--
Авторы: Пользователи форума sleepycat и jim945
Конт. информация: sleepyjinn@jabber.ru , jim945@jabber.ru
Текст создан: 23.02.2012
Последнее обновление: 22.06.2013
Lupus pilum mutat, non mentem.
Большое спасибо за столь обстоятельное руководство.
Немного смутил один момент:
root=UUID= заменить на root=/dev/disk/by-uuid/
Возможно, лучше записать так
root=UUID=идентификатор_фс заменить на root=/dev/disk/by-uuid/идентификатор_фс
А то я было подумал сначала, что UUID это и есть значение, а второй знак “=” добавлен по ошибке
И ещё, хотелось бы знать, почему такая замена необходима.
Отлично)
Все не читал ибо пока за ненадобностью, но вполне неплохо)
В вики это, в вики))
lampslave
Немного смутил один момент:
root=UUID= заменить на root=/dev/disk/by-uuid/
Возможно, лучше записать так
root=UUID=идентификатор_фс заменить на root=/dev/disk/by-uuid/идентификатор_фс
А то я было подумал сначала, что UUID это и есть значение, а второй знак “=” добавлен по ошибке
И ещё, хотелось бы знать, почему такая замена необходима.

щас махнем, как ТС вернется. Это одно из “странных мест”. Дело в том, что изначально этой операции не было. Но при проверке практических дейсвий в тексте “стандартная” форма записи перестала работать, ну мы, не долго думая, попробовали “на старый лад” и вроде зацепился корень при загрузке…. Обязательно поправим, напишем подробнее, я так понимаю , что понятней показать до и после…
Лозунг у них был такой: "Познание бесконечности требует бесконечного времени". С этим я не спорил, но они делали из этого неожиданный вывод: "А потому работай не работай — все едино". И в интересах неувеличения энтропии Вселенной они не работали. (с)
maxys146
В вики это, в вики
не уверен, что нужно. Тут нету ничего сверестественного и многое уже там расписано.
maxys146
Большое спасибо за столь обстоятельное руководство.
тоже самое. =) Не-за-что.
Самое тяжелое было вылизать и выправить текст до рабочего варианта =)
До конца думали “ а нужна ли вообще подобная статья”, но все же она увидела свет, так что, мы рады каждому, кому это стало полезным…не зря мучали клавиатуру и флешки…
Лозунг у них был такой: "Познание бесконечности требует бесконечного времени". С этим я не спорил, но они делали из этого неожиданный вывод: "А потому работай не работай — все едино". И в интересах неувеличения энтропии Вселенной они не работали. (с)
А с проблемой udev/kmod что делали?
Насколько я заметил, теперь эту “сладкую парочку” нужно руками приспосабливать в каждому компьютеру, на котором ядро использует модули, с которыми глючит новый udev. Я пока не придумал, как этого избежать, не откатывая на старый udev и module-init-tools.

Кроме того, некоторые модули (i915 на некоторых чипсетах, к примеру) нормально работают только если загрузить этот модуль до старта udevd. Если модуль добавлен в машиноспецифический initcpio, это незаметно, но на переносной системе мне пришлось громоздить весьма забубенный костыль.
sleepycat
щас махнем, как ТС вернется. Это одно из “странных мест”. Дело в том, что изначально этой операции не было. Но при проверке практических дейсвий в тексте “стандартная” форма записи перестала работать
Есть такое дело. Суть в том, что форма UUID= во время инициализации все равно переводится в /dev/, но переводится до того как будет использована задержка rootdelay (даже не заданный этот параметр имеет значение 5с).
Поэтому получается следующая упрощенная форма
1) по UUID=
UUID= –(с использованием blkid, вот тут-то частенько и обламываются usb'ишки)–> /dev/ –> задержка –> монтирование
2) по /dev/disk/by-
/dev/ –> задержка –> монтирование
У меня тоже после какого-то обновления mkinitcpio флешка стала монтироваться раз через 5 пока не перешел на /dev/disk/by-
Natrio
А с проблемой udev/kmod что делали?
xм, честно? Ну отвечу только за себя - ничего….я эту проблему не встречал, пока что .(последняя флешка зделана была вчера, проверил на всем что было. К сожалению проверить массово на всем сущесвующем нет)
Лозунг у них был такой: "Познание бесконечности требует бесконечного времени". С этим я не спорил, но они делали из этого неожиданный вывод: "А потому работай не работай — все едино". И в интересах неувеличения энтропии Вселенной они не работали. (с)
Natrio
А с проблемой udev/kmod что делали?
Насколько я заметил, теперь эту “сладкую парочку” нужно руками приспосабливать в каждому компьютеру, на котором ядро использует модули, с которыми глючит новый udev.
Пока не сталкивался с такой проблемой, т.к. кмод на небольшом количестве железа испробован.
Natrio
Кроме того, некоторые модули (i915 на некоторых чипсетах, к примеру) нормально работают только если загрузить этот модуль до старта udevd.
Из ближайшего, что помню, пробовал на i945. Вроде полет был нормальный. Но на этой железке всего лишь переразбивал диск и слушал музыку.
Было бы интересно узнать подробнее об этих проблемах, т.к. у каждого свои проблемы. И погуглю конечно.

Natrio
машиноспецифический initcpio
На сколько я понял машиноспецифическим его делает хук autodetect, который убираем.

lampslave
Возможно, лучше записать так
root=UUID=идентификатор_фс заменить на root=/dev/disk/by-uuid/идентификатор_фс
Исправлено.
Добавлена пара коментариев для fstab и mkinitcpio (autodetect)
Lupus pilum mutat, non mentem.
Rdf
У меня тоже после какого-то обновления mkinitcpio флешка стала монтироваться раз через 5 пока не перешел на /dev/disk/by-
Насколько я понимаю эта проблема только для внешних устройств? Т.к. системы на внинтах запускаются именно по root=UUID= и проблемы нет.
Столкнулся с ней только при написании этой статьи. 4-5 мес. назад этой проблемы не было, а потом я стал шифровать корень трукриптом, соответственно использовать другие способы загрузки, и не поймал момента появления этой проблемы.
Lupus pilum mutat, non mentem.
 
Зарегистрироваться или войдите чтобы оставить сообщение.