Ремонт на GRUB и INITRAMFS

Отделих специално място за ремонт на GRUB защото ако показвам техниката за ремонт в другите статии ще се получи нещо ужасно дълго и объркващо. Примерно темата е: "Инсталиране на Debian 11 на BIOS и ZFS" и нещо се обърка. Ако почвам да показвам как се ремонтира GRUB ще изгубите логиката на инсталиране на специфичния Debian. Затова реших тази тема да я отделя и разкажа подробно за нея.

Ремонт на GRUB при BIOS

Тук пак има два варианта. Използване на твърди дискове във формат MSDOS или GPT. По сложния вариант е при GPT, затова ще покажа него. За MSDOS по логика ще се справите сами. Изгоря Ви е първия диск на който сте инсталирали системата. Всичко е работило прекрасно и си мислите, че така сте направили и втория диск. Обаче за изненада когато се стартирате от втория диск се появява следния екран:

Една от грешките при развален GRUB. Можете да видите три грешки - grub> - Най-лекия проблем. GRUB открива всичко (ядро, модули), без конфигурационния файл grub.cfg - grub rescue> - Малко по-сложен проблем. GRUB е зареден в MBR но не може да открие папката /boot/grub - GRUB: - Най-лошия вариант. GRUB не е успял да открие дори основната информация за работа. При този проблем задължително трябва да се заредите през LiveCD и да ремонтирате системата. Не показвам най-лесния вариант, защото той е част от този. И така, имаме грешка grub rescue>. Поне част от GRUB e зареден. Да проверим:

Чрез set проверяваме за текущото състояние на GRUB. Виждаме, че е зареден в MBR с дадена конфигурация. Указано е, че ще зарежда от първия диск root=hd0, като конфигурацията му ще се записва в prefix=(hd0)/grub. По просто казано ще зарежда от първия диск който трябва да е форматиран в MSDOS за да няма дялове и в корена ще се намират всички папки /boot, /home, /dev и т.н. Тка ние ще имаме проблем. Първо диска ни е във формат GPT. След това зареждането го обособяваме в отделен дял, най-често втория. Примерно /boot е монтиран на /dev/sda2. До тук това може да разберем. Да проверим:

Чрез командата ls / проверяваме дали имаме достъп до конфигурациите на GRUB. За съжаление отговора е: "error: unknown filesystem. / грешка: непозната файлова система." Да проверим все пак наличните дискове с прилежащите им дялове:

Използвайки командата ls виждаме, че имаме един диск (hd0) с три дяла (hd0,gpt3),(hd0,gpt2) и (hd0,gpt1). Нас ни вълнува вторя дял (hd0,gpt2). В него е /boot с ядрата на системата, с модулите за ядрата. Да проверим:

set prefix=(hd0,gpt2)/boot - казваме, че тук ще се намира конфигурацията на GRUB. set root=(hd0,gpt2) - тук ще се намират ядра модули и т.н. Това на практика е /boot. Накрая с комндата set проверяваме какви нови настройки дефинирахме чрез предните команди за root и prefix. Отново да проверим дали правилно зададохме новите конфигурации:

С командата ls / проверяваме дали наистина така дефинирахме достъп до /boot. Отговора е положителен. Видя се конфигурационната папка grub, както и ядрото. Въпрос е обаче дали в конфигурационна папка grub е наличен конфигурационния файл grub.cfg.

За съжаление НЕ. Налични са модулите които ще зареди ядрото, но без grub.cfg. Това усложнява нещата. Ядрото няма да знае кои модули да зареди в паметта. Ще се наложи ръчно да ги указваме. Тук искам да наблегна на един факт. Когато ремонтирате дадена система, трябва поне да знаете как работи. Имам в предвид следното. Трябва да знаете какви файлови системи ползва, на кой дял е корена на системата и има ли нещо специфично когато сте конфигурирали сървъра. Примерно vmlinux зарежда стандартно много модули които да са унифицирани за повечето машини, но INITRD зарежда конкретни модули за точно тази машина, с точно тази конфигурация. Конкретни параметри като драйвери за файлова система която ползвате (ext2, ext4, lvm, zfs и т.н.), драйвери за видовете дискове които ползвате (ata, sata, ssd и т.н.), драйвери за типа контролери за твърдите дискове, драйвери за шините на твърдите дискове. Всичко от този тип. След горното уточнение да заредим нужните ни модули за текущата система.

Заредихме някои модули за които се сещаме и пробваме да заредим ядрото vmlinuz...... Отговора беше: "Unknown command 'linux' / непозната команда 'linux'". Това означава, че сме забравили още някой модул да заредим. Дозареждаме модула linux и наново пробваме да заредим ядрото (vmlinuz и initrd). Този път всичко се зарежда успешно. Следва да стартираме системата чрез командата boot. Не се радвайте обаче, това не е края. Това ще се разбере чрез долните картинки.

Не може да стартира задача от /dev/disk/by-id/......... (ID на изгорелия диск).

Все пак зареди някаква ОС. Предупреждава за грешки които може да се видят чрез командата jounalctl -xb. За сега това не ни вълнува. Предлага ни да вкараме паролата на ROOT за да продължим да работим със системата. Вкарваме паролата и продължаваме.

Все пак заредихме. Имаме ROOT права в работата на тази сесия. Ще може да правим някакви конфигурации за по-нататъшна работа. Да проверим все пак какво имаме:

Почти цялата система. Липсва само дяла /dev/sda2 - (/boot). Това е така защото не е описан в /etc/fstab. Да го опишем:

Чрез горните команди отделяме само частта UUID необходима за описване в /etc/fstab. Да редактираме и самия файл /etc/fstab.

Спираме зареждането на /boot от счупения диск, като маркирахме с # третия одолу нагоре ред. С най-долния ред дефинираме, че новия дял на здравия диск ще е зареждащ. На практика новия дял е /dev/sdb2 но е показан като UUID. До тук с първите настройки. Рестартираме системата.

За някои може да е изненада но GRUB отново не се зареди. Този път с по-малката грешка. Липсва само конфигурационния файл /boot/grub/grub.cfg. Най-отгоре казах, че няма да отделям друга глава за ремонт само на grub>, защото е част от проблема grub rescue>. Ето ти и втората част.

Проверяваме отново активните дискове и дялове чрез командата ls. Дефинираме наново root и prefix. Виждаме, че имаме достъп до ядрото с модулите.

Зареждаме необходимите модули за ядрото

Зареждаме ядрото и стартирам системата. Вече зареждаме нормално.

df -h >Filesystem Size Used Avail Use% Mounted on udev 1.9G 0 1.9G 0% /dev tmpfs 394M 604K 393M 1% /run zp0/debian 26G 693M 25G 3% / zp0/debian/home 25G 128K 25G 1% /home zp0/debian/var 25G 114M 25G 1% /var tmpfs 2.0G 0 2.0G 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock /dev/sda2 2.0G 101M 1.7G 6% /boot tmpfs 394M 0 394M 0% /run/user/0 tmpfs 394M 0 394M 0% /run/user/1000

Даже /boot се е заредил. Остава да инсталираме и запишем новите конфигурации на GRUB.

grub-install /dev/disk/by-id/ata-VMware_Virtual_SATA_Hard_Drive_01000000000000000001 Installing for i386-pc platform. Installation finished. No error reported. update-initramfs -u -k all update-initramfs: Generating /boot/initrd.img-5.10.0-21-amd64 update-initramfs: Generating /boot/initrd.img-5.10.0-20-amd64 update-grub Generating grub configuration file ... Found linux image: /boot/vmlinuz-5.10.0-21-amd64 Found initrd image: /boot/initrd.img-5.10.0-21-amd64 Found linux image: /boot/vmlinuz-5.10.0-20-amd64 Found initrd image: /boot/initrd.img-5.10.0-20-amd64 Warning: os-prober will be executed to detect other bootable partitions. Its output will be used to detect bootable binaries on them and create new boot entries. done

Готово. В /boot се създаде папка grub, а в същата папка се създаде и конфигурационния файл grub.cfg с текущите настройки. Рестартираме се. Всичко тръгва нормално.

Ремонт на GRUB при UEFI

За начало какви са разликите: - В предния случай едната част на GRUB се инсталираше в MBR (първите 512 байта на диска). При UEFI e различно. Нямаме MBR, а имаме EFI Boot Loader. - При BIOS можем да имаме само 4 първични дяла. Тук може да са на практика безкрайно много. - При BIOS системата за зареждане не беше много сигурна. Тук сигурността е на много по-високо ниво. И да припомним как се работи при BIOS и UEFI:

Веднага разликата: При BIOS, GRUB записва данни в MBR, при UEFI GRUB работи с EFI. Да покажем сега някои грешки при работа с UEFI и как се решават. За целта ще счупим нещо работещо за да демонстрираме решение на проблем. Да проверим какво имаме и да решим каква грешка да имитираме:

BIOS е заредил първата част на GRUB, в MBR. Втората част също е заредена (ядро с модули). Липсва конфигурационния файл grub.cfg

Дефинираме мястото на ядрото и модулите които трябва да зареди. Папката grub съществува но от по-рано знаем, че липсва grub.cfg. На практика се вижда, че е така.

Зареждаме ядрата нарочно грешно. Пътя на корена указваме да е /dev/sda3, а ние работим с ZFS файлова система. Да видим какво ще се получи:

Както се и очакваще. ROOT устройството не е правилно указано. vmlinuz грешно е указал къде се намира корена на системата. Да видим какво все пак сме заредили:

GRUB е завършил своята работа. Заредил е ядрата с модулите, след това е заредил INITRAMFS в паметта и му е предал управлението. За съжаление последния не знае какво да прави, защото му е казано root=/dev/sda3. Ако работехме с файлова система Ext4, Ext3 или Ext2 без LVM това щеше да работи, защото ядрото зарежда по-подразбиране модулите за ext* файлови системи, но не е заредило ZFS файловата система и спира до тук, чакайки да му кажем от къде да ги вземе. Погледнете обаче, липсва /boot. Да заредим модула за файловата система ZFS.

Модула ZFS се зареди успешно. От тук нататък ще може да заредим zpool-овете които сме създали или дисковете които ползваме.

zpool list - нямаме заредени пулове, zfs list - нямаме заредени dataset-ове, zpool import - можем да импортираме zpool-a zp0. Ако прочетете в Интернет ще видите, че предлагат пула да се зареди с: zpool import -R /root -N. -R указва ALTROOT (временното изместване на пула). Това добре, но -N казва, че не е необходимо да се импортира dataset-a. Грубо казано, импортираме пула, но точка на монтиране на dataset-a забраняваме. Нас такава команда не ни трябва. Затова:

Импортирахме zpool zp0. Казахме му чрез -R /root коренния dataset zp0/debian да се намира в /root. Също така казахме dataset-a, който се създава автоматично с изграждането на zpool zp0 никъде да не се монтира (както си беше оригинално направена системата). Накрая проверяваме как сме импортирали zp0. Виждаме, че ALTROO (изместване точката на монтиране спрямо създателя) е дефинирал да се измести монтирането в каталога /root. Когато погледнем dataset-овете чрез zfs list виждаме основния къде е монтиран и съответно дъщерните къде са монтирани. Всичко е правилно. Да погледнем състоянието на zpool-a zp0

Всичко е правилно. Имаме импортиран пул zp0, който е ONLINE (работещ) и е в режим mirror. За да продължим с зареждането на системата накрая пишем командата exit. Всичко тръгва без грешка до края, трябва само да вкарате име и парола за да влезете да работите в системата. Само едно уточнение: Ако трябва да заредите повече от един пул. Преди да излезете от INITRAM-a чрез exit, трябва да импортирате всички пулове които ползвате и накрая продължавате с exit. След като заредите правилно системата, ще имате достъп до /boot, /boot/grub, /etc/fstab и всичко което има системата. Значи ще трябва наново да инсталирате GRUB, ако не е инсталиран правилно и да обновите initramfs, като и grub. Толкова за INITRAMFS. С това приключвам така сложната за някои хора тема, GRUB.