Pull to refresh

Comments 87

Ну скажем прямо — так грузятся далеко не все дистры.
Поделитесь, пожалуйста, как организовано в генту.
Папки уровней запуска по другому называются и инструмент для управления уровнями удобный есть.
Те же яйца, только в профиль. )
Спасибо. Кстати, на счет инструмента, то и в убунте есть ГУИ для этих целей.
UFO just landed and posted this here
Эээ… Это немного не то. startupmanager только позволяет конфигурить (и весьма ограничено) меню Grub, Splashy и Usplash. Взгляните здесь.
UFO just landed and posted this here
Можете взглянуть на rcconf, sysv-rc-conf и bum — все они позволяют манипулировать скриптами в /etc/rc?.d. Два первые можно запускать без графисечкой среды (требуется наличие ncurses), а bum — GTK-тулза, правда у меня с ней были проблемы при отображении UTF-8, а я с ней играться не имел желания.
Не совсем те же яйца, там еще есть управление зависимостями сервисов, то есть sshd, например, раньше сети не запустится. Это по-моему гораздо удобнее, чем распихивать скрипты по разным папкам с номерами.
update-rc.d в debian умеет раскидывать с номерами сам (зависимости прописываются в скриптах в /etc/init.d, на которые линкуются файлы из /etc/rc?.d/)
Еще хочется сделать замечание по поводу MBR, первого сектора и пр. Все несколько усложнилось за последние годы. Сейчас уместней говорить о EFI.

«GUID Partition Table (GPT) является стандартным форматом размещения таблиц разделов на физическом жестком диске. Он является частью Extensible Firmware Interface (EFI) (Расширяемый Микропрограммный Интерфейс) — стандарта, предложенного Intel на смену отжившего BIOS, одного из последних реликтов первозданной IBM PC. EFI использует GPT там, где BIOS использует Главную загрузочную запись (MBR)....» (википедия)

UFO just landed and posted this here
Загрузка какого дитрибутива не проходит хотябы один из этих 6 уровней?
У слаквари нету rc.d скриптов. Точнее, они оставлены только для совместимости.
Стыкался всего один раз со слакой, но думаю, что есть аналог rc.d. Должны же как-то демоны загружаться, не так ли?
Откройте для себя BSD init. Впрочем, от классического SysV отходят многие дистрибутивы.
UFO just landed and posted this here
Все уровни могут использоваться как для загрузки, так и для выгрузки. Зависит от первой буковки — K=kill, S=start. Далее идёт приоритет, а далее, собственно, имя скрипта из /etc/init.d, который этим линком вызывается. (Может быть и не линк, а скрипт). В любом случае, действие определяет первый символ, а не уровень выполнения (runlevel).
$ ls -1 /etc/rc1.d

K05anacron

S13cpuspeed


Так что не сбивайте народ с «пути истинного». :)

PS. Не для всех дистрибутивов верно. Верно, если мне не изменяет память, для систем построенных на основе SystemV.
UFO just landed and posted this here
> Некоторые уровни не для загрузки, а для «выгрузки»
Ваши слова? Вот на это я и ответил, что любой уровень может использоваться как для загрузки, так и для выгрузки. И именно это имел ввиду, говоря «не сбивайте народ с «пути истинного»
UFO just landed and posted this here
Я отвечал на вопрос SkyManPHP, «Загрузка какого дитрибутива не проходит хотябы один из этих 6 уровней? „

Ответ “Уровень 6» будет правильным.
Ибо «старт скрипта при shutdown» не относится к процессу _загрузки_.
Только я один что ли понял, что вы вообще о разном говорите?
UFO just landed and posted this here
Ядро можно скомпилировать без initrd.
Ну да, есть еще bsd-style init.

Кстати никогда не понимал ранлевелов.
Ну скажем прямо — здесь описаны не все дистрибутивы, а обобщенная схема загрузки операционки.
Кроме того смысл скриптов rc.d ( как бы они не назывались ) — обеспечение различных схем инициализации системы ( читать: «загрузка разных модулей и подготовка различного окружения» ) в зависимости от ранлевела.
И не важно какая схема инициализации используется, все равно подход остается тем же — разное окружение для различных условий.
Ещё немаловажно соблюдение порядка загрузки в пределах одного ранлевела.
Понимаю, что вопрос глупый, но, думаю, он не у одного меня.
А в Windows оно как? И MacOS? Любопытно просто.
зачем давать ссылки? можно же целую статью скопипастить, а хомячки плюсиков поставят…
Гугл — спаситель человечества.
Т.е. данный топик по-вашему тоже не нужен? Это ведь тоже есть в гугле ;)
Вот если бы хабрачеловечек DerSpinner не спрашивал очевидные вещи, а нагуглил, и написал два топика — никаких вопросов не было бы. Зачем спрашивать о том, что можно запросто найти самому?
UFO just landed and posted this here
Откуда Вы знаете, что далее, если дальше не читали?
И да, наверное таки стоит почитать. Ибо MBR — это кусок исполняемого кода, другими словами — это программа, а не просто указатель.
UFO just landed and posted this here
А сам MBR — не программа, и исполняемого кода там нет…
Почитайте википедию, что ли…
Я почему-то предполагал, что в MBR хранится «указатель», кому передать управление дальше…
Ну, значит, ошибались.
Никакой логики нет в этом тем более. Кто тогда этот указатель использует то? Компьютер не может работать сам по себе, не выполняя всё время какой-то код. И BIOS не читает MBR, он подгружает его на предопределённое место и передаёт туда управление. Это всегда так было и это отнюдь не секретная информация, не пойму чего тут спорить то…
А, на счет POST — это часть функционала BIOS'а. Никто ничего никому не передает :)
Пожалуй, таки упомину о нем.
MBR как раз таки передает управление конкретному загрузчику, установщик которого (grub-install, syslinux, bootsect) туда этот самый MBR и записал.
Ну, можно было бы еще и про LILO написать, хоть он и старый, но все же.
LILO хоть и старый, но пока остается единственным вариантом для некоторых нонеймовых материнок (:
BIOS (и не упомянутый тут (U)EFI) прежде всего занимается инициализацией устройств (в том числе загрузку собственных биосов PCI-устройств), про это ничего не написано. Хотя эта роль постепенно сокращается, так как всё больше железа инициализирует себя само и/или поддерживает горячее подключение и потому всё равно инициализируется ОС, но, например, инициализацию оперативной памяти он делает всегда.
для полноты картины надо бы добавить ещё то, что происходит в промежуток времени между нажатием кнопки включения питания и выдачей (блоком питания) сигнала Power_good. Ибо POST, насколько я понимаю, уже после начинается.
Не думаю, что это нужно относить к теме о загрузке Линукса, ибо не тот уровень. Ибо в таком случае уже нужно и учитывать еще уровень ниже — прохождение тока в электричной цепи. С такими углублениями уже и за Линукс читатель забудет :)
SysV init must die.
Использовал несколько встроенных систем основанных на подходе описаном автором статьи за ссылкой. Они значительно более удобны для разработки и отладки.
Ура! «SysV VS BSD-style»-срач! Давненько его не было %)
А чего тут спорить, BSD-Style > SysV-style.
xinit — наше всё. Жаль, умер.
Ох уж этот хабр… Всегда найдеться тот, кто знает лучше всех, как грузиться ядро линукс…
>Возможно, некоторым из вас это не ново и особого интереса не было при чтении статью, поскольку она более ориентирована на начально-средний уровень знакомства з Линуксом.
> В таком случае могу лишь сказать, что «повторение — мать учения» (с).

Занимаюсь Linux около 19-и лет. Всё равно с большим интересом читаю подобные статьи.
UFO just landed and posted this here
Извиняюсь, спутал с общим стажем. Примерно с 99-го или с 98-го плотно подсел на Linux.
> GRUB понимает, что такое файловая система (древние загрузчики Linux'а, например, LILO этого не понимают).

Предвижу shitstorm от фанатов LILO.
Самый популярный дистрибутив у новичков, Ubuntu, уже несколько лет вместо inittab использует upstart ( upstart.ubuntu.com/ ), поэтому все, что касается runlevel'ов там совсем не так.
Да шестой пункт в каждом дистре по своему.
В пятом пункте тоже всё «по-своему». Т.е. уровни как миниум 2,4,5 не во всех дистрах так распределены, в каждом по-разному.
Да ну? А Выполните-ка в терминале на убунте
ls -la /etc/rc0.d/

UpStart-то есть, но и SysV используется и еще долго будет поддерживаться, хотя бы в целях совместимости.
Ну да)

$ tail -n1 /etc/init/rc.conf
exec /etc/init.d/rc $RUNLEVEL
И? Вы же подтверждили то, что я написал. :)
Для Debian/Ubuntu:
— каталога /etc/rc.d/ нет;
— каталоги /etc/rc?.d/ настоящие каталоги, а не ссылки;
— в этих каталогах хранятся ссылки на скрипты в каталоге /etc/init.d/

Вручную лучше в /etc/rc?.d/ ничего не править, а использовать команду update-rc.d, которая позволяет создавать ссылки, удалять их, запрещать (фактически переименовывать c S* на K*) и разрешать (c K* на S*) запуск.
Пропущен initrd. А это ОЧЕНЬ важный этап.
Который, опять же, присутсвует не всегда.
Как и BIOS, MBR, GRUB и SysV init.
Занимаясь буквоедством, единственным обязательным этапом загрузки линукса является запуск ядра.
И стейджи бутлодера не расписаны, кстати.
Почему важный? Если ядро собирается под конкретное железо, можно все нужные драйверы вкомпилировать в ядро, а initrd выкинуть. На встраиваемых системах так часто делают.
Кстати, не стоит забывать, что сейчас вместо init.d появился Upstart и systemd — оно позволяет значительно ускорить загрузку системы. А init.d наверно скоро уйдет в /dev/null
Linux — это ядро, оно имеет другие этапы загрузки, то что вы описали это процесс загрузки какого-то конкретного дистрибутива GNU/Linux, причем процесс на конкретной аппаратной платформе ( IBM PC? ), к примеру встраиваемые системы грузятся иначе. В любом случае, выбрав правильное название топика, можно было избежать споров в коментах.
Спасибо, Ваш комментарий учтен
Я добавлю небольшое уточнение. Всё что вы описали верно только для части дистров (об этом уже упомянули) и только в случае платформы x86 с BIOS на борту. Уточнение здесь для того, что во-первых, на декстопах иногда бывает EFI, а кроме того Linux популярен в мире embedded и там ещё куча разных платформ. Я какбе к тому, что надо было указать о чём речь, ибо у меня вот линукс в телефоне и грузицо он совсем не так (: Ну какбе вообще не так.
Согласен, Ваши комментарии справедливы. Наверное, стоило добавить хотя бы PC в шапку статьи. Впрочем, на то они и комментарии, чтобы «виводить на чистую воду», да чтобы уточнять детали.
вам бы батенька покурить архитектуры отличные от x86/amd64. даже хотя бы x86/amd64 с [U]EFI. или таки исправьте заголовок.
Я, если честно, давно не мог понять одной вещи… Вы пишете:

>Ядро монтирует файловую систему в соответствии с настройкой «root=» в фале grub.conf

А как оно вообще туда лезет, если FS не смонтирована? Более того, как GRUB читает свой конфигурационный файл, если он даже не знает, какое ядро грузить? И где загрузчик находится физически?
>initrd — это Initial RAM Disk, он же временный диск в оперативной памяти
>initrd используется самим ядром в качестве временной корневой файловой системы, пока kernel не загрузится в реальную примонтированную файловую систему. Этот временный диск также содержит необходимые для загрузки драйверы, позволяющие получить доступ к разделам дисков и другому оборудованию
ЕМНИП (могу сильно ошибаться) grub-install устанавливает в mbr так же модуль для чтения той fs, на которой лежит ядро и конфиги grub. Если модуль поддержки fs в ядре статичный, то initrd может быть не нужен.
Вы написали, что «древний» LILO, не понимает что такое файловая система, а GRUB понимает. Какой плюс от этого GRUB'у?
Почему LILO потерял свою популярность?
Не припомню ни одного дистрибутива который использует lilo по умолчанию, хотя везде оно есть, да.
> Какой плюс от этого GRUB'у?
lilo не умеет грузить iso-образы.

И еще, у lilo нет файловера, как в грубе.
А некоторые системы работают без биоса и граба, обходясь только u-boot.
Есть книжка «Ядро Linux в комментариях», тем кому интересно могут там прочитать более подробно о стадии загрузки и других механизмах. Правда, она достаточно старая и о переизданиях я не слышал.
Спасибо — и наполнение и оформление отличное. Приятно читать.

зы. — Что Вы все прицепились к GRUB vs Lilo? Есть же BURG — вот радость, вот она )
Спасибо за статью. Здесь еще добавлено немного подробнее об уровнях выполнения на практике. Может будет кому-то полезным.
Sign up to leave a comment.

Articles