Несколько дистрибутивов и один GRUB2

Через UEFI грузись, там и груба не надо

старое железо, UEFI недоступен, денег купить новое нет

И вообще - Linux, это же один раз настроил и потом всю жизнь пользуешься. А тут почему-то надо в железо вкладываться, прямо как под Windows

Linux, это же один раз настроил и потом всю жизнь пользуешься.

До первого обновления.

отдельном разделе и монтировался во все операционные системы (по аналогии с boot)

Первое, что приходит в голову, собрать его из исходников (на манер того, как это сделано в LFS) и установить в обход пакетного менеджера, что не есть хорошо.

А так, емнип, каждый граб2 завязал на свои специфичные скрипты, которые различны в Генте и Дебиане, к примеру.

Так что не похоже, чтобы кто-то работал в этом направлении :(

Я не понял что хочет автор. Один дистрибутив ставишь как положено - с грабом и со всем остальным. Остальные ставишь БЕЗ загрузчика. А дальше вопрос как именно ты это все настроишь - либо автоматический скрипт найдет другие дистрибутивы и будет их грузить, либо ты настроишь это все вручную.

Упорот? Где сказано, что есть EFI?

либо автоматический скрипт найдет другие дистрибутивы и будет их грузить, либо ты настроишь это все вручную

Не понятно что за автоматический скрипт и когда он должен запускаться. Обновлять конфигурацию grub нужно после обновления ядра какой-нибудь системы.

У меня один загрузчик в МБР, остальные в раздел, каждый в свой. Один раз настроил основной, добавил в список загрузки с разделов. После обновления, сразу грузится последнее ядро. Ну, по вкусу, таймауты можно поменьше написать.

Были раньше проблемы с установкой, grub2 по-умолчанию ставится в МБР, в раздел - только с форсе. В некоторых дистрибутивах, из их инсталляторов нельзя было поставить загрузчик в раздел, разок приходилось это делать вручную. Последнее время таких проблем не было.

сделай в GRUB2-менюшке «главного» дистрибутива несколько пунктов-меню, ...

которые будут вести на GRUB2-менюшки остальных дистрибутивов.

пункты меню — будут примерно такие:

menuentry 'My Linux 123' {
. (hd0,123)/boot/grub/grub.cfg
}
menuentry 'My Linux 234' {
. (hd0,234)/boot/grub/grub.cfg
}
menuentry 'My Linux 345' {
. (hd0,345)/boot/grub/grub.cfg
}

то есть на «не-главных» дистрибутивах ты будешь ставить GRUB2, будешь его конфигурировать, но НЕ будешь записывать загрузочный сектор (дабы НЕ перезаписать загрузочный сектор от «главного» дистрибутива)

в этом случае — в каком-то смысле для «неглавных» дистрибутивов GRUB2 станет более портабельным.

мне непонятно, как здесь работают линии с точкой.

это то же самое, что и директива configfile ?

в идеале, хотелось бы прямо во внедрённом конфиге пробежаться по всем разделам HDD и собрать из них все подменю в одно меню.

но проблема в том, что насколько я понял, модуль normal запускается только после встроенного конфига, и в самом встроенном конфиге не доступны команды menuentry (правда мне непонятно, как тогда работают остальные команды и чем menuentry от них отличается, что работает только после загразки модуля normal)

в общем, идея такая: написать замену модулю normal, обозвать его как-нибудь типа multiboot и пусть он конфиг грузит не с одного какого-то конкретного раздела, а собирает с разных разведлов в один конфиг.

Если на жестком диске есть несколько разделов с разными операционными системами каждый, то хотелось бы

перестать маяться херней.

grub4dos живет весь в небольшом досовом разделе

мне непонятно, как здесь работают линии с точкой.

точка (".") — синоним команды source.

то есть (как в bash) просто считывается конфиг как есть. в итоге к старому меню — добавляются ещё новые строчки, и быть может меняется оформление.

это то же самое, что и директива configfile ?

прошу прощения.. быть может команда configfile — подошла бы тут лучше, чем точка (".") . вообщем над поэкспериментировать с командой configfile

модуль normal запускается только после встроенного конфига, и в самом встроенном конфиге не доступны команды menuentry

ды нет смысла менять встроенный конфиг. menuentry нужны уже после него — в обычном конфиге (или даже например засунуть menuentry в /boot/grub/custom.cfg . /boot/grub/custom.cfg подгружается поумолчанию из /boot/grub/grub.cfg , хотя наверное зависит от того как собран пакет с Грабом :) , надо поглядеть /etc/grub.d/41_custom)

в общем, идея такая: написать замену модулю normal, обозвать его как-нибудь типа multiboot и пусть он конфиг грузит не с одного какого-то конкретного раздела, а собирает с разных разведлов в один конфиг.

для этого не надо писать новый модуль.

команда точка (.) (синоним команды «source») — может собрать конфиги из разных разделов разных грубов.

. (hd0,123)/boot/grub/grub.cfg
. (hd0,234)/boot/grub/grub.cfg
. (hd0,345)/boot/grub/grub.cfg

(использовать команды с точками (.) — без menuentry , тогда уж, в отличии от Несколько дистрибутивов и один GRUB2 (комментарий) )

прописать эту команду в *обычном* конфиге Груба «главного» дистрибутива.

в итоге получится — одна большая менюшка (со всеми вариантами).

тут на мой взгляд едиственная проблема — в оформлении. каждый погруженный конфиг — захочет выставить своё оформление. в итоге наверное останется то оформление которое было подгружено в последнем конфиге :-) ..

так что придётся указать в конце (после команд с точками) ещё и пару команд которые бы вернули оформление в более «эталонный» вид :-)

А разве нет разницы из под чего его конфигурять, если он в MBR записан?

точка (".") — синоним команды source

команды source не существует в grub2:
http://www.gnu.org/software/grub/manual/grub.html

не путаешь ли ты с bash-ем?

команды source не существует в grub2:

но ведь эта команда даже используется... хм.. пумолчанию, кое где..

вот — скриншот файла «/etc/grub.d/41_custom» (файл такой какой есть после установки Груб-пакета. этот файл я не менял, и не создавал):

[regular-user@localhost ~]$ cat /etc/grub.d/
00_header      20_linux_xen   40_custom      60_memtest86+  
10_linux       30_os-prober   41_custom      README         
[regular-user@localhost ~]$ cat /etc/grub.d/41_custom 
#!/bin/sh
cat <<EOF
if [ -f  \${config_directory}/custom.cfg ]; then
  source \${config_directory}/custom.cfg
elif [ -z "\${config_directory}" -a -f  \$prefix/custom.cfg ]; then
  source \$prefix/custom.cfg;
fi
EOF

ну ты текст-то почтай, в пятой строке написано, что это скрипт для /bin/sh
а совсем не для grub2

Для чего он нужен? Может он нужен для генерации конфига grub?

нашел маппинг команды на модуль:
grep -E «^source» /boot/grub/i386-pc/command.lst
source: configfile

точку тоже нашел, там же:
grep -E «^\.:» /boot/grub/i386-pc/command.lst
.: configfile

То есть эта команда обрабатывается модулем configfile.mod
но как именно обрабатывается, мне пока непонятно.
Какие вообще функции есть в модуле configfile - там одна функция или несколько?

http://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/commands/configfile....

GRUB_MOD_INIT(configfile)
{
  cmd_configfile =
    grub_register_command ("configfile", grub_cmd_source,
			   N_("FILE"), N_("Load another config file."));
  cmd_source =
    grub_register_command ("source", grub_cmd_source,
			   N_("FILE"),
			   N_("Load another config file without changing context.")
			   );

  cmd_extractor_source =
    grub_register_command ("extract_entries_source", grub_cmd_source,
			   N_("FILE"),
			   N_("Load another config file without changing context but take only menu entries.")
			   );

  cmd_extractor_configfile =
    grub_register_command ("extract_entries_configfile", grub_cmd_source,
			   N_("FILE"),
			   N_("Load another config file but take only menu entries.")
			   );

  cmd_dot =
    grub_register_command (".", grub_cmd_source,
			   N_("FILE"),
			   N_("Load another config file without changing context.")
			   );
}

там же, чуть выше:

static grub_err_t
grub_cmd_source (grub_command_t cmd, int argc, char **args)
{
  int new_env, extractor;

  if (argc != 1)
    return grub_error (GRUB_ERR_BAD_ARGUMENT, N_("filename expected"));

  extractor = (cmd->name[0] == 'e');
  new_env = (cmd->name[extractor ? sizeof ("extract_entries_") - 1 : 0] == 'c');

  if (new_env)
    grub_cls ();

  if (new_env && !extractor)
    grub_env_context_open ();
  if (extractor)
    grub_env_extractor_open (!new_env);

  grub_normal_execute (args[0], 1, ! new_env);

  if (new_env && !extractor)
    grub_env_context_close ();
  if (extractor)
    grub_env_extractor_close (!new_env);

  return 0;
}

разобрался, что написано в проверках, теперь бы ещё понять как grub_normal_execute работает...
меня, если честно, такой стиль проверок пугает (хотя баг явных я не вижу).

для этого не надо писать новый модуль

дело в том, что я не уверен, что обычные команды будут работать во внедрённом конфиге (embedded config) grub.

а я хочу избавиться от специального раздела /boot, чтобы всё моё колдунство было незаметно шаловливым пользователям. Просто представь, что они школьники.

А я возму dd и восстановлю начальные сектора из бекапа. Без всяких там лишних разделов.

ну ты текст-то почтай, в пятой строке написано, что это скрипт для /bin/sh
а совсем не для grub2

первая строчка: #!/bin/sh . а вторая строчка: cat <<EOF

ты же понимаешь что такое в шелл обозначает выражение — <<EOF ?? :-)

а я хочу избавиться от специального раздела boot

правильное дело!

нет особого смысла иметь специальный раздел boot ! (кроме исключительных ситуаций, таких когда без отдельного boot-раздела нельзя)

так как grub2 умеет работать с EXT4/BTRFS/<и-кучу-других-фс> — думаю достаточно чтобы каждая операционная система имелабы свой корень! (а в случае с BTRFS достаточно чтобы каждая операционная система имела-бы хотя бы свой subvol)

но как это всё влияет на описываемую ситуацию?

ведь раздел же «ef02 BIOS boot partition» (GPT-GUID: 21686148-6449-6E6F-744E-656564454649) — у тебя всё равно же будет (и только один, независимо от того сколько у тебя операционных систем на HDD)...

только НЕ говори что ты НЕ используешь GPT, да? верно, используешь же?

выведется на stdout фрагмент от EOF до EOF.

Я уже понял, что этот текст попадает в финальный конфиг. и написал тебе, как он там на самом деле работает.

У меня теперь другой вопрос - в embedded конфиге, до выполнения команды normal можно ли использовать extract_entries_source ?

А если перед этим написать
insmod configfile
?

Что писать тогда вместо normal - ничего не писать? Так normal ведь сам запускается...

У меня теперь другой вопрос - в embedded конфиге, до выполнения команды normal можно ли использовать extract_entries_source ?

до normal .. сомниваюсь... но нужен кто-то более квафицированный чем я, чтобы ответить на это :-)

НЕ говори

окау

# parted -l
Диск /dev/sda: 1000GB
Размер сектора (логич./физич.): 512B/512B
Таблица разделов: msdos
Disk Flags: 

Номер  Начало  Конец   Размер  Тип       Файловая система  Флаги
 1     1049kB  33.6GB  33.6GB  primary   ext2              загрузочный
 2     33.6GB  1000GB  967GB   extended
 5     33.6GB  46.0GB  12.4GB  logical   ntfs
 6     46.0GB  54.8GB  8804MB  logical   ext4
 7     54.8GB  61.8GB  7065MB  logical   ext4
 8     61.8GB  70.2GB  8402MB  logical   ext4
 9     70.2GB  111GB   41.2GB  logical   ext4
10     111GB   145GB   33.6GB  logical   ext4
11     145GB   512GB   367GB   logical   ext4
12     512GB   530GB   17.8GB  logical   linux-swap(v1)
13     530GB   561GB   31.5GB  logical   ext4
14     561GB   595GB   33.9GB  logical   reiserfs
20     595GB   616GB   21.0GB  logical   ext4
15     932GB   953GB   21.0GB  logical   ext4
16     953GB   959GB   6606MB  logical   ext4
17     959GB   966GB   6291MB  logical   ext2
18     966GB   979GB   13.6GB  logical   ext4
19     979GB   1000GB  21.0GB  logical   ext4

ох... ну и дела :-)

нужен кто-то более квафицированный чем я, чтобы ответить на это :-)

у меня та же фигня. Поэтому я и создал этот тред

ну вот подгружать другие конфиги через точку — я пробовал (они нормально подгружаются) .. но правда делал я это — из интерактивной bash-like-командной-строки , а не заранее прописав в «главный» конфиг