Acum câteva zile m-am decis să îmi instalez Ubuntu 16.04 de pe stick. Ceea ce ar fi trebuit să fie simplu, de făcut repede într-o după amiază, s-a transformat imediat într-un maraton al răbdării. Dacă ești grăbit poți să sari peste explicații și să dai clic aici.

Am mers pe site-ul oficial, am descărcat imaginea .iso și aveam doar un stick la îndemână. Așa că le-am urmat tutorialul care îmi spunea:

După ce s-a finalizat procesul am restartat calculatorul și am schimbat ordinea de bootare( am pus prima oară USB HDD, iar apoi Windows Boot Manager). Spre surprinderea mea, Windows Boot Manager rula de fiecare dată, ordinea de bootare părând a nu avea vreun efect.

De curiozitate, am zis să încerc bootarea folosind Legacy Mode. Încă din start, opțiunea aceasta era doar temporară, pentru a vedea dacă stick-ul funcționează. Temporară, deoarece dacă aș fi instalat Ubuntu în Legacy Mode, GRUB ar fi fost vizibil doar de aici, iar asta ar fi însemnat să nu pot boota în Windows. Și într-adevăr, în Legacy mergea.

Acest lucru mi-a stârnit curiozitatea. De ce în modul UEFI normal, boot loader-ul pare cumva să țină cont de sistemul de operare? Răspunsul prematur și incomplet este că nu pare, ci chiar ține cont, într-un anumit grad, de sistemul de operare(ține cont și de noțiunea de partiții ale disk-ului și boot-loadere).  Mi-am dat seama că nu cunosc, măcar la nivel elementar, cum funcționează UEFI-ul și care sunt diferențele față de BIOS…tot prematur, nu sunt deloc asemănătoare, decât la nivelul că sunt specificații premergătoare încărcării sistemului de operare. Așa că…

[divider type=”dotted”]

Ce este UEFI? UEFI vs. BIOS

O luăm în ordine cronologică, așa că vorbim prima oară despre BIOS(Basic Input Output System).

BIOS

După cum sugerează și numele este un program low-level, dar foarte important – într-o așa măsură, încât pe placa de bază există un chip dedicat numai lui. Când computerul pornește este treaba BIOS-ului să verifice componentele dacă funcționează, iar dacă totul este în regulă dă controlul mai departe sistemului de operare.

Fiecare disc conține un sector special, numit MBR(Master Boot Record). Acesta e un alt standard de facto:

  • conține informații ce specifică tabela de partiții a computerului
  • conține un boot-loader, ce este o bucată mică de cod ce poate fi executată de BIOS și cu ajutorul căreia se localizează sistemul de operare pe disc și se bootează

Cam tot ce știe BIOS, în contextul pornirii sistemului, este ce disc conține sistemul de operare. Astfel, tu îi poți spune doar spre ce disc să se uite pentru a boota sistemul. Programul va căuta în locația specificată după MBR și va executa bootloader-ul.

 

UEFI

[label style=”red”]Warning!! Ia-ți o cană de cafea și-o doză de răbdare.[/label]

Încă de la început vă spun că tot ce voi scrie mai jos este ceva orientativ. Documentația oficială are peste 2600 de pagini, vă dați seama că nu am citit-o integral. Am încercat să citesc lucrurile de bază și am evitat toată chestia cu protocoale(aceea părea pentru ingineri firmware și-am zis că nu-mi bat capul). În fine, o să vorbim puțin despre:

  1. GUID Partition Table(GPT)
  2. EFI System Table
  3. Boot Manager
  4. Secure Boot

↑ Acestea corespund cu capitolele 3, 4, 5 și 30 din documentația oficială.

1. GUID Partition Table(GPT)

Tabela de partiții GUID este strâns legată de specificațiile UEFI. Asta nu e ceva extraordinar – GPT e doar un standard pentru a face tabele de partiții – asta e informația de la începutul unui disc ce definește ce partiții conține acel disc.

 

2. EFI System Table

Conceptul EFI system Partitions și EFI System Table e un răspuns la problema ce în trecut era rezolvată cu spațiul MBR de la BIOS. Conceptul acesta cu ceva spațiu special la începutul discului unde trăiește bootloader-ul chiar nu e prea grozav(nu e spatiu mult in primul rand). EFI System Partitions sunt chiar răspunsul la problema asta.

În esență spunem că nivelul firmware trebuie să fie capabil să citească câteva tipuri de codificări a sistemului de fișiere. Documentația UEFI vorbește de FAT12, FAT16, FAT32.

The file system supported by the Extensible Firmware Interface is based on the FAT file system. EFI defines a specific version of FAT that is explicitly documented and testable. Conformance to the EFI specification and its associate reference documents is the only definition of FAT that needs to be implemented to support EFI. To differentiate the EFI file system from pure FAT, a new partition file system type has been defined.

EFI encompasses the use of FAT32 for a system partition, and FAT12 or FAT16 for removable media. The FAT32 system partition is identified by an OSType value other than that used to identify previous versions of FAT. This unique partition type distinguishes an EFI defined file system from a normal FAT file system. The file system supported by EFI includes support for long file names.

Astfel, o partiție EFI este orice partiție formatată într-una din variantele FAT specificate în documentația FAT și care conține un tip de partiție GPT specific pentru a ajuta firmware-ul să o găsească. Toată chestia asta pornește de la faptul că vrem să fim siguri ca firmware-ul e capabil să citească informația dintr-o partiție cât de cât normală de disc.

 

3. Boot Manager

În documentația oficială ni se spune ceva de genul:

Boot managerul UEFI este un motor de politică firmware ce poate fi configurat prin modificarea variabilelor globale NVRAM definite la nivelul arhitecturii. Boot managerul va încerca să încarce driverele UEFI și aplicațiile UEFI(inclusiv UEFI OS boot loaders) într-o ordine definită de către variabilele globale NVRAM. Firmware-ul platformei va trebui să folosească ordinea de bootare specificată de variabilele NVRAM pt o bootare normală.

Și, păstrându-se limbajul standardizat, conchidem cu:

  • Ordinea de bootare e citită dintr-o variabilă NVRAM def. global
  • Variabila globală conține și un pointer la device-ul hardware și la o filă din acel device spre imaginea UEFI ce trebuie încărcată
  • Variabila ar putea conține căi către partiția și directorul SO-ului alături de alte directoare de configurare specifice

Ce-am înțeles eu, la un nivel simplificat, este că acel UEFI boot manager este precum un boot menu Având BIOS, acel meniu de bootare ar fi fost compus din discurile conectate la sistem la pornire(de ce fel or fi ele). La UEFI totuși, treaba stă diferit.

UEFI boot manager poate fi configurat – adică pot să adaug sau să elimin intrări din acel boot menu. Firmware-ul poate să(de fapt cred că e obligat dacă respectă toate protocoalele) genereze intrări în acest boot menu, în funcție de discurile atașate la sistem + alte configurări la nivel firmware. Poate fi și examinat…

Un lucru grozav este că UEFI oferă un mecanism prin care putem să examinăm acest boot menu din alte nivele. Sincer la Windows n-am prea găsit cum(dacă ști te rog spune-mi cum), dar cu Linux e destul de faină și ușoară treaba fiindcă există [label style=”grey”]efibootmgr[/label]. Scrieți în terminal[label style=”grey”] man efibootmgr[/label] și-o să vedeți o mulțime de chestii interesante.

[root@system directory]# efibootmgr -v
BootCurrent: 0002
Timeout: 3 seconds
BootOrder: 0003,0002,0000,0004
Boot0000* CD/DVD Drive  BIOS(3,0,00)
Boot0001* Hard Drive    HD(2,0,00)
Boot0002* Fedora        HD(1,800,61800,6d98f360-cb3e-4727-8fed-5ce0c040365d)File(\EFI\fedora\grubx64.efi)
Boot0003* opensuse      HD(1,800,61800,6d98f360-cb3e-4727-8fed-5ce0c040365d)File(\EFI\opensuse\grubx64.efi)
Boot0004* Hard Drive    BIOS(2,0,00)P0: ST1500DM003-9YN16G        .
[root@system directory]#

Dacă am porni firmware-ul UEFI în modul default, fără a face ceva modificări de care o să vorbesc puțin mai încolo, atunci ar trebui să booteze acele intrări din boot menu, în ordinea listată în BootOrder(vezi exemplul de mai sus – mulțumesc unui tip de pe happyassasin.net, ce a scris și el un articol pe tema UEFI).

 

Intrări de bootare compatibile UEFI

Folosindu-ne de exemplul anterior, voi detalia puțin ce reprezintă Boot0002 și Boot0003. Ambele intrări sunt instalări a celor două sisteme de operare Linux, OpenSUSE și Fedora. Ambele SO-uri sunt compatibile UEFI și tot ce spun este „încarcă-mi fila asta din această partiție”. Partiția este [label style=”grey”]HD(1,800,61800,6d98f360-cb3e-4727-8fed-5ce0c040365d)[/label] și e formată după un anumit protocol UEFI(EFI_DEVICE_PATH_PROTOCOL – există o secțiune grozavă în documentație la acest protocol, dar nu am citit-o).

Partiția în cauză poate fi cu siguranță calificată ca partiție EFI, fiindcă ăsta-i formatul de partiție la care suntem siguri că firmware-ul îl poate accesa.

Aici putem vedea și mecanismul prin care UEFI permite sistemelor de operare să se facă disponibile la bootare: sistemul de operare instalează un bootloader care încarcă kernel-ul sistemului într-o partiție EFI și adaugă o intrare în UEFI boot manager cu un nume – derivat din numele sistemului de operare – și locația(acel pointer de care vorbeam adineauri) bootloader-ului.

 

Configurarea procesului de bootare(dintr-un sistem de operare)

Așa cum am spus mai sus, spre deosbire de BIOS, cu UEFI putem configura procesul de bootare de la nivelul sistemului de operare. Dacă ai un firmware mai nebun, poate trebuie să faci și asta pentru a putea face ce îți dorești.

Folosind efibootmgr putem să adăugăm, ștergem sau modifica intrări din boot manager, dar și alte lucruri. Putem schimba ordinea de bootare. Putem să îi spunem să booteze o anumită intrare din listă, fără a se folosi de BootOrder(același lucru e valabil și la Windows, unde mecanismul FastBoot crește prioritatea intrării Windows Boot Manager, așa că indiferent de cum o setăm, tot ea ajunge prima să ruleze).Tocmai de aceea, de multe ori, poate este necesar ca configurarea de bootare să se facă de la nivelul sistemului de operare și nu de la nivelul firmware al computerului.

 

4. Secure Boot

Am ajuns și la Secure Boot. O mulțime de lucruri suplimentare puteți găsi în capitolul 30 din specificațiile UEFI. Foarte simplificat, acest mecanism spune că un firmware poate să conțină un set de semnături și poate astfel refuza orice executabil EFI care nu conține una din acele semnături.

Folosirea cheilor publice și private pentru verificarea integrității nu e ceva nou. Aproape toate distribuțiile Linux depind de ea – pachetele publice din repozitorii conțin un astfel de protocol, iar dacă încerci să instalezi ceva fără o cheie acceptată o să ai o mulțime de mesaje, warning-uri ș.a.m.d. Secure Boot e tocmai acest mecanism numa aplicat lanțului de bootare.

[divider type=”dotted”]

Fast Startup

Motivul pentru care ordinea de bootare nu era respectată avea legătură cu Windows 10/8 și o anumită opțiune, numită Fast Startup(sau Fast Boot în Windows 8) . Am detaliat mai sus căteva din trăsăturile esențiale ale mecanismului UEFI și cum pot sistemele de operare să aibă mai mult control asupra procesului de bootare. Totuși, rămânem cu problema…

 

Ce este Fast Startup?

Este un mecanism ce combină elementele unui shutdown + hibernare. Când Fast Startup e activat, Windows închide aplicațiile și deloghează userii ca într-un shutdown normal. În acest punct, Windows e într-o stare similară cu cea de la bootare: fără useri sau programe pornite, dar kernel-ul Windows e încărcat, iar sistemul rulează. În acest punct, Windows alertează prin drivere că device-ul trebuie să se pregătească pentru hibernare și de aceea va salva starea curentă a sistemului într-o filă de hibernare, după care va opri computerul.

Când pornești computerul, Windows nu va mai trebui să reîncarce kernel-ul, driverele și starea sistemului în mod individual, ci va încărca în RAM imaginea din fila de hibernare. Aici totuși este cheia mecanismului care explică și de ce o eventuală ordine a bootări este irelevantă. În primul rând, dacă ordinea de bootare chiar s-ar respecta ar fi mari probleme de securitate și interoperabilitate. Să detaliez de ce:

Pașii de bootare la activarea opțiunii FastStartup

Poate imaginea de mai sus e de la sine grăitoare, dar se poate vedea cum imediat după verificările POST(Power-on Self-Test) se citește acel hiberfile și nu se mai utilizează fișierele din sistemul de fișiere.

Așa că cea mai mare problemă, dar și cea mai urâtă, ar fi pierderile de date: atunci când vei crea o partiție NTFS(care Ubuntu poate s-o citească și s-o scrie fără probleme, iar Windows la fel), prin hibernare structura sistemului de fișiere se va păstra. Dacă vei încerca să salvezi un fișier de pe Ubuntu pe Windows(cum adesea facem cu toții, fiindcă avem acces la acele partiții și din Ubuntu) în acea partiție NTFS, la repornirea în Windows acel fișier se va pierde tocmai din cauză că se reține starea veche a sistemului de fișiere. Acesta e motivul pentru care nu ne atingem de Fast Boot când facem Dual Boot.

În general, dacă un disc e montat folosindu-se fast boot, Windows va pune discul și conținutul său într-un hiberfile. Orice modificare făcută sistemului  nu va fi vizibilă când acel hiberfile e restaurat. Asta include și discuri externe. Ubuntu va refuza oricum să monteze un disc ce conține un hiberfile.

 

Cum dezactivăm FastStartup în Windows 8/10

Mulțumită celor de howtogeek, vă pot arăta câteva imagini. Mergeți la PowerOptions(click dreapta pe bateria de lângă ceas):

Optiuni Startup - Choose what the power buttons do Opțiuni atunci când apăsăm butonul de Turn OnDezactivare optiune Turn On Fast Startup

That’s it!! Odată dezactivată opțiunea, ordinea de bootare se va respecta și vei putea selecta USB HDD, iar atunci vei putea boota în Linux din boot manager.

 

În concluzie, totul este verde și frumos până când vrei să faci dual-boot. Atunci viața ți se complică inutil și totul devine mai ambiguu. Soluțiile sunt relativ simple, dar pentru a înțelege cât de cât pe ce-apăsăm și ce butonăm, totul devine o cutie a Pandorei.

Lasă un comentariu

Adresa ta de email nu va fi publicată. Câmpurile obligatorii sunt marcate cu *