Как обычно, в Ташкенте в субботу снова пройдет семинар по линуксу. В этот раз затронем тему пакетных менеджеров в линуксе. Вот готовлю материал уже. Подробнее тут:
http://forum.linux.uz/index.php/topic,1009.0.html
И тут:
http://forum.linux.uz/index.php/topic,1002.0.html
Отключаем initrd в убунте.
Недавно провел эксперимент - просто отключил в грабе initrd. Система спокойно и без ругани загрузилась. Самые необходимые модули уже встроены в ядро, даже ext4. Можете проверить сами и убедиться.
В грабе, на строчке с выбором ядра, жмем букву "e" на клаве, стрелками выбираем строчку со словом "initrd" и нажимаем букву "d". Далее стрелками снова выбираем строчку со словом "kernel ..." и секцию "root=UUID=........." заменяем на "root=/dev/sdaX", где Х - номер раздела, куда установлена убунту. Нажимаем "ENTER" и потом букву "b". Если система загрузится нормально - можете уже исправить конфиг граба. Убунту будет грузиться еще быстрее.
Чтобы отключить уже в грабе, достаточно открыть его конфиг
gksudo gedit /boot/grub/menu.lst
найти там строчку типа
initrd /boot/initrd.img-2.6.28-14-generic
и закомментировать ее, то есть поставить перед ней знак решетки "#"
# initrd /boot/initrd.img-2.6.28-14-generic
Кто использует уже скомпиленные ядра в deb-пакетах, скаченные с http://kernel.ubuntu.com/~kernel-ppa/mainline/, может тоже уже не использовать initrd.
Только хочу предупредить, что initrd все равно иногда просто необходим системе. Например, если у вас проблемы с файловой системой, инитрд сначала проверить ее на ошибки, исправит их, а потом только подмонтирует и продолжит загрузку. Единственный плюс от его отключения - это опять уменьшение времени загрузки убунты.
В грабе, на строчке с выбором ядра, жмем букву "e" на клаве, стрелками выбираем строчку со словом "initrd" и нажимаем букву "d". Далее стрелками снова выбираем строчку со словом "kernel ..." и секцию "root=UUID=........." заменяем на "root=/dev/sdaX", где Х - номер раздела, куда установлена убунту. Нажимаем "ENTER" и потом букву "b". Если система загрузится нормально - можете уже исправить конфиг граба. Убунту будет грузиться еще быстрее.
Чтобы отключить уже в грабе, достаточно открыть его конфиг
gksudo gedit /boot/grub/menu.lst
найти там строчку типа
initrd /boot/initrd.img-2.6.28-14-generic
и закомментировать ее, то есть поставить перед ней знак решетки "#"
# initrd /boot/initrd.img-2.6.28-14-generic
Кто использует уже скомпиленные ядра в deb-пакетах, скаченные с http://kernel.ubuntu.com/~kernel-ppa/mainline/, может тоже уже не использовать initrd.
Только хочу предупредить, что initrd все равно иногда просто необходим системе. Например, если у вас проблемы с файловой системой, инитрд сначала проверить ее на ошибки, исправит их, а потом только подмонтирует и продолжит загрузку. Единственный плюс от его отключения - это опять уменьшение времени загрузки убунты.
Программа "/sbin/init" и стартовые скрипты. Часть 1.
После того, как grub загрузил ядро линукса, это самое ядро по умолчанию запускает программу "/sbin/init" (в параметрах ядра можно указать другой путь до этой программы, "init=/usr/bin/my_init" к примеру или "init=/bin/bash" - чтобы запустить напрямую после ядра сразу bash). Ядро может запустить только одну программу, но эта программа должна взять на себя обязанность загружать все остальное. В winnt, кстати, используется почти такая же система - там роль "/sbin/init" играет программа "smss.exe". Сейчас, с использованием initrd-образов в большинстве дистрибутивах, программа init сначала запускается с этого самого образа, но потом все равно запускает "/sbin/init" с корневого раздела. Для того, чтобы легче было манипулировать с настройками загрузки системы и чтобы проще было добавлять сторонние программы в "автозагрузку", init использует конфиги, скрипты и т.д. Чаще всего - в текстовом формате. То есть, ядро запускает "/sbin/init", а тот в свою очередь уже запускает по порядку стартовые скрипты или парсит текстовый конфиг. В некоторых случаях же, "/sbin/init" сам представляет из себя шелл-скрипт, как на том-же образе initrd.
Загрузка всей системы - довольно сложный процесс. В него входит инициализация udev, hal и многого другого. Ради гибкости настроек и совместимости, в большинстве случаев, теряется производительность. Скрипты и конфиги для инита уже переросли в целые системы, пакеты с кучей файлов.
Долгое время в *NIX системах использовалась система стартовых скриптов sysvinit. Сейчас же sysvinit сильно устарел и на его смену пришло очень много других вариантов - InitNG, Upstart, runit, eINIT, Kyuba... В убунте к примеру уже используется upstart, в генту - initng.
В общем, в следующих частях этой темы и опишу различия этих систем, сделаю краткий обзор. Потом постараюсь описать работу убунтовского Upstart. А в будущем, с друзьями, планирую написать свой простенький init. В основном ради экспериментов, для опыта и для примеров.
Загрузка всей системы - довольно сложный процесс. В него входит инициализация udev, hal и многого другого. Ради гибкости настроек и совместимости, в большинстве случаев, теряется производительность. Скрипты и конфиги для инита уже переросли в целые системы, пакеты с кучей файлов.
Долгое время в *NIX системах использовалась система стартовых скриптов sysvinit. Сейчас же sysvinit сильно устарел и на его смену пришло очень много других вариантов - InitNG, Upstart, runit, eINIT, Kyuba... В убунте к примеру уже используется upstart, в генту - initng.
В общем, в следующих частях этой темы и опишу различия этих систем, сделаю краткий обзор. Потом постараюсь описать работу убунтовского Upstart. А в будущем, с друзьями, планирую написать свой простенький init. В основном ради экспериментов, для опыта и для примеров.
Программа "/sbin/init" и стартовые скрипты. Часть 2.
Краткий обзор некоторых клонов init:
Upstart (http://upstart.ubuntu.com/ http://en.wikipedia.org/wiki/Upstart)
Загружает сервисы по событиям.
InitNG (http://www.initng.org/ http://en.wikipedia.org/wiki/Initng)
eINIT (http://en.wikipedia.org/wiki/Einit)
minit (http://www.fefe.de/minit/)
cinit (http://linux.schottelius.org/cinit/)
twsinit (http://www.energymech.net/users/proton/)
runit (http://smarden.org/runit/)
Kyuba (http://kyuba.org/)
myinit (http://sourceforge.net/projects/myinit/)
Ссылки:
http://www.freesource.info/wiki/TZ/initscripts?show_files=1 (Описание работы sysvinit, upstart и initng на русском языке)
http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/ru-RU/Installation_Guide/s2-boot-init-shutdown-init.html
http://en.wikipedia.org/wiki/Init (Страница о /sbin/init в википедии на английском языке)
http://www.busybox.net/
http://users.rsise.anu.edu.au/~okeefe/p2b/power2bash/power2bash.html (Описание загрузки линукса от включения питания до приглашения bash на английском языке)
http://wiz.su/2008/03/06/kak-zagruzhaetsya-linux/ (Пример использования runit с простыми скриптами - на русском языке)
http://ru.wikipedia.org/wiki/Процесс_загрузки_Linux (Процесс загрузки Linux в википедии на русском языке)
http://www.linuxshare.ru/docs/distro/lfs/lfs6/chapter07/usage.html (Информация о работе стартовых скриптов из LFS, тоже на русском языке)
http://wiki.kryukov.biz/wiki/Система_инициализации_Slackware_Linux (Инит-скрипты в слаке, на русском)
Upstart (http://upstart.ubuntu.com/ http://en.wikipedia.org/wiki/Upstart)
Загружает сервисы по событиям.
InitNG (http://www.initng.org/ http://en.wikipedia.org/wiki/Initng)
eINIT (http://en.wikipedia.org/wiki/Einit)
minit (http://www.fefe.de/minit/)
cinit (http://linux.schottelius.org/cinit/)
twsinit (http://www.energymech.net/users/proton/)
runit (http://smarden.org/runit/)
Kyuba (http://kyuba.org/)
myinit (http://sourceforge.net/projects/myinit/)
Ссылки:
http://www.freesource.info/wiki/TZ/initscripts?show_files=1 (Описание работы sysvinit, upstart и initng на русском языке)
http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/ru-RU/Installation_Guide/s2-boot-init-shutdown-init.html
http://en.wikipedia.org/wiki/Init (Страница о /sbin/init в википедии на английском языке)
http://www.busybox.net/
http://users.rsise.anu.edu.au/~okeefe/p2b/power2bash/power2bash.html (Описание загрузки линукса от включения питания до приглашения bash на английском языке)
http://wiz.su/2008/03/06/kak-zagruzhaetsya-linux/ (Пример использования runit с простыми скриптами - на русском языке)
http://ru.wikipedia.org/wiki/Процесс_загрузки_Linux (Процесс загрузки Linux в википедии на русском языке)
http://www.linuxshare.ru/docs/distro/lfs/lfs6/chapter07/usage.html (Информация о работе стартовых скриптов из LFS, тоже на русском языке)
http://wiki.kryukov.biz/wiki/Система_инициализации_Slackware_Linux (Инит-скрипты в слаке, на русском)
Linux-Сообщество Узбекистана
Так как решил снова заняться сообществом, большинство моих сил будут направлены на
http://www.linux.uz
Со временем, допишу все свои статьи и перетащу туда, а пока все-таки буду писать сначала сюда, как в черновик.
Initial RAM-Disk (initrd)
В большинстве дистрибутивах используется один очень полезный костыль - это initrd - Initial RAM disk, что по русски звучит круче - "диск в оперативной памяти для начальной инициализации". По названию и по некоторому опыту можно самостоятельно понять, что это некий образ диска, который грузиться в начале старта системы и используется для ее инициализации.
На деле - этот файл уже не является образом. Ветка ядер 2.6 уже поддерживает помимо образов еще и cpio архивы. То есть сейчас, файл initrd.img представляет из себя cpio-архив, сжатый обычно gzip'ом, внутри которого урезанная корневая файловая система. То есть, в нем те-же каталоги "/bin", "/etc" и т.д., но только не целиком взятые с основной корневой фс, а только лишь с необходимыми файлами для загрузки системы. То есть, там естественно будут утилиты типа "insmod", чтобы подгружать модули, "mount", чтобы монтировать уже настоящею корневую систему и т.д. Еще там находятся необходимые для загрузки модули - ведь ядро, например, не сможет получить доступ к файловой системе, поддержка которой скомпилена модулем, а сам модуль находиться на этой ФС. То есть ядро не сможет прочитать модуль с этой ФС, пока не загрузит этот модуль. Немного смешно звучит конечно, но собственно для таких целей и используется initrd. В нем просто находятся модули файловых систем, модули контроллеров жестких дисков и т.д.
Работает это все очень просто. Загрузчик, типа grub, загружает ядро линукса и в параметрах передает этому ядру файлик initrd. Ядро загружается, загружает в память содержимое initrd, запускает в нем программу "/sbin/init" которая уже задачи загрузки берет на себя. Подгружаются необходимые модули, монтируются файловые системы и дальше initrd передает уже управление загрузкой на основной корневой системе.
В разных дистрибутивах состав этого образа не одинаковый. Поэтому разберу его на примере уже в следующей теме.
На деле - этот файл уже не является образом. Ветка ядер 2.6 уже поддерживает помимо образов еще и cpio архивы. То есть сейчас, файл initrd.img представляет из себя cpio-архив, сжатый обычно gzip'ом, внутри которого урезанная корневая файловая система. То есть, в нем те-же каталоги "/bin", "/etc" и т.д., но только не целиком взятые с основной корневой фс, а только лишь с необходимыми файлами для загрузки системы. То есть, там естественно будут утилиты типа "insmod", чтобы подгружать модули, "mount", чтобы монтировать уже настоящею корневую систему и т.д. Еще там находятся необходимые для загрузки модули - ведь ядро, например, не сможет получить доступ к файловой системе, поддержка которой скомпилена модулем, а сам модуль находиться на этой ФС. То есть ядро не сможет прочитать модуль с этой ФС, пока не загрузит этот модуль. Немного смешно звучит конечно, но собственно для таких целей и используется initrd. В нем просто находятся модули файловых систем, модули контроллеров жестких дисков и т.д.
Работает это все очень просто. Загрузчик, типа grub, загружает ядро линукса и в параметрах передает этому ядру файлик initrd. Ядро загружается, загружает в память содержимое initrd, запускает в нем программу "/sbin/init" которая уже задачи загрузки берет на себя. Подгружаются необходимые модули, монтируются файловые системы и дальше initrd передает уже управление загрузкой на основной корневой системе.
В разных дистрибутивах состав этого образа не одинаковый. Поэтому разберу его на примере уже в следующей теме.
SquashFS. Тестирование
В тестировании использовалось ядро 2.6.30 с поддержкой squashfs версии 4.0 и утилиты squashfs-tools тоже версии 4.0. Естественно, как обычно тесты просто "посмотреть", но все равно полезно интересующимся.
Для тестирования взял каталог /usr почти на свеже-установленной системе, размером в 2076824Кб, почти в два гигабайта. Сжал в образ squashfs вот так:
То есть используя параметры по умолчания (размер блока - 128кб). Файловая система создалась за 6 минут и 4 секунды. Файл usr.sqs сжался до размера 683924Кб. Следовательно, размер файла сократился ровно в три раза, что есть очень сильно... С использованием других параметров, особо ничего не изменилось (даже размер блока в мегабайт не дал особых результатов).
Ладно, скорость сжатия не низкая, несмотря на сильное сжатие. Но интересней больше скорость чтения, по теории она должна быть выше, чем работа с файлами на обычной файловой системе. На практике это подтвердилось. На копирование всех файлов с подмонтированной squashfs ушло 2 минуты и 18 секунд, а на копирование всех тех-же файлов с каталога /usr ушло 4 минуты и 58 секунд. Однако в первом случае, возросла нагрузка на процессор - в среднем 30%, а во втором случае - всего 8%. То есть, теория подтвердилась полностью, но нагрузка на процессор с использованием squashfs не такая уж сильная.
В итоге, пока так и не стало все полностью понятным. В интернете отсутствует подробная информация. Но по крайней мере понятно то, что squashfs справляется со своими задачами очень даже хорошо. На данный момент, на сколько я понял, утилиты squashfs и сама поддержка файловой системы в ядре, сжимают информацию с использованием gzip, когда как раньше были патчи, позволяющие использовать lzma. Буду копать дальше...
Для тестирования взял каталог /usr почти на свеже-установленной системе, размером в 2076824Кб, почти в два гигабайта. Сжал в образ squashfs вот так:
sudo mksquashfs /usr /usr.sqs
То есть используя параметры по умолчания (размер блока - 128кб). Файловая система создалась за 6 минут и 4 секунды. Файл usr.sqs сжался до размера 683924Кб. Следовательно, размер файла сократился ровно в три раза, что есть очень сильно... С использованием других параметров, особо ничего не изменилось (даже размер блока в мегабайт не дал особых результатов).
Ладно, скорость сжатия не низкая, несмотря на сильное сжатие. Но интересней больше скорость чтения, по теории она должна быть выше, чем работа с файлами на обычной файловой системе. На практике это подтвердилось. На копирование всех файлов с подмонтированной squashfs ушло 2 минуты и 18 секунд, а на копирование всех тех-же файлов с каталога /usr ушло 4 минуты и 58 секунд. Однако в первом случае, возросла нагрузка на процессор - в среднем 30%, а во втором случае - всего 8%. То есть, теория подтвердилась полностью, но нагрузка на процессор с использованием squashfs не такая уж сильная.
В итоге, пока так и не стало все полностью понятным. В интернете отсутствует подробная информация. Но по крайней мере понятно то, что squashfs справляется со своими задачами очень даже хорошо. На данный момент, на сколько я понял, утилиты squashfs и сама поддержка файловой системы в ядре, сжимают информацию с использованием gzip, когда как раньше были патчи, позволяющие использовать lzma. Буду копать дальше...
SquashFS. Введение
В ядро версии 2.6.29 внесли наконец поддержку squashfs. Это значит, что теперь эта файловая система поддерживается в самом ядре, без дополнительных патчей.
SquashFS - это файловая система, наподобие CramFS и Cloopfs. Эта файловая система поддерживает сжатие, причем даже уже мое любимое - LZMA. Применяется в основном на livecd и во встраеваемых устройствах. Работает только в режими чтения, то есть, внести новый файл или уже изменить существующий "на лету" никак не получиться.
Вы можете встретить ее на обычном livecd диске убунты. Файл SquashFS-образа находиться в папке casper на диске с убунтой и называется filesystem.squashfs. Если в ядре есть поддержка данной файловой системе, то вам достаточно лишь примонтировать этот файл, как вы монтировали когда-то обычные ".iso" образы:
В каталоге /mnt вы увидете структуру каталогов обычного дистрибутива линукса. Это и есть дистрибутив убунты. Убунту грузиться с компакт-диска монтирует данный файл и с помощью chroot запускает уже целиком систему. Если же вы начали инсталлировать убунту, то инсталлятор просто копирует содержимое данного файла на корневой раздел вашего винчестера. Ну дальше он доставляет некоторый софт, конфигурирует систему и т.п.
Получить файлы из этой файловой системы можно и другим способом. Помимо реализации самой данной файловой системы, существуют так-же и утилиты для управления ею. Скачать их можно отсюда. Они, конечно, есть и в стандартном репозитарии убунты:
Но эти утилиты и сама ФС в убунте обновлялись очень давно. В дистрибутиве до сих пор используется версия SquashFS за 2007 год, когда уже актуальная вышедшая в этом году четвертая версия. Поэтому лучше всего использовать ядро выше версии 2.6.29 и утилиты компилить вручную. Ну по крайней мере до тех пор, пока это чудо не обновиться в убунте.
Так вот, с помощью утилиты mksquashfs можно с легкостью создать данную файловую систему:
Или распаковать ее:
Преимуществ у данной ФС много. Помимо всего прочего - она использует очень сильное сжатие. Файлы сжимаются в два-три раза, причем на довольно высокой скорости. Чтобы достать один файл, не нужно распаковывать всю файловую систему целиком (как это делается с обычными архивами - tar.bz2 и т.п. - попробуйте распаковать всего один самый маленький файл из архива с исходниками ядра), а достаточно лишь ее подмонтировать. Скорость распаковки тоже впечатляет. Да и операции с файлами на такой ФС быстрее, так как файлы занимают в дво-трое меньший размер, чем в реальности. То есть скорость того-же копирования - в два-три раза быстрее, чем с обычной ФС. Из недостатков только то, что операции с файлами на данной ФС больше используют мощности процессоров, но на современных компьютерах это не заметно, а на встраеваемой технике обычно размер играет большее значение.
SquashFS - это файловая система, наподобие CramFS и Cloopfs. Эта файловая система поддерживает сжатие, причем даже уже мое любимое - LZMA. Применяется в основном на livecd и во встраеваемых устройствах. Работает только в режими чтения, то есть, внести новый файл или уже изменить существующий "на лету" никак не получиться.
Вы можете встретить ее на обычном livecd диске убунты. Файл SquashFS-образа находиться в папке casper на диске с убунтой и называется filesystem.squashfs. Если в ядре есть поддержка данной файловой системе, то вам достаточно лишь примонтировать этот файл, как вы монтировали когда-то обычные ".iso" образы:
mount -o loop /media/cdrom/casper/filesystem.squashfs /mnt
В каталоге /mnt вы увидете структуру каталогов обычного дистрибутива линукса. Это и есть дистрибутив убунты. Убунту грузиться с компакт-диска монтирует данный файл и с помощью chroot запускает уже целиком систему. Если же вы начали инсталлировать убунту, то инсталлятор просто копирует содержимое данного файла на корневой раздел вашего винчестера. Ну дальше он доставляет некоторый софт, конфигурирует систему и т.п.
Получить файлы из этой файловой системы можно и другим способом. Помимо реализации самой данной файловой системы, существуют так-же и утилиты для управления ею. Скачать их можно отсюда. Они, конечно, есть и в стандартном репозитарии убунты:
apt-get install squashfs-tools
Но эти утилиты и сама ФС в убунте обновлялись очень давно. В дистрибутиве до сих пор используется версия SquashFS за 2007 год, когда уже актуальная вышедшая в этом году четвертая версия. Поэтому лучше всего использовать ядро выше версии 2.6.29 и утилиты компилить вручную. Ну по крайней мере до тех пор, пока это чудо не обновиться в убунте.
Так вот, с помощью утилиты mksquashfs можно с легкостью создать данную файловую систему:
mksquashfs /usr /usr.squashfs
Или распаковать ее:
unsquashfs /media/cdrom/casper/filesystem.squashfs -d /ubuntu_live
Преимуществ у данной ФС много. Помимо всего прочего - она использует очень сильное сжатие. Файлы сжимаются в два-три раза, причем на довольно высокой скорости. Чтобы достать один файл, не нужно распаковывать всю файловую систему целиком (как это делается с обычными архивами - tar.bz2 и т.п. - попробуйте распаковать всего один самый маленький файл из архива с исходниками ядра), а достаточно лишь ее подмонтировать. Скорость распаковки тоже впечатляет. Да и операции с файлами на такой ФС быстрее, так как файлы занимают в дво-трое меньший размер, чем в реальности. То есть скорость того-же копирования - в два-три раза быстрее, чем с обычной ФС. Из недостатков только то, что операции с файлами на данной ФС больше используют мощности процессоров, но на современных компьютерах это не заметно, а на встраеваемой технике обычно размер играет большее значение.
Снова ".deb" и lzma
В сети пока не легко найти инфу по архиватору lzma, который вроде не такой уж новый, но популярность начал обретать лишь недавно. Мой скрипт по перепаковки ".deb" пакетов из bz2/gz в lzma слишком сырой и кривой. Однако не только я, оказывается, интересовался этой проблемой. Есть уже более подробная информация и более подробным сравнением. Встречайте:
https://wiki.ubuntu.com/dpkg-lzma
Отключение надоедливого спикера
Жутко раздражает меня эта пищалка. Отключается довольно просто - надо всего-лишь выгрузить модуль "pcspkr". То есть:
Но это отключит его только на данный сеанс, чтобы отказаться вообще от этой пищалки, открываем файл
И в конец добавляем строчку "blacklist pcspkr". Сохраняем и перезагружаемся, дабы проверить.
sudo modprobe -r pcspkr
Но это отключит его только на данный сеанс, чтобы отказаться вообще от этой пищалки, открываем файл
sudo gedit /etc/modprobe.d/blacklist.conf
И в конец добавляем строчку "blacklist pcspkr". Сохраняем и перезагружаемся, дабы проверить.
Подписаться на:
Сообщения (Atom)
