Van wat je al hebt gelezen in de titel van het bericht, zal ik uitleggen hoe je ArchLinux opstart (geen idee of het werkt op andere distributies) zonder enige vorm van bootloader op EFI- of UEFI-computers.
Eerste stap
Installeer efibootmgr (als je het nog niet hebt geïnstalleerd)
# pacman -S efibootmgr
Tweede stap
Mount efivarfs (indien nog niet gemonteerd)
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars
Derde stap
Voeg je distro toe aan de "Opstartvolgorde" van je computer
# efibootmgr -c -L "Arch Linux" -l /vmlinuz-linux -u "root=/dev/sdaX initrd=/initramfs-linux.img"
in mijn geval deed ik het zo
# efibootmgr -c -L "Arch Linux" -l /vmlinuz-linux -u "root=UUID=d5e93b09-02a8-4597-b059-3f87a8221825 initrd=/initramfs-linux.img quiet loglevel=0"
Laatste stap
Kijk of het werkte
# efibootmgr -v
Verwijder je bootorder-distro
Als het om de een of andere reden niet voor u heeft gewerkt of als u het idee om geen bootloader te gebruiken gewoon niet leuk vindt, kunt u het volgende doen:
Eerste stap
Kijk welk nummer overeenkomt met je distro in de opstartvolgorde
# efibootmgr -v
Je zou zoiets als dit moeten zien:
BootCurrent: 0000 Time-out: 0 seconden BootOrder: 0000,3000,2001,2002,2003 Boot0000 * Arch Linux HD (1,800,100000, bf49dd02-7af7-42bb-ac5d-967ea840e3f8) Bestand (\ vmlinuz-linux) root = .UUID = .d.5.e.9.3.b.0.9 .-. 0.2.a.8 .-. 4.5.9.7 .-. B.0.5.9 .-. 3.f.8.7.a.8.2.2.1.8.2.5. .initrd =. /. initramfs-.linux..img .quiet .loglevel = .0. Boot2001 * USB-station (UEFI) RC Boot2002 * Intern cd / dvd-rom-station (UEFI) RC Boot3000 * Interne harde schijf of solid-state schijf RC Boot3001 * Interne harde schijf of solid-state schijf RC Boot3002 * Interne harde schijf of solid-state schijf RC
Ze zullen zien dat het Boot0000 * markeert, maar in dit geval zijn we alleen geïnteresseerd in het nummer 0000
Tweede stap
Verwijder je bootorder-distro
# efibootmgr -b 0000 -B
bron: Arch Linux Wiki
BELANGRIJKE MEDEDELING
in de derde stap van dit item WERKT het commando dat ik gebruik NIET.
Ik probeer de oplossing te vinden, ik zal het posten als ik het vind
Hier de lijn die werkt
efibootmgr -c -L "Arch Linux" -l / vmlinuz-linux -u "root = UUID = d5e93b09-02a8-4597-b059-3f87a8221825 initrd = / initramfs-linux.img rustige loglevel = 0"
Ik vraag iedereen die de invoer kan bewerken, doe dit alsjeblieft
Klaar, gecorrigeerd toch? 🙂
Bedankt
Hoi. Ik deed dit al een tijdje geleden (hetzelfde in Arch Linux), en ik kan je vertellen dat mijn computer in ieder geval geen schade heeft opgelopen, mijn laptop is een Lenovo G480. Wat als het gebeurde, is dat toen de kernel werd bijgewerkt, het systeem niet langer opnieuw kon worden geladen en ik opnieuw alle procedures moest uitvoeren die u hier beschrijft; Nadat ik experimenten had gedaan, heb ik het systeem geladen (ik maak duidelijk dat het mijn fout was, niet die van het systeem), dus ik moest het opnieuw installeren en ik weet niet waarom ik het niet terug kon krijgen zonder de bootloader. Omdat ik toen geen tijd had om mezelf te vermaken met Griekse sfinxpuzzels en raadsels, heb ik grub geïnstalleerd en heb ik het nooit meer geprobeerd.
Nou, ik gebruik deze methode op mijn laptop (een HP pavilion n029-la), ik heb de kernel bijgewerkt en ik heb geen problemen gehad. Maar voor het geval mij zoiets overkomt, draag ik altijd een arch livecd in de koffer waarmee ik hem draag.
Ik heb het gelezen, en ja, het is waar dat na een kernelupdate het (efibootmgr) -commando in sommige geïsoleerde gevallen geen item kan maken (het kan alleen worden verwijderd). https://bugs.archlinux.org/task/34641
Kunt u mij de relatie met grub uitleggen? Ik begrijp het verschil niet. of als je de concepten van efi / uefi met betrekking tot grub uitlegt, de bootloader
Precies het idee van de inzending is om het team te starten zonder door Grub te gaan. Dat wil zeggen dat dezelfde EFI (dat wil zeggen, de huidige vervanging van het BIOS) verantwoordelijk is voor het laden van de kernel en de opstartimage.
Wat het BIOS deed, was het eerste deel van de eerste harde schijf lezen, waar meestal Grub is geïnstalleerd, die verantwoordelijk is voor het laden van de kernel en de afbeelding. EFI laat kernels zichzelf laden (en maakt daardoor geavanceerde beveiligingsopties mogelijk, zoals de geliefde / gehate SecureBoot).
Praktisch gezien heeft het voor mij geen voordeel om deze methode te gebruiken om de pc op te starten.
groeten
Eén vraag:
Ik wil een nieuwe (of niet zo nieuwe) computer kopen om er GNU / Linux op te installeren. Als het wordt geleverd met Window $ 8, heb ik dan een probleem met Secure Boot?
Kan. Het probleem zal zijn dat, afhankelijk van de computer, als het W8 heeft, het wordt geleverd met UEFI geactiveerd en u het moet uitschakelen om te installeren volgens welke distributies. In de mijne geactiveerd kon ik ubuntu installeren als ik het me goed herinner, maar toen ik manjaro installeerde, werkte het niet en moest ik het deactiveren om het correct te kunnen installeren. (Eigenlijk denk ik nu in archlinux dat het zonder veel moeite kan worden geïnstalleerd, en ik denk dat grub2 het ondersteunt, maar ik veronderstel dat toen ik het systeem lang geleden installeerde het nog steeds niet helemaal gepolijst was).
Schakel UEFI en Secure Boot uit en start vervolgens de cd op wanneer u installeert voordat u de Win8- en UEFI-partities verwijdert.
Bijna alle EFI's staan toe dat besturingssystemen worden geladen in "Legacy" -modus, dat wil zeggen klassiek. Als u EFI op deze manier configureert, heeft u geen problemen.
Er is iets dat ik niet begrijp. Stel dat ik een nieuwe computer heb met Windows en UEFI. Waar voer ik deze stappen uit? In Arch-installatie of vanaf een LiveCD?
Toen ik het deed, was het vanaf de Live-cd en installeerde ik een systeem vanaf het begin, ik heb het nooit geprobeerd vanaf een al geïnstalleerd systeem. Ik stel me voor dat het ook mogelijk moet zijn als het systeem eenmaal is geïnstalleerd door de bootloader, grub of gummiboot te verwijderen om de meest voorkomende te noemen, en vervolgens de bootloader-items te verwijderen om de instructies vanaf het begin te volgen, hoe durf je dat te ervaren? . Als het niet om de verdomd absorberende baan die ik heb, ik het al deed, heb je me een doorn in het oog gegeven.
Wat als ik denk dat je het niet kunt, is met deze methode een dual-boot afhandelen.
In mijn geval heb ik een MSI B85M-E45-moederbord en hoewel het voor mij werkte, heeft het de firmware zodanig beschadigd dat ik de BIOS-instellingen niet meer kan invoeren; Ik heb een BIOS-reset uitgevoerd vanaf de jumpers op het moederbord en het probleem blijft bestaan. Ik zal proberen de firmware opnieuw te flashen. Dan zal ik je vertellen of ik het BIOS kan herstellen
Ik beschouw het in ieder geval als een proces dat het niet waard is om te proberen vanwege het risicovolle in ruil voor een paar voordelen
Gelukkig kon ik de firmware flashen, hoewel ik hierdoor niet in de BIOS-configuratie kon komen, kon ik nog steeds opstarten vanaf de harde schijf en vervolgens een opstartbare DOS-pendrive maken met het programma om het BIOS en het firmwarebestand opnieuw te flashen.
Ik had geluk, en een keer gebeurde het dat de firmware van een ACER-laptop met UEFI beschadigd was toen ik openSUSE installeerde toen UEFI-compatibele distributies begonnen te verschijnen.
Pff minder slecht, veel geluk deze keer !!!!