Вы могли использовать что-то как zenity
или xmessage
. Например:
wgetmsg() {
wget "$@" && zenity --info --text='Wget returned success.' || zenity --error --text='Wget returned failure.'
}
wgetmsg -O filename http://www.example.com
Это обычно не устанавливается там. Большую часть времени GRUB (этап 1) установлен в MBR только на Linux.
Хотя версия 1 GRUB будет всегда переполняться немного в 30 КБ после MBR (этап 1.5, т.е. драйверы файловой системы), с версией 2 GRUB, код, установленный в MBR, может загрузить некоторый другой и больший код (этап 1.5) сырыми данными, читая любые секторы из диска (но будет обычно придерживаться поведения GRUB 1 - то есть, загружая код из 30 КБ после MBR).
Те 30 КБ являются обычно доступным non-partitionned "бесплатным" дисковым пространством, потому что по историческим причинам довольно редко для первого раздела диска запуститься перед сектором 63, который оставляет по крайней мере 512*62 = 31 кибибит после MBR.
Затем это загружает некоторые файлы, обычно от /boot
, как меню (menu.lst
или grub.cfg
), больше драйверов файловой системы, и т.д. Это - этап 2.
После этого, имеет достаточно для запуска ОС.
Что касается VBR теперь, это не является наиболее часто используемым на разделах Linux, потому что это не достаточно надежная, но MS Windows, обычно устанавливает один в начале системы (C:\) разделы. GRUB просто выполнит его, если Вы захотите запустить Windows. Этот процесс называют chainloading: загрузчик, который запускает другой. Это также означает, что файловая система, используемая там, должна оставить нетронутым начало ее раздела, потому что она могла перезаписать VBR иначе! Сумма "нетронутого" доступного пространства зависит от файловой системы, таким образом, нет никакой хорошей гарантии: это могло быть очень маленьким...
О загружающемся этапе 1.5 от "необычного" места, поскольку я сказал, GRUB 2 может загрузить свой этап 1.5 из любого сектора на диске. Это может быть из файла, но это может быть опасно, потому что файловая система может решить переместить тот файл в другие секторы на диске в любое время (или еще хуже, для фрагментации его!), и GRUB должен был бы обновить новый номер сектора в MBR каждый раз...
Интересный случай является Таблицами разделов GUID (GPT). Они являются слишком большими, чтобы гарантировать, что достаточно места (30 КБ) всегда будет свободным для этапа 1.5. Рекомендуемое решение в этом случае состоит в том, чтобы использовать специализированный "раздел загрузчика" (не проблема, так как GPT может поддерживать 128 разделов), который не разместит файловую систему, но данные этапа 1.5 GRUB. Таким образом, это не должно перемещать anywere, и можно дать ему много пространства.
Необходимо действительно прочитать статью GRUB Википедии, где я получил большую часть этой информации.
На самом деле GRUB2 обычно не устанавливается на VBR. Это рекомендует против этой практики.
Это - что-то как там то, чтобы не быть достаточным количеством пространства там для связывания модуля файловой системы для начальной загрузки/. Исторически, диски MBR дают Вам 62 "зарезервированных" сектора для такого загрузочного кода. (Поскольку первый раздел запускается на цилиндрической границе. В наше время мы игнорируем цилиндры, но это выровненное к целому мегабайту вместо этого, для поддержки 4K дисков сектора, справки с SSD / RAID, и т.д.). Вы не получаете такие хорошие гарантии от VBR.
Сообщение GRUB2 дает Вам, объясняет, что VBR (раздел) установки должен полагаться на сохранение номеров блока модулей, таких как драйвер файловой системы. Это менее надежно; это означает, что личинка должна быть переустановлена, когда те файлы модуля обновляются.
fdisk
некоторое время, для обеспечения старой совместимости DOS.
– Totor
23.03.2013, 14:53
/dev/sda
- непосредственно после MBR - существует копия/boot/grub/core.img
или/boot/grub/diskboot.img
. – JohnnyFromBF 22.03.2013, 15:47