GNU GRUB жүктегішін таныстыру

Кіріспе

GNU GRUB (GNU GRand Unified Bootloader, көбінесе GRUB деп аталады) – GNU жобасының жүктегіш бастауыш пакеті. GRUB – Free Software Foundation’s Multiboot Specification-ның эталондық іске асырылуы болып табылады, ол пайдаланушыға компьютерге орнатылған бірнеше операциялық жүйенің бірін таңдауға немесе белгілі бір операциялық жүйенің бөлімдерінде қолжетімді нақты ядро конфигурациясын таңдауға мүмкіндік береді. GNU GRUB Grand Unified Bootloader (Grand Unified Theory ойыны) деп аталатын пакеттен дамытылды. Ол негізінен Unix сияқты жүйелерде қолданылады.

Жүгірту

Компьютер қосылғанда, оның BIOS негізгі жүктелетін құрылғыны (әдетте компьютердің қатты дискісі) тауып, бастапқы жүктелу бағдарламасын бас жүктеу жазбасынан (MBR) іске қосады. MBR – бұл қатты дискідегі бірінші сектор. Бұл бағдарлама кішкентай болуы керек, өйткені ол бір секторға сыйып қана қоймай, іске қосылу процесін бастауы тиіс. Ұзақ уақыт бойы сектордың көлемі 512 байтты құрады. 2009 жылдан бері 4096 байттық секторлары бар қатты дискілер де қолжетімді, олар Advanced Format дискілері деп аталады. Бірақ 2013 жылға дейін мұндай дискілерге 512 байттық секторлар арқылы, 512e эмуляциясын пайдалана отырып қол жеткізілді. MBR бөлім кестесінің ескі нұсқасы максимум төрт бөлімді қолдайды және 64 байт орын алады. Опциялық дискінің идентификаторы (төрт байт) және уақыт белгісі (алты байт) ескерілгенде, жүктеушінің машиналық кодына 434-тен 446 байтқа дейін орын қалады. Мұндай шағын орын өте қарапайым жүктеушілерге жеткілікті болғанымен, күрделі және көптеген файлдық жүйелерді қолдайтын, мәзірлік таңдау арқылы жүктеу опцияларын ұсынатын жүктеушіні орналастыру үшін жеткіліксіз. Сондықтан үлкен жүктеушілер бөліктерге бөлінеді, ең кішкентай бөлігі MBR-ге сыйып, ал қалған үлкен бөліктері MBR мен бірінші бөлім арасындағы бос секторлар сияқты басқа орындарда сақталады. MBR-дегі код екінші бөлікті іске қосып қана қоймайды. Жүктеушінің қалған бөліктері операциялық жүйені конфигурациялап, ядроны іске қосу арқылы жүйеге қол жеткізеді. Ядролар көбінесе тиісті файлдық жүйелердегі файлдар түрінде сақталады, бірақ BIOS файлдық жүйе туралы білмейді. Сондықтан BIOS-қа негізделген жүйелерде жүктеушінің міндеті – сол файлдардың мазмұнына қол жеткізіп, оларды RAM-ге жүктеу және іске қосу. Жүктеушілердің бір әдісі – негізгі файлдық жүйеге түсініксіз, қатты дискінің секторларына тікелей қол жеткізу арқылы ядролық бейнелерді жүктеу. Әдетте, ядролық бейнелердің физикалық секторларын тізімдейтін қосымша файлдар немесе карталар қажет болады. Мұндай карталарды жаңа ядролық бейнелер орнатылғанда, файлдық жүйе фрагментацияланғанда және т.б. ядролық бейне дискідегі физикалық орналасқан жерін өзгерткен сайын жаңарту қажет. Сондай-ақ, карталардың физикалық орналасқан жері өзгерген жағдайда, секторларды анықтау механизмі жұмыс істеуін қамтамасыз ету үшін олардың орналасқан жері жүктеушінің MBR кодында жаңартылуы керек. Бұл ғана емес, қиындық тудырады, сонымен қатар жүйе жаңарту кезінде қателіктер туған жағдайда жүйені қолмен жөндеу қажет болуы мүмкін. Басқа бір тәсіл – жүктеушіге қолдау көрсетілетін файлдық жүйелер туралы білуді қамтамасыз ету, сонда ядролық бейнелер олардың нақты файлдық жолдары арқылы конфигурацияланып, қол жеткізіледі. Бұл үшін жүктеушіде қолдау көрсетілетін әрбір файлдық жүйеге арналған драйвер болуы керек, осылайша жүктеуші оларды түсініп, қол жеткізе алады. Бұл тәсіл қатты дискінің секторларының қатты кодталған орналасқан жерін және карта файлдарының болуын болдырмайды, сонымен қатар ядролық бейнелер қосылғаннан немесе жылжытылғаннан кейін MBR жаңартуларын қажет етпейді. Жүктеушінің конфигурациясы әдеттегі файлда сақталады, ол ядролық бейнелерді іске қосу алдында жүктеу конфигурацияларын алу үшін файлдық жүйеге қол жеткізіп пайдаланылады. Осылайша жүйе жаңарту кезінде қателіктердің болу ықтималдығы азаяды. Алайда, мұндай жүктеушілер көбірек орын алады және күрделі болады. boot.img (1-кезең) бас жүктеу жазбасының алғашқы 440 байтына (MBR жүктеу коды 0-шы секторда) немесе партиция жүктеу секторына (PBR) жазылады. Ол diskboot.img-ге 64 биттік LBA мекенжайы арқылы жүгінеді. Нақты сектор нөмірі grub install арқылы жазылады. diskboot.img – ядроның бірінші секторы. img, оның жалғыз мақсаты – ядроның қалған бөлігін жүктеу. img, LBA сектор нөмірлерімен де grub install арқылы жазылады. MBR бөлінген дискілерде, core.img (1.5-кезең) MBR мен бірінші бөлім арасындағы бос секторларда (болған жағдайда) сақталады. Жаңа операциялық жүйелер мұнда сәйкестендіру үшін 1 МиБ кеңістік ұсынады (2047 512 байт немесе 255 4 КиБ сектор). Бұл кеңістік 1996 жылға дейін BIOS қолданған Цилиндр Бас Сектор (C/H/S) адрестеуінің сектор санының шегін еске түсіретін 62 сектор (31 КиБ) болды, сондықтан core.img 32 КиБ-тан кіші болуы тиіс. GPT бөлінген дискілерде core.img өзінің жеке бөліміне жазылады. Ол "BIOS grub" деп белгіленуі керек, форматталмауы керек және 1 МиБ-қа дейін көлемде болуы мүмкін. 2-кезең: core.img /boot/grub/i386-pc/normal.mod-ты grub install конфигурациялаған бөлімнен жүктейді. Егер бөлім индексі өзгерген болса, GRUB normal.mod-ты таба алмайды және пайдаланушыға GRUB Rescue сұранысын ұсынады. GRUB2 қалай орнатылғандығына байланысты, /boot/grub/ Linux дистрибуциясының түбірлік бөлімінде немесе бөлек /boot бөлімінде орналасқан. normal.mod жүктелгеннен кейін: normal.mod /boot/grub/grub.cfg-ні талдайды, қажет болса модульдерді жүктейді (мысалы, графикалық интерфейс пен файлдық жүйе қолдауы үшін) және мәзірді көрсетеді.

When a computer is turned on, its BIOS finds the primary bootable device (usually the computer's hard disk) and runs the initial bootstrap program from the master boot record (MBR). The MBR is the first sector of the hard disk. This bootstrap program must be small because it has to fit in a single sector. For a long time, the size of a sector has been 512 bytes. Since 2009 there are hard disks available with a sector size of 4096 bytes, called Advanced Format disks, but as of 2013, such hard disks are still accessed in 512 byte sectors, using the 512e emulation. The legacy MBR partition table supports a maximum of four partitions and occupies 64 bytes, combined. Together with the optional disk signature (four bytes) and disk timestamp (six bytes), this leaves between 434 and 446 bytes available for the machine code of a boot loader. Although such a small space can be sufficient for very simple boot loaders, it is not big enough to contain a boot loader supporting complex and multiple file systems, menu driven selection of boot choices, etc. Boot loaders with bigger footprints are therefore split into pieces, where the smallest piece fits in the MBR, while one or more larger pieces are stored in other locations such as empty sectors between the MBR and the first partition. The code in the MBR then does little more than starting the second part. The purpose of the remaining part(s) of the boot loader is to actually boot an operating system by configuring it and starting the kernel. Kernels are in most cases stored as files residing on appropriate file systems, but the concept of a file system is unknown to the BIOS. Thus, in BIOS based systems, the duty of a boot loader is to access the content of those files, so it can be loaded into the RAM and executed. One possible approach for boot loaders is to load kernel images by directly accessing hard disk sectors without understanding the underlying file system. Usually, an additional level of indirection is required, in form of maps or map files auxiliary files that contain a list of physical sectors occupied by kernel images. Such maps need to be updated each time a kernel image changes its physical location on disk, due to installing new kernel images, file system defragmentation, etc. Also, in case of the maps changing their physical location, their locations need to be updated within the boot loader's MBR code, so the sectors indirection mechanism continues to work. This is not only cumbersome, but it also leaves the system in need of manual repairs in case something goes wrong during system updates. Another approach is to make a boot loader aware of the underlying file systems, so kernel images are configured and accessed using their actual file paths. That requires a boot loader to contain a driver for each of the supported file systems, so they can be understood and accessed by the boot loader itself. This approach eliminates the need for hardcoded locations of hard disk sectors and existence of map files, and does not require MBR updates after kernel images are added or moved around. The configuration of a boot loader is stored in a regular file, which is also accessed in a file system aware way to obtain boot configurations before the actual booting of any kernel images. Thus, fewer things can go wrong during system updates. As a downside, such boot loaders are larger and more complex. boot. img (stage 1) is written to the first 440 bytes of the Master Boot Record (MBR boot code in sector 0), or optionally in a partition boot sector (PBR). It addresses diskboot. img by a 64 bit LBA address. The actual sector number is written by grub install. diskboot. img is the first sector of core. img with the sole purpose to load the rest of core. img identified by LBA sector numbers also written by grub install. On MBR partitioned disks, core. img (stage 1.5) is stored in the empty sectors (if available) between the MBR and the first partition. Recent operating systems suggest a 1 MiB gap here for alignment (2047 512 byte, or 255 4KiB, sectors). This gap used to be 62 sectors (31 KiB) as a reminder of the sector number limit of Cylinder Head Sector (C/H/S) addressing used by BIOS before 1996, therefore core. img is designed to be smaller than 32 KiB. On GPT partitioned disks core. img is written to its own partition. It must be flagged "BIOS grub", must not be formatted and can be as tiny as 1 MiB. stage 2: core. img loads /boot/grub/i386 pc/normal. mod from the partition configured by grub install. If the partition index has changed, GRUB will be unable to find the normal. mod, and presents the user with the GRUB Rescue prompt. Depending on how GRUB2 was installed, the /boot/grub/ is either in the root partition of the Linux distribution, or in the separate /boot partition. after normal. mod loaded: normal. mod parses /boot/grub/grub. cfg, optionally loads modules (eg. for graphical UI and file system support) and shows the menu.

UEFI тұрақ-бағдарламасын пайдаланатын жүйелерді іске қосу

/efi/<distro>/grubx64.efi (x64 UEFI жүйелері үшін) EFI жүйелік бөлімінде файл ретінде орнатылады және тікелей, boot.img файлы MBR секторының 0-шы секторында болмай, микробағдарламамен (firmware) жүктеледі. Бұл файл 1-ші және 1.5-ші кезеңдерге ұқсас. /boot/grub/ EFI жүйелік бөліміне немесе жеке /boot бөліміне орнатылуы мүмкін. x64 UEFI жүйелері үшін 2-ші кезең – /boot/grub/x86_64.efi/normal.mod файлы және басқа /boot/grub/ файлдары.

Бөлшектерді анықтау (UUID айналма әдісі)

Компьютерде бірнеше қатты дискілер болуы мүмкін. Бұл дискілерді SATA порты арқылы анықтауға болады. Компьютер POST-тан өтетін әр жолы, аналық платаның 1-ші портына қосылған қатты дискіге бірдей идентификатор тағайындалуы мүмкін, мысалы. Бірақ егер мұндай тұрақтылыққа кепілдік берілмесе не істеу керек? Егер қосылған қатты дискілердің жиынтығы бір жүктелуден екіншісіне өзгерсе не істеу керек? Егер қатты диск басқа компьютерге қосылса не істеу керек? GRUB құтқару консоліне (core.img жүктелгеннен кейін қолжетімді) немесе GRUB консоліне (normal.mod жүктелгеннен кейін қолжетімді) кіру арқылы барлық қолжетімді қатты дискілер мен бөлімдердің тізімін алуға болады. Бұл сандарды болжау арқылы немесе одан әрі зерттеулер жүргізу арқылы (мысалы) нақты қатты дискілер мен бөлімдерге тағайындауға болады. Қатты дискілерді қарапайым сандармен нөмірлеудің тұрақты еместігіне кепілдік болмағандықтан, GNU GRUB бөлімдерді (немесе файл жүйесінің мысалдары) анықтау үшін UUID-ты пайдалана алады – егер оларда мұндай мүмкіндік болса. ext2, ext3, ext4 және xfs файлдық жүйелері бір дананы бірегей түрде анықтау үшін Универсалды бірегей идентификаторды (UUID) пайдаланады. UUID бөлім форматталғанда жасалады. UUID файлдық жүйеге кіріктірілген және суперблокқа жазылады. Форматтаудан басқа барлық операциялар UUID-ты өзгеріссіз қалдыруы керек, бірақ оны өзгерту немесе көшіру мүмкін (мысалы, dd командасын пайдаланып бөлімді клондау арқылы). файлы GRUB-ты конфигурациялау үшін қолданылады. Осы файлда әрбір жүктелу кезінде орындалатын командалар сақталады. Егер қолданыстағы және жарамды болмаса, GRUB сұрау шығарады. Ең қарапайым келесі екі командадан ғана тұруы мүмкін (қ. бастапқы RAM дискісі): linux (hd0,1)/kernel/vmlinuz 3.20.1 4 ro # бірінші қатты дискідегі бірінші бөлімдегі /kernel каталогында орналасқан "vmlinuz" файлы linux ядролық бейнесі ретінде қолданылсын initrd (hd0,1)/boot/initrd.img 3.20.1 4 # бірінші қатты дискідегі бірінші бөлімдегі /boot каталогында орналасқан "initrd.img" файлы бастапқы RAM дискісі ретінде қолданылсын. Көбірек әсемдікке ұмтылған көрсетілетін мәзірді сипаттайды, бірнеше түстерді пайдаланады және мүмкін ая кескінін қосады.

A computer can have multiple hard disks connected to it. These could be identified via their SATA port. Each time the computer POSTs, the hard disk connected to port 1 (of the motherboard), could be assigned the same identifier, e. g. But what if such consistency cannot be guaranteed? What if the constellation of connected hard disks changed from one start up to another? What if a hard disk shall be connected to another computer? By entering into either the in GRUB rescue console (available after loading core. img ) or the GRUB console (available after loading normal. mod) a list of all available hard disks and partitions can be obtained. Either by guessing or by further investigation (e. g. ) can these numbers be assigned to actual hard disks and partitions. As it cannot be guaranteed that the numbering of hard disks via dumb numbers is consistent, GNU GRUB can use the UUID to identify partitions (actually file system instances) – that have this feature – instead. The file systems ext2, ext3, ext4 and xfs use an Universally Unique Identifier (UUID) to uniquely identify an instance. The UUID is created when a partition is formatted. The UUID is part of the file system and written to the superblock. All operations but a formatting should leave the UUID unaltered, but it is possible to change it or duplicate it (by using dd to clone an entire partition). The file is used to configure GRUB. It is the file where the commands which shall be executed during each start up are stored. Without an existing and valid , GRUB will present a prompt. An absolute minimal might contain only the following two commands (cf. initial ramdisk):
linux (hd0,1)/kernel/vmlinuz 3.20.1 4 ro # use the file name "vmlinuz " located in the directory /kernel on the first partition of the first hard disk as linux kernel image
initrd (hd0,1)/boot/initrd. img 3.20.1 4 # use the file named "initrd. img– " located in the directory /boot on the first partition of the first hard disk as initial ramdisk

More fancy will describe a menu to be presented, will use multiple colors, and maybe a background picture.

Тарих

GRUB бастапқыда Эрих Болейн GNU/Hurd операциялық жүйесін іске қосу жұмысының бөлігі ретінде, Free Software Foundation әзірлеген, құрастырған. 1999 жылы Гордон Матцигкейт және Йошинори К. Окуджи GRUB-ты GNU жобасының ресми бағдарламалық қамтамасы деп жариялап, оның әзірлеу процесін көпшілыққа ашты.

Даму

GRUB 1-ші нұсқасы (сонымен қатар "GRUB Legacy" деп те аталады) енді әзірленбейді және кезең-кезеңмен тоқтатылуда. GNU GRUB әзірлеушілері назарын GRUB 2-ге аударды, ол GNU GRUB-ты тазалау, нығайту, көшпелі және қуатты ету мақсатымен толыққандай қайта жазылды. GRUB 2 PUPA деген атпен бастау алды. PUPA-ға Жапонияның ақпараттық технологияларды дамыту агенттігі (IPA) қолдау көрсетті. PUPA шамамен 2002 жылы GRUB 2 дамуына енгізілді, сол кезде GRUB 0.9x нұсқасы GRUB Legacy деп қайта аталды. GRUB 2 жобасының мақсаттарының ішінде x86 емес платформаларды қолдау, халықаралық деңгейдегі қолдау және жергілікті тілге аудару, ASCII емес символдар, динамикалық модульдер, жадты басқару, сценарийлерді жасауға арналған шағын тіл, платформаға тән (x86) кодты платформаға тән модульдерге көшіру және объектіге бағытталған құрылым бар. GNU GRUB 2.00 нұсқасы 2012 жылдың 26 маусымында ресми түрде жарияланды. Ең көп қолданылатын Linux дистрибутивтерінің үшi GRUB 2-ні негізгі жүктеу құралы ретінде пайдаланады. Ubuntu оны 2009 жылдың қазан айындағы 9.10 нұсқасында әдепкі жүктеу құралы ретінде қабылдады. Fedora 2011 жылдың қараша айында шыққан Fedora 16 нұсқасымен соңғысын істеді. OpenSUSE GRUB 2-ні 2012 жылдың қыркүйек айындағы 12.2 нұсқасында әдепкі жүктеу құралы ретінде қабылдады. Solaris та x86 платформасында Solaris 11.1 нұсқасында GRUB 2-ні қабылдады. Buildroot сонымен қатар GNU GRUB-ты x86 және x86 64 мақсаттары үшін қолданады. 2015 жылдың соңында кіру паролін айналып өту үшін 28 рет backspace пернесін басу арқылы жасалған қате табылып, жылдам түзетілді.

Нұсқалар

GNU GRUB - еркін және ашық бастапқы кодты бағдарламалық қамтамасыз ету, сондықтан бірнеше нұсқалары жасалды. GRUB негізгі тармағына қосылмаған ерекше нұсқалардың кейбіреулері: OpenSolaris-ке Solaris VTOC бөлімдерін қолдайтын, автоматты түрде 64 биттік ядроны таңдайтын және ZFS-тен жүктеуді (құралу және бірнеше жүктеу ортасымен) қамтамасыз ететін өзгертілген GRUB Legacy кіреді. Google Summer of Code 2008 жобасы GRUB Legacy-дің ext4 форматындағы бөлімдерден жүктелуін қолдауды қамтамасыз етті. Syllable жобасы өздерінің AtheOS файлдық жүйесінен жүктеу үшін GRUB-тың өзгертілген нұсқасын жасады. TrustedGRUB сенімді платформа модулін (TPM) пайдаланып, жүйе тұтастығын тексеру және жүктеу процесінің қауіпсіздігін арттыру арқылы GRUB-ты кеңейтеді. Intel BIOS Implementation Test Suite (BITS) BIOS-ты, әсіресе Intel процессорларын, жабдықтарын және технологияларын бастауды сынау үшін GRUB ортасын ұсынады. BITS Python арқылы сценарийлерді қолдайды және ACPI, CPU және чипсет тіркеулері, PCI және PCI Express сияқты аппараттық платформаның төменгі деңгейдегі әртүрлі функционалдықтарына қол жеткізу үшін Python API-лерін қамтиды. GRUB4DOS – DOS және Microsoft Windows жүйелерінде орнату процесін жақсартатын GRUB Legacy-нің тармағы. Оны DOS-тен тікелей немесе NTLDR немесе Windows Boot Manager арқылы жүктеуге болады. GRUB4DOS белсенді даму үстінде және 2021 жылдан бастап UEFI-ді қолдайды.

GRUB конфигурация құралдарын

Әр түрлі дистрибутивтерде қолданылатын орнату құралдары көбінесе GRUB-ты орнатуға арналған модульдерді қамтиды. Мысалы, SUSE Linux және openSUSE дистрибутивтеріндегі YaST2, Fedora/RHEL дистрибутивтеріндегі Anaconda. StartUp Manager және GRUB Customizer – Debian негізіндегі дистрибутивтер үшін графикалық конфигурация редакторлары. StartUp Manager бағдарламасын әзірлеу 2011 жылдың 6 мамырында тоқтатылды, өйткені бас әзірлеуші жеке себептермен бағдарламаны белсенді түрде дамытуды тоқтатуға мәжбүр болды. GRUB Customizer Arch негізіндегі дистрибутивтер үшін де қолжетімді. GRUB 2 үшін KDE басқару модульдері бар. GRLDR ICE – GRUB4DOS үшін grldr файлының әдепкі конфигурациясын өзгертуге арналған шағын құрал.

Жүгіртуді жөндеу құралдары

Boot Repair – GRUB және Microsoft Windows жүктеуішінде жиі кездесетін жүктеу қателіктерін жоюға арналған қарапайым графикалық құрал. Бұл қолданба GNU GPL лицензиясымен таратылады. Boot Repair, Debian, Ubuntu, Mint, Fedora, openSUSE және Arch Linux сияқты көптеген Linux дистрибутивтерінде GRUB-ты қалпына келтіре алады.

Windows үшін орнатушы

Grub2Win – Windows үшін ашық бастапқы коды бар бағдарламалық пакет. Ол GNU GRUB-ты Windows каталогынан жүктеуге мүмкіндік береді. Орнату бағдарламасы GNU GRUB 2.06 нұсқасын NTFS бөліміне орнатады. Содан кейін Windows GUI қолданбасы GRUB жүктеу мәзірін, тақырыптарды, UEFI жүктеу ретін, сценарийлерді және т.б. реттеу үшін пайдаланылады. GNU GRUB сценарийлері мен командаларының барлығы UEFI және ескі жүйелер үшін қолдау көрсетіледі. Grub2Win GRUB-ты Windows, Ubuntu, openSuse, Fedora және көптеген басқа Linux дистрибутивтерін бірнеше рет жүктеу үшін конфигурациялай алады. Ол GNU GPL лицензиясы бойынша SourceForge-де тегін қолжетімді.