GNU GRUB - GNU GRUB

GNU GRUB
GNU GRUB logo
GNU GRUB logo
Debian Unstable GRUB2 (2015) .png
GRUB v2 kører i teksttilstand
Originale forfattere Erich Boleyn
Udvikler (er) GNU -projekt
Første udgivelse 1995 ; 26 år siden ( 1995 )
Stabil udgivelse
2.06 (GRUB 2) / 8. juni 2021 ; 4 måneder siden ( 2021-06-08 )
Depot
Skrevet i Samling , C
Operativ system Linux , macOS , BSD , ( Solaris / illumos (x86 -port)) og Windows (gennem kædelastning)
Platform IA-32 , x86-64 , IA-64 , ARM , PowerPC , s390x , MIPS og SPARC
Tilgængelig i Engelsk og andre
Type Bootloader
Licens GPLv3
Internet side www .gnu .org /software /grub /

GNU GRUB (forkortelse for GNU GRand Unified Bootloader , almindeligvis omtalt som GRUB ) er en boot loader -pakke fra GNU -projektet . GRUB er referenceimplementeringen af Free Software Foundation 's Multiboot Specification , som giver en bruger mulighed for at starte et af flere operativsystemer installeret på en computer eller vælge en specifik kernekonfiguration tilgængelig på et bestemt operativsystems partitioner.

GNU GRUB blev udviklet fra en pakke kaldet Grand Unified Bootloader (et spil om Grand Unified Theory ). Det bruges overvejende til Unix-lignende systemer. Det GNU-operativsystemet bruger GNU GRUB som sin boot loader, som de fleste Linux-distributioner og Solaris-operativsystemet på x86-systemer, der starter med Solaris 10 1/06 udgivelse.

Operation

GRUB2 på MBR -partitioneret harddisk; trin 1 ( boot.img) kan alternativt skrives ind i en af partition boot -sektorer .
GRUB2 på en GPT -partitioneret harddisk, opstart på BIOS -firmware eller UEFI -kompatibilitetstilstand (CSM)

Opstart

Når en computer tændes, finder BIOS den konfigurerede primære bootable enhed (normalt computerens harddisk) og indlæser og udfører det første bootstrap -program fra master boot record (MBR). MBR er den første sektor på harddisken, med nul som offset (sektortælling starter ved nul). I lang tid har størrelsen på en sektor været 512 bytes, men siden 2009 er der tilgængelige harddiske med en sektorstørrelse på 4096 bytes, kaldet Advanced Format -diske. Fra oktober 2013 er der stadig adgang til sådanne harddiske i 512-bytes sektorer ved hjælp af 512e-emuleringen .

Den gamle MBR -partitionstabel understøtter maksimalt fire partitioner og optager 64 bytes tilsammen. Sammen med den valgfri disksignatur (fire bytes) og disketidsstempel (seks bytes) efterlader dette mellem 434 og 446 bytes til rådighed for maskinkoden til en boot -loader. Selvom sådan en lille plads kan være tilstrækkelig til meget enkle bootloaders, er den ikke stor nok til at indeholde en boot loader, der understøtter komplekse og flere filsystemer , menudrevet valg af boot-valg osv. Bootloaders med større fodaftryk er således opdelt i stykker, hvor det mindste stykke passer ind i og befinder sig inden for MBR, mens større stykker gemmes andre steder (f.eks. i tomme sektorer mellem MBR og den første partition) og påberåbes af boot loaderens MBR -kode.

Operativsystemets kernebilleder er i de fleste tilfælde filer, der findes på passende filsystemer, men konceptet med et filsystem er ukendt for BIOS. I BIOS-baserede systemer er en boot loader således pligt til at få adgang til indholdet af disse filer, så den kan indlæses i RAM og udføres.

En mulig tilgang for bootloadere til at indlæse kernebilleder er ved direkte adgang til harddisksektorer uden at forstå det underliggende filsystem. Normalt kræves et yderligere niveau af indirektion i form af kort eller kortfiler  - hjælpefiler, der indeholder en liste over fysiske sektorer optaget af kernebilleder. Sådanne kort skal opdateres hver gang et kernebillede ændrer sin fysiske placering på disken på grund af installation af nye kernebilleder, defragmentering af filsystem osv. I tilfælde af at kortene ændrer deres fysiske placering, skal deres placeringer opdateres inden for boot loader's MBR -kode, så sektorens indirektionsmekanisme fortsætter med at fungere. Dette er ikke kun besværligt, men det efterlader også systemet behov for manuelle reparationer, hvis noget går galt under systemopdateringer.

En anden tilgang er at gøre en boot loader opmærksom på de underliggende filsystemer, så kernebilleder konfigureres og tilgås ved hjælp af deres faktiske filstier . Det kræver, at en boot loader indeholder en driver til hvert af de understøttede filsystemer, så de kan forstås og tilgås af selve boot loader. Denne fremgangsmåde eliminerer behovet for hardkodede placeringer af harddisksektorer og eksistensen af ​​kortfiler og kræver ikke MBR -opdateringer, efter at kernebillederne er tilføjet eller flyttet rundt. Konfiguration af en boot loader gemmes i en almindelig fil, som også er tilgængelig på en filsystembevidst måde for at opnå boot-konfigurationer før den egentlige opstart af eventuelle kernebilleder. Som følge heraf reduceres muligheden for at det går galt under forskellige systemopdateringer betydeligt. Som en ulempe har sådanne bootloaders øget intern kompleksitet og endnu større fodaftryk.

GNU GRUB bruger den anden tilgang ved at forstå de underliggende filsystemer. Selve boot loader er opdelt i flere faser , så den kan passe ind i MBR boot -ordningen.

To større versioner af GRUB er i almindelig brug: GRUB version 1, kaldet GRUB legacy, er kun udbredt i ældre udgivelser af Linux -distributioner. GRUB 2 blev skrevet fra bunden og havde til formål at erstatte sin forgænger, og bruges nu af et flertal af Linux -distributioner.

Version 0 (GRUB Legacy)

GRUB v1 menu (kører som en del af Ubuntu 8.04 installation)

GRUB 0.x følger en to-trins tilgang. Master boot -posten (MBR) indeholder normalt GRUB -trin 1, eller kan indeholde en standard MBR -implementering, som kædelaster GRUB -trin 1 fra den aktive partitions boot -sektor . I betragtning af den lille størrelse af en støvlesektor (512 bytes) kan trin 1 kun gøre meget mere end at indlæse det næste trin i GRUB ved at indlæse et par disksektorer fra et fast sted nær starten af ​​disken (inden for dens første 1024 cylindre).

Trin 1 kan indlæse trin 2 direkte, men det er normalt indstillet til at indlæse trin 1.5. , placeret i de første 30 KiB harddisk umiddelbart efter MBR og før den første partition. Hvis denne plads ikke er tilgængelig (usædvanlig partitionstabel, specielle diskdrivere, GPT eller LVM -disk) vil installationen af trin 1.5 mislykkes. Den fase 1.5 billede indeholder filsystemet drivere, der gør det muligt at direkte indlæse etape 2 fra ethvert kendt sted i filsystemet, for eksempel fra /boot/grub. Trin 2 indlæser derefter standardkonfigurationsfilen og alle nødvendige moduler.

Version 2 (GRUB 2)

GRUB 2 - MBR vs. GPT -partitionering og startsekvens visualiseret (systemer, der bruger BIOS -firmware).

Opstart på systemer ved hjælp af BIOS -firmware

  • Se illustration i sidste billede til højre.
  • boot.img( trin 1 ) skrives til de første 440 bytes i Master Boot Record (MBR boot -kode i sektor 0) eller eventuelt i en partitions boot -sektor (PBR). Det adresserer diskboot.imgmed en 64-bit LBA-adresse. Det faktiske sektornummer er skrevet af grub-install. diskboot.imger den første sektor af core.imgmed det ene formål at indlæse resten af core.imgidentificeret ved LBA -sektornumre også skrevet af grub-install.
  • På MBR -partitionerede diske lagres core.img( trin 1.5 ) i de tomme sektorer (hvis tilgængelig) mellem MBR og den første partition. Nylige operativsystemer foreslår et 1 MiB -hul her for justering (2047*512 byte eller 255*4KiB sektorer). Dette hul var tidligere 62 sektorer (31 KiB) som en påmindelse om sektornummergrænsen for Cylinder-Head-Sector (C/H/S) adressering, der blev brugt af BIOS før 1996, og core.imger derfor designet til at være mindre end 32 KiB.
  • På GPT-partitionerede diske: primære partitioner er ikke begrænset til 4, og core.imger således skrevet til sin egen lille (1 MiB), filsystemfrie BIOS-bootpartition.
  • trin 2: core.img indlæser /boot/grub/i386-pc/normal.modfra partitionen konfigureret af grub-install. Hvis partitionsindekset er ændret, kan GRUB ikke finde normal.modog præsentere brugeren for GRUB Rescue -prompten.
  • Afhængigt af hvordan GRUB2 blev installeret, den /boot/grub/er enten i roden partition af Linux-distributionen, eller i den separate / boot -partition.
  • efter normal.mod loaded: normal.mod parser /boot/grub/grub.cfgeventuelt indlæser moduler og viser menuen (fx for grafisk brugergrænseflade og filsystemet støtte.).

Opstart på systemer ved hjælp af UEFI -firmware

  • /efi/<distro>/grubx64.efi(for x64 UEFI -systemer) installeres som en fil i EFI -systempartitionen og startes direkte af firmwaren uden en boot.imgi MBR -sektor 0. Denne fil som stage1 og stage1.5.
  • /boot/grub/kan installeres på EFI System Partition eller den separate /boot partition.
  • For x64 UEFI -systemer er stage2 /boot/grub/x86_64-efi/normal.modfilen og andre /boot/grub/filer.

Efter opstart

GRUB præsenterer en menu, hvor brugeren kan vælge mellem operativsystemer (OS) fundet af grub-install. GRUB kan konfigureres til automatisk at indlæse et bestemt operativsystem efter en brugerdefineret timeout. Hvis timeout er indstillet til nul sekunder, ⇧ Shiftgør det muligt at få adgang til startmenuen ved at trykke og holde, mens computeren starter.

I menuen til valg af operativsystem accepterer GRUB et par kommandoer:

  • Ved at trykke på eer det muligt at redigere kerneparametre for det valgte menupunkt, før operativsystemet startes . Grunden til at gøre dette i GRUB (dvs. ikke at redigere parametrene i et allerede bootet system) kan være en nødsituation: systemet har ikke startet. Ved hjælp af kerneparameterlinjen er det blandt andet muligt at angive et modul, der skal deaktiveres (sortlistet) for kernen. Dette kan være påkrævet, hvis det specifikke kernemodul er brudt og dermed forhindrer opstart. For eksempel for at sortliste kernemodulet nvidia-current, kunne man tilføje modprobe.blacklist=nvidia-currenti slutningen af ​​kerneparametrene.
  • Ved at trykke cpå indtaster brugeren kommandolinjen GRUB. GRUB-kommandolinjen er ikke en almindelig Linux-shell, f.eks. Bash , og accepterer kun visse GRUB-specifikke kommandoer, dokumenteret af forskellige Linux-distributioner.

Når boot -muligheder er valgt, indlæser GRUB den valgte kerne i hukommelsen og overfører kontrollen til kernen. Alternativt kan GRUB overføre kontrollen over opstartsprocessen til en anden boot loader ved hjælp af kædebelastning . Dette er den metode, der bruges til at indlæse operativsystemer, der ikke understøtter Multiboot -specifikationen eller ikke understøttes direkte af GRUB.

Historie

GRUB blev oprindeligt udviklet af Erich Boleyn som en del af arbejdet med opstart af operativsystemet GNU / Hurd , udviklet af Free Software Foundation . I 1999 gjorde Gordon Matzigkeit og Yoshinori K. Okuji GRUB til en officiel softwarepakke i GNU -projektet og åbnede udviklingsprocessen for offentligheden. Fra 2014 har størstedelen af ​​Linux -distributioner vedtaget GNU GRUB 2 samt andre systemer såsom Sonys PlayStation 4 .

Udvikling

GRUB version 1 (også kendt som "GRUB Legacy") er ikke længere under udvikling og udfases. GNU GRUB -udviklerne har skiftet fokus til GRUB 2, en komplet omskrivning med mål, herunder at gøre GNU GRUB renere, mere robust, mere bærbar og mere kraftfuld. GRUB 2 startede under navnet PUPA . PUPA blev støttet af Information Technology Promotion Agency (IPA) i Japan. PUPA blev integreret i GRUB 2 udvikling omkring 2002, da GRUB version 0.9x blev omdøbt til GRUB Legacy.

Nogle af målene med GRUB 2-projektet inkluderer understøttelse af ikke-x86- platforme , internationalisering og lokalisering , ikke-ASCII-tegn, dynamiske moduler, hukommelsesstyring , et script -minisprog , migrerende platformspecifik (x86) kode til platformspecifikke moduler, og en objektorienteret ramme. GNU GRUB version 2.00 blev officielt frigivet den 26. juni 2012.

Tre af de mest udbredte Linux -distributioner bruger GRUB 2 som deres mainstream boot loader. Ubuntu vedtog det som standard boot loader i sin 9.10 version af oktober 2009. Fedora fulgte trop med Fedora 16 udgivet i november 2011. OpenSUSE vedtog GRUB 2 som standard boot loader med sin 12.2 udgivelse af september 2012. Solaris vedtog også GRUB 2 den x86 -platformen i Solaris 11.1 -udgivelsen.

I slutningen af ​​2015 blev udnyttelsen af ​​at trykke backspace 28 gange for at omgå login -adgangskoden fundet og hurtigt rettet.

Varianter

GNU GRUB er gratis og open-source software , så flere varianter er blevet oprettet. Nogle bemærkelsesværdige, som ikke er blevet fusioneret til GRUB -hovedlinjen:

  • OpenSolaris indeholder en modificeret GRUB Legacy, der understøtter Solaris VTOC-udsnit, automatisk 64-bit kernelvalg og opstart fra ZFS (med komprimering og flere boot-miljøer).
  • Google Summer of Code 2008 havde et projekt for at understøtte GRUB -arv til opstart fra ext4 -formaterede partitioner.
  • Den Syllable projektet lavet en modificeret version af GRUB at indlæse systemet fra dets AtheOS File System .
  • TrustedGRUB udvider GRUB ved at implementere verifikation af systemintegriteten og opstartsprocessikkerheden ved hjælp af Trusted Platform Module (TPM).
  • Intel BIOS Implementation Test Suite (BITS) giver et GRUB -miljø til test af BIOS'er og især deres initialisering af Intel -processorer, hardware og teknologier. BITS understøtter scripting via Python og inkluderer Python API'er for at få adgang til forskellige funktionaliteter på lavt niveau på hardwareplatformen, herunder ACPI-, CPU- og chipsætregistre, PCI og PCI Express.
  • GRUB4DOS er en gammel GRUB -gaffel, der forbedrer installationsoplevelsen på DOS og Microsoft Windows ved at lægge alt udover GRLDR -konfigurationen i en billedfil. Det kan indlæses direkte fra DOS, eller af NTLDR eller Windows Boot Manager . GRUB4DOS er under aktiv udvikling og understøtter fra 2021 UEFI.

Hjælpeprogrammer

GRUB konfigurationsværktøjer

StartUp-Manager , et program, der bruges til at konfigurere GRUB

Opsætningsværktøjerne, der bruges af forskellige distributioner, indeholder ofte moduler til opsætning af GRUB. For eksempel YaST2SUSE Linux og openSUSE distributioner og AnacondaFedora / RHEL distributioner. StartUp-Manager og GRUB Customizer er grafiske konfigurationseditorer til Debian-baserede distributioner. Udviklingen af ​​StartUp-Manager stoppede den 6. maj 2011, efter at hovedudvikleren angav personlige grunde til ikke aktivt at udvikle programmet. GRUB Customizer er også tilgængelig for Arch-baserede distributioner.

Til GRUB 2 er der KDE -kontrolmoduler.

GRLDR ICE er et lille værktøj til at ændre standardkonfigurationen af ​​grldr -fil til GRUB4DOS.

Boot reparationsværktøjer

Boot-Repair er et simpelt grafisk værktøj til at gendanne fra hyppige boot-relaterede problemer med GRUB og Microsoft Windows bootloader. Denne applikation er tilgængelig under GNU GPL -licens . Boot-Repair kan reparere GRUB på flere Linux-distributioner, herunder, men ikke begrænset til, Debian, Ubuntu, Mint , Fedora, openSUSE og Arch Linux .

GRUB Customizer

Installer til Windows

Grub2Win er en Windows open source-softwarepakke. Det giver GNU GRUB mulighed for at starte fra et Windows -bibliotek. Setup -programmet installerer GNU GRUB version 2.06 til en NTFS -partition. En Windows GUI -applikation bruges derefter til at tilpasse GRUB -startmenuen, temaer, UEFI -opstartsrækkefølge, scripts osv. Alle GNU GRUB -scripts og -kommandoer understøttes for både UEFI- og ældre systemer. Grub2Win kan konfigurere GRUB til multiboot af Windows, Ubuntu, openSuse, Fedora og mange andre Linux -distributioner. Det er frit tilgængeligt under GNU GPL -licensSourceForge .

Alternative boot-ledere

Styrken ved GRUB er den brede vifte af understøttede platforme, filsystemer og operativsystemer, hvilket gør det til standardvalget for distributioner og integrerede systemer.

Der er dog boot-ledere målrettet mod slutbrugeren, der giver mere venlig brugeroplevelse, grafisk OS-vælger og enklere konfiguration:

  • rEFInd -Grafisk boot-manager i Macintosh-stil, kun til UEFI-baserede computere (BIOS understøttes ikke).
  • CloverEFI -Grafisk boot-manager i Macintosh-stil til BIOS og UEFI-baserede computere. Emulerer UEFI med en stærkt modificeret DUET fra TianoCore -projektet. Kræver en FAT -formateret partition, selv på BIOS -systemer. Som en fordel har den en grundlæggende filsystemdriver i partitionsstartsektoren, hvilket undgår skrøbeligheden ved GRUB 2., 3. etape og den berygtede GRUB Rescue -prompt. Brugergrænsefladen ligner rEFInd: begge arver fra den forladte boot-manager rEFIt .

Ikke-grafiske alternativer:

  • systemd-boot -Let, UEFI-kun boot-manager med tekstbaseret OS-vælgermenu.

eksterne links

Vejledning og fejlfinding

Distributionswikier har mange løsninger på almindelige problemer og tilpassede opsætninger, der kan hjælpe dig:

Dokumentation

Indledende artikler

Tekniske egenskaber

Se også

Referencer