Зачем нужен загрузчик grub lilo
Перейти к содержимому

Зачем нужен загрузчик grub lilo

  • автор:

Форум русскоязычного сообщества Ubuntu

Страница сгенерирована за 0.053 секунд. Запросов: 25.

  • Сайт
  • Об Ubuntu
  • Скачать Ubuntu
  • Семейство Ubuntu
  • Новости
  • Форум
  • Помощь
  • Правила
  • Документация
  • Пользовательская документация
  • Официальная документация
  • Семейство Ubuntu
  • Материалы для загрузки
  • Совместимость с оборудованием
  • RSS лента
  • Сообщество
  • Наши проекты
  • Местные сообщества
  • Перевод Ubuntu
  • Тестирование
  • RSS лента

© 2012 Ubuntu-ru — Русскоязычное сообщество Ubuntu Linux.
© 2012 Canonical Ltd. Ubuntu и Canonical являются зарегистрированными торговыми знаками Canonical Ltd.

Сравнение lilo и grub

Автору не удалось быть беспристрастным, о чем он открыто и заявил признавшись в любви к GRUB. Подводя итоги статьи можно сказать, что LILO — загрузчик для тех, кому не нужны красивости, вроде интерактивного меню, зато нужна скорость и отстутствие дыр.
А GRUB надо ставить на компы какой-нибудь сети в каком-нибудь офисе, чтобы менеджеры среднего звена радовались, а админ мог через сеть загружаться.

Все вышесказанное ИМХО.

OConnor
( 28.08.05 20:37:43 MSD )
Ответ на: комментарий от OConnor 28.08.05 20:37:43 MSD

>Подводя итоги статьи можно сказать, что LILO — загрузчик для тех, кому не нужны красивости, вроде интерактивного меню, зато нужна скорость и отстутствие дыр.

У LILO равно как и у GRUB есть интерактивное меню, а также можно поставить графическое. Насчёт дыр — назови хоть одну в грубе.

mikhail
( 28.08.05 20:41:33 MSD )

груб без патчей не понимает многие фс, например рейзер4

а вот лило глубоко пофигу какая фс на разделе

JB ★★★★★
( 28.08.05 20:44:05 MSD )
Ответ на: комментарий от JB 28.08.05 20:44:05 MSD

вроде как LILO не умеет FreeBSD грузить?

devUrandom
( 28.08.05 20:47:06 MSD )
Ответ на: комментарий от mikhail 28.08.05 20:41:33 MSD

Наличие в LILO интерактивного меню автоматически уничтожает аргумент автора статьи.

А насчет дыр — я юзер, в коде никогда не ковырялся. Но программа с поддержкой сети для меня всегда более подозрительна, чем без оной.

OConnor
( 28.08.05 20:47:40 MSD )

Чего сравнивать жопу с пальцем? Ясен пень, что GRUB в тысячу раз круче по своим возможностям. И будущее если не за GRUB, то за подобными ему загрузчиками.

dmitrmax ★
( 28.08.05 20:49:02 MSD )
Ответ на: комментарий от OConnor 28.08.05 20:47:40 MSD

>Но программа с поддержкой сети для меня всегда более подозрительна, чем без оной.

Так если ты не указываешь сетевого источника загрузки, откуда могут взяться дыры?

mikhail
( 28.08.05 20:50:05 MSD )
Ответ на: комментарий от OConnor 28.08.05 20:47:40 MSD

> А насчет дыр — я юзер, в коде никогда не ковырялся. Но программа с поддержкой сети для меня всегда более подозрительна, чем без оной.

Аффтар имел ввиду дыры с точки зрения кривости рук при настройке. Кроме того, во всех дистрах (ну или почти) GRUB скомпилен без поддержки сети. Потому что она компилится под конкретную сетевуху.

dmitrmax ★
( 28.08.05 20:51:53 MSD )
Ответ на: комментарий от devUrandom 28.08.05 20:47:06 MSD

> вроде как LILO не умеет FreeBSD грузить?

Умеет, лично грузил. Сам использую lilo.

clx ★★★
( 28.08.05 20:52:22 MSD )
Ответ на: комментарий от dmitrmax 28.08.05 20:51:53 MSD

>Аффтар имел ввиду дыры с точки зрения кривости рук при настройке. Кроме того, во всех дистрах (ну или почти) GRUB скомпилен без поддержки сети. Потому что она компилится под конкретную сетевуху.

Да что в lilo, что в grub, если пароль не поставишь и не поставишь lock на загрузку флопа, кто угодно сможет получить рутовы доступ посредством параметра ядру init=/bin/sh.

mikhail
( 28.08.05 21:00:29 MSD )

Привык к grub. Сравнение lilo и grub даже читать не хочу. Если всё и так хорошо работает, зачем менять?

Selecter ★★★★
( 28.08.05 21:04:00 MSD )

В свое время переполз на grub, т.к. все время забывал вызывать lilo после очередной пересборки ядра / правки конфига =)

int19h ★★★★
( 28.08.05 21:06:50 MSD )

default=0 timeout=10 splashimage=(hd1,3)/grub/splash.xpm.gz password --md5 $1$opeVt0$Y.br.18LyAasRsGdSKLYlp1 title Red Hat Linux password --md5 $1$0peVt0$Y.br.18LyAasRsGdSKLYlp1 root (hd1,3) kernel /vmlinuz-2.4.18-14 ro root=LABEL=/ initrd /initrd-2.4.18-14.img title Windows XP password --md5 $1$0peVt0$Y.br.18LyAasRsGdSKLYlp1 rootnoverify (hd0,0) chainloader +1 А нахрена три раза password писать?

mikhail
( 28.08.05 21:10:07 MSD )
Ответ на: комментарий от dmitrmax 28.08.05 20:49:02 MSD

> Ясен пень, что GRUB в тысячу раз круче по своим возможностям. И будущее если не за GRUB, то за подобными ему загрузчиками.

Канешно, дружище! И не нужны нам никакие статти, патаму шо мы и так самые умные!

А ещё — Сляка рулит!

anonymous
( 28.08.05 21:14:54 MSD )
Ответ на: комментарий от devUrandom 28.08.05 20:47:06 MSD

С какого перепоя не умеет? У меня 3 года грузит.

wadim_ ★
( 28.08.05 21:24:57 MSD )

> Сравнение lilo и grub

Мдя. Они бы ещё сравнили запорожец 72 года выпуска, и Audi TT cabrialet. Смех да и только. Правильно сказали, что сравнивать жопу с пальцем?

log1n
( 28.08.05 21:27:10 MSD )

Одни пионеры собрались?

Или grub уже за пределы x86 выбрался?

AVL2 ★★★★★
( 28.08.05 21:32:14 MSD )
Ответ на: комментарий от AVL2 28.08.05 21:32:14 MSD

> Или grub уже за пределы x86 выбрался?

А какие еще процессоры существуют?

И второй вопрос — а почему они *еще* существуют?

plm ★★★★★
( 28.08.05 21:35:38 MSD )
Ответ на: комментарий от plm 28.08.05 21:35:38 MSD

> И второй вопрос — а почему они *еще* существуют?

неправильный поставленный вопрос, правильно будет «почему x86 еще существует?»

JB ★★★★★
( 28.08.05 21:36:29 MSD )
Ответ на: комментарий от AVL2 28.08.05 21:32:14 MSD

>Или grub уже за пределы x86 выбрался?

Однако на x86 он лучший, а x86 — подавляющее большинство. 🙂

mikhail
( 28.08.05 21:38:15 MSD )
Ответ на: комментарий от JB 28.08.05 21:36:29 MSD

> правильно будет «почему x86 еще существует?»

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

plm ★★★★★
( 28.08.05 21:41:56 MSD )
Ответ на: комментарий от mikhail 28.08.05 21:38:15 MSD

> Однако на x86 он лучший, а x86 — подавляющее большинство. 🙂

Вот тут товарищи напоминают про карманные компьютеры.

А чем там ядра грузят кстати?

plm ★★★★★
( 28.08.05 21:42:46 MSD )
Ответ на: комментарий от AVL2 28.08.05 21:32:14 MSD

octy ★★
( 28.08.05 21:57:22 MSD )
Ответ на: комментарий от AVL2 28.08.05 21:32:14 MSD

> Или grub уже за пределы x86 выбрался?

Да. Везде, кроме altlinux, видимо.

log1n
( 28.08.05 22:05:44 MSD )
Ответ на: комментарий от mikhail 28.08.05 21:00:29 MSD

>кто угодно сможет получить рутовы доступ посредством параметра ядру init=/bin/sh.

только еще нужно системник в стену замуровать, при чем так, чтобы не нашли, а то этот кто-нибудь сбросит пароль биваса и загрузится с диска или просто унесет винт домой (-:

Muromec ☆☆
( 28.08.05 22:38:00 MSD )
Ответ на: комментарий от JB 28.08.05 20:44:05 MSD

> груб без патчей не понимает многие фс, например рейзер4

>а вот лило глубоко пофигу какая фс на разделе

не понимает не значит что не может загрузить. stage 1.5 optional

( статью сейчас почитаю 🙂 )

всю жизнь сидел с lilo — теперь поставил и grub. hda — lilo. hdb — grub. друг на друга ссылаются — всё работает прекрасно. В функционале разницы особой пока не нашел( разве что файлы читать без ОС в grub — и то со stage1.5 ). раздражает медленное обновление экрана при шлёпаньи стрелками вверх вниз. не знаете как починить?

sf ★★★
( 28.08.05 22:42:56 MSD )
Ответ на: комментарий от plm 28.08.05 21:41:56 MSD

Чертовски правильно! Реальность парадоксальна. зато так интереснее.

Обеспечение безопасности загрузчика GRUB в Linux

Привет, Хабр! Сегодня я покажу вам, как защитить загрузчик.

Безопасность компьютерных систем является одним из ключевых аспектов в современном мире цифровых технологий. С каждым днем возрастает число кибератак, направленных на нарушение конфиденциальности данных, а также вторжение в личную жизнь и нанесение ущерба бизнесу. В этом контексте обеспечение безопасности загрузчика GRUB, используемого в операционных системах Linux, становится неотъемлемой составляющей защиты системы. В данной статье мы рассмотрим шаги по обеспечению безопасности загрузчика GRUB, начиная с генерации зашифрованного пароля и заканчивая его внедрением в систему.

Значение безопасности загрузчика GRUB:

GRUB (Grand Unified Bootloader) является ключевым элементом при загрузке операционной системы Linux. Этот процесс начинается с выполнения кода BIOS, который затем передает управление загрузчику GRUB. В случае нарушения безопасности загрузчика, злоумышленники могут получить доступ к системе исключительно путем обхода авторизации, изменения конфигурации или запуска специальных режимов, что может привести к серьезным последствиям, вплоть до полного контроля над системой.

Обеспечение безопасности загрузчика GRUB позволяет предотвратить подобные атаки, обеспечивая аутентификацию пользователей и защиту от несанкционированного доступа к системе уже на этапе ее загрузки. Такой подход обеспечивает надежную защиту операционной системы Linux и способствует сохранению целостности и конфиденциальности данных.

Когда компьютер запускается, первый выполняемый код — это BIOS.

Это происходит очень быстро, и выполняется тест самопроверки.

Затем он выполняет код в секторе Master Boot Record диска, где находится загрузчик.

Загрузчик затем загружает ядро, которое инициализирует всю систему.

Сегодня все основные дистрибутивы Linux используют GRUB 2 в качестве загрузчика. Хакер может изменить GRUB и загрузить систему в специальный режим работы (называемый режимом одиночного пользователя), где root входит автоматически без пароля. Атакующий также может использовать интерфейс редактора GRUB для изменения его конфигурации или сбора информации о системе; или если это двойная загрузка, атакующий может выбрать во время загрузки другую операционную систему, которая игнорирует контроль доступа и права доступа к файлам.

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

Один из таких методов — это загрузка системы с другого носителя, такого как USB-накопитель.

Также стоит установить пароль BIOS и настроить систему на автоматическую загрузку с раздела, на котором установлен Linux.

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

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

grub-mkpasswd-pbkdf2

PBKDF2 — это функция вывода ключа, основанная на пароле.

И я ввожу пароль.

И она сгенерировала хешированную форму пароля.

Следующим шагом после генерации хешированного пароля является редактирование основного файла конфигурации GRUB и добавление хеша пароля.

Таким образом, ваш фактический пароль не виден в сценариях GRUB, и возможный хакер не может его увидеть.

Основной файл конфигурации GRUB2 находится в /boot/grub/grub.cfg

Однако этот файл не изменяется напрямую пользователем. Он перезаписывается определенными обновлениями GRUB при добавлении или удалении ядра или когда пользователь выполняет команду обновления GRUB 2.

Так что, фактически, GRUB использует серию скриптов для построения этого файла конфигурации, они находятся в /etc/grub.d

Поэтому мы изменяем файлы в этом каталоге, а затем выполняем update-grub2.

Эта команда, основанная на содержимом этих файлов в /etc/grub.d, сгенерирует grub.cfg, основной файл конфигурации.

Я предпочитаю изменить настраиваемый файл, такой как 40_custom, потому что он не будет перезаписан, даже когда пакет GRUB будет обновлен.

Давайте посмотрим на хешированный пароль, который мы только что сгенерировали.

И я копирую эту строку в буфер обмена, начиная с grub.pbkdf2.

И как root, я открываю 40_custom, так что sudo vim /etc/grub.d/40_custom и в конце файла добавляю

set superusers="root" password_pbkdf2 root

и вставляю хешированный пароль.

Я сохраняю файл и выхожу.

Следующим шагом я обновляю файл конфигурации GRUB.

Я выполняю команду update-grub2 от имени root. Эта команда сгенерирует новый файл grub.cfg.

Вот и все! Теперь GRUB запрашивает пароль при загрузке; он больше не загружает систему напрямую в первую ОС. Так что я ввожу имя пользователя, которое является root, и пароль, который я установил.

LVM + lilo > GPT + EFI (или почему GRUB такой неуклюжий)

Мало кто знает и понимает, что MBR по сути своей есть величайшая ошибка человечества. Ну послушайте, ну серьезно, кому в голову пришло смешивать в одном блоке данные, необходимые для загрузки системы и сведения о разделах?

Я еще раз повторю, не надо сейчас мне говорить «так сложилось», а включите логику. MBR ужасна.

Еще ужаснее то, что она пытается исправлять ошибки проектирования костылями. Чтобы избежать идиотского ограничения в 4 раздела в одной MBR-записи нужно предложить концепцию «расширенного» раздела (логически), обманывая и создавая кучу полупустых MBR по всему диску (физически). Опять же, не буду на этом подробно останавливаться, специалисты поймут, остальным неважно.

Еще одна проблема MBR заключается в том, что разделы нельзя просто так увеличивать (ну, кроме последнего). Хотите изменить размер раздела? Ну, это просто — нужно удалить его и заново создать, передвинув его конец. Глубокоуважаемый товарищ amarao запилил прекрасную утилиту ptmax, которая позволяет хоть как-то снять эту боль, но послушайте, еще раз, ведь есть же другой путь!

Отдельным пунктом идет прекрасное поведение загрузчика GRUB с MBR. Ну, поскольку загрузчику мало 446 байт для полноценной жизни, он помещает свой core.img в «зазор» между окончание MBR и началом первого раздела (который предлагается начинать с 1 мегабайта, хотя раньше было ближе).

GPT?

Эээээ, нет. GPT лечит проблему того, что в MBR в одном флаконе собран уж и еж. GPT как бы говорит нам, что теперь нет никаких скрытых областей, куда GRUB будет что-то писать, вот для него отдельный раздел. Отлично. Но куда деваться от того, что разделы все равно нельзя увеличить?

Ну, например, поставил я систему. Выделил под rootfs 32 Гб, а завтра понял, что мне надо 64. И как жить? Что делать? Если я создал после rootfs раздел под swap, то расширение раздела под rootfs выглядит вот так:

1. Выключить swap
2. Снести раздел под swap
3. Изменить размер раздела под rootfs
4. Расширить файловую систему rootfs
5. Создать раздел под swap
6. Включить swap

Все бы хорошо, но если у меня за rootfs создан раздел с данными и передвинуть его я не могу? Ну, тогда нужно страдать.

LVM

О да, вот это уже круто! Ведь тут вопрос разделов вынесен за скобки вообще. Я могу создать сколько угодно разделов и не задумываться о том, как их потом увеличивать. Круто? Да.

Но к сожалению, логика того, что LVM заменяет собой MBR и GPT приходит не ко всем. До сих пор целый ряд подходов системных администраторов косно крутится вокруг логики «давайте создадим раздел на весь диск, а раздел добавим в LVM».

Ну и крутотенюшка заканчивается, когда Вы хотите отказаться от MBR или GPT полностью, а остаться только с LVM.

Попытка с инсталлятором Ubuntu

Note: здесь и далее я буду говорить про Ubuntu, если уважаемое сообщество подскажет, как обстоят дела с этим вопросом в других дистрибутивах, буду рад.

«В чем проблема? Я ж видел даже в инсталляторе Ubuntu строчку про LVM!» — скажет любой, кто устанавливал хоть раз, например, Ubuntu и будет прав.

Да, ну давайте посмотрим, какой ад вариант нам предложит инсталлятор.

Здесь прекрасно все. От мелочей до важного.

Для начала, оцените иронию — под LVM отдан раздел, а не диск. Почему? Я оставлю это на совести тех, кто это придумал. Особый цинизм в том, что раздел расширенный, т.е. на диске будет болтаться два блока с MBR. Окей.

Потом мы оценим обычный раздел /boot. Да, Вы хотите LVM, но у Вас будет и MBR тоже. Почему так? Ну раньше это можно было оправдать тем, что grub не умел эти Ваши LVM, но он давно уже умеет.

Ну и плавно к важному. Никого не смущает, что по сути LVM натягивается, как сова на глобус поверх MBR? Это как понимать? Зачем это вообще?

Да закопайте уже стюардессу

Отказаться от MBR просто — мы же можем отдать целый диск в подчинение LVM? Можем и нужем. Как это сделать из инсталлятора? Увы, никак. Руками. То есть, перед шагом Partition disks нужно переключиться в соседний tty и руками сделать следующее (подразумевается, что диск, куда мы хотим установить систему, зовут /dev/sda):

pvcreate /dev/sda vgcreate ubuntu /dev/sda lvcreate -n root -L6G ubuntu lvcreate -n swap -l100%FREE ubuntu 

Тут я отдаю 6 гигабайт на rootfs, оставшееся на swap, изменить по желанию.

Ну и дальше на этапе разбивки диска мы увидим созданные нами разделы, можем распределить, что и куда дальше.

Хьюстон, у нас проблемы

И все будет хорошо, но ровно до этапа установки загрузчика. Инсталлятор предложит установить GRUB. Мы, конечно, согласимся. А что не так?

Напомню, что LVM обычно отступает 1Mb от начала физического носителя. Откуда я знаю? Ну команда

pvs -o +pe_start

покажет это. Что для нас это означает? Первый мегабайт диска свободен, никто не мешает GRUB записать туда свои 446 байт загрузчика, плюс core.img. Вот только без MBR он не сможет это сделать!

Еще раз, я поражаюсь нежности GRUB: тебе дают диск, давай уже, сделай так, чтобы ты оттуда мог грузиться. Ты умеешь LVM, в чем проблема?

Даже попытки вызвать grub-install вручную с параметром -s привели только к тому, что «unable to identify a filesystem in hostdisk//dev/sda: safety check can’t be performed».

Воскуривание сырцов открывает жестокую правду: GRUB просто не умеет выполнить инсталляцию самого себя, если нет живого MBR с хотя бы одним разделом.

Лирическое отступление: истинные бойцы с презрением скажут: «Зачем тебе вообще возиться с этим отсталым GRUB? Приходи же в нашу церковь EFI!».

Вообще я согласен, с EFI все гораздо проще, но есть проблема с кучей Legacy машин, которые EFI уметь не будут. То есть, заставить EFI грузиться как BIOS обычно можно, обратное, увы, не всегда выполнимо. А я хочу LVM и мороженку, тьфу, загрузку не только с EFI.

EFI?

В целом, EFI задуман достаточно неплохо. Нет никаких скрытых тебе областей, создай раздел, положи туда загрузчик в виде .efi-файла, 7 строк конфигурации и загружайся.

Нет, подождите. Опять создай раздел? Может быть кто-нибудь догадается в спецификацию EFI добавить поддержку LVM? Пожалуйста?

В качестве выхода, конечно, можно взять небольшую флешку и отформатировать ее в желанный для EFI FAT целиком, без разделов. Уже хлеб, но все равно в системе придется держать два диска, один для EFI, другой целиком под LVM, где уже система.

lilo?

Тут, думаю, раздастся громкий WAT. Да, увы, так оно и есть, это настоящий и серьезный WAT.

Никогда не думали, почему GRUB так монструозен? Потому что обычно он хорошо подходит для сложных ситуаций, когда одну систему мы хотим грузить так, тут хотим опций, там хотим вот этого и тут хотим того. Но минуточку, для системных администраторов, где уже все давно виртуализировано, это обычно нонсенс. Нужно просто загружать систему с минимальной болью.

И что мы выясняем? Что lilo отлично умеет устанавливаться на диск с LVM; умеет /boot в LVM; не требует, чтобы на диске был создан хоть какой-то MBR и замечательно работает на той же Ubuntu 16.04, т.е. пакет есть и он адекватен.

Беда в другом. Разработка lilo прекратилась в конце 2015 года. Ну, с другой стороны, оно умеет все, что надо, чтобы загружать современную систему целиком на LVM.

Заключение

Еще раз, пожалуйста, поймите главный message этой статьи — откажитесь от обычной таблицы разделов. Будь то MBR, будь то GPT, оно Вам не нужно, если есть LVM. Никогда не отдавайте под LVM разделы (кроме тех случаев, когда нужен какой-нибудь извращенный dual-boot с Windows), в этом просто нет смысла.

И давайте вместе надеяться, что когда-нибудь у нас будет поддержка LVM в EFI. А пока будем страдать, тьфу, использовать lilo.

  • Системное администрирование
  • *nix
  • Серверное администрирование
  • DevOps

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

Ваш адрес email не будет опубликован. Обязательные поля помечены *