Din ceea ce ați citit deja în titlul postului, vă voi explica cum să porniți ArchLinux (nici o idee dacă funcționează pe alte distribuții) fără niciun fel de bootloader pe computerele EFI sau UEFI.
Primul pas
Instalați efibootmgr (dacă nu îl aveți deja instalat)
# pacman -S efibootmgr
Pasul al doilea
Montați efivarfs (dacă nu este deja montat)
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars
Al treilea pas
Adăugați distribuția la „Ordinul de încărcare” al computerului
# efibootmgr -c -L "Arch Linux" -l /vmlinuz-linux -u "root=/dev/sdaX initrd=/initramfs-linux.img"
în cazul meu am făcut-o așa
# efibootmgr -c -L "Arch Linux" -l /vmlinuz-linux -u "root=UUID=d5e93b09-02a8-4597-b059-3f87a8221825 initrd=/initramfs-linux.img quiet loglevel=0"
Ultimul pas
Vezi dacă a funcționat
# efibootmgr -v
Ștergeți distro-ul de bootorder
Dacă dintr-un anumit motiv nu a funcționat pentru dvs. sau pur și simplu nu vă place ideea de a nu utiliza un bootloader, puteți face următoarele:
Primul pas
Vedeți care este numărul care corespunde distribuției dvs. în bootorder
# efibootmgr -v
Ar trebui să vedeți așa ceva:
BootCurrent: 0000 Timeout: 0 secunde BootOrder: 0000,3000,2001,2002,2003 Boot0000 * Arch Linux HD (1,800,100000, bf49dd02-7af7-42bb-ac5d-967ea840e3f8) Fișier (\ 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 * Unitate USB (UEFI) RC Boot2002 * Unitate internă CD / DVD ROM (UEFI) RC Boot3000 * Hard disk intern sau disc Solid State RC Boot3001 * Hard disk intern sau Solid State Disk RC Boot3002 * Hard disk intern sau Solid State Disc RC
Vor vedea că marchează Boot0000 *, dar în acest caz ne interesează doar numărul 0000
Pasul al doilea
Ștergeți distro-ul de bootorder
# efibootmgr -b 0000 -B
Fuente: Arch Linux Wiki
ANUNȚ IMPORTANT
În al treilea pas al acestei intrări, comanda pe care o folosesc NU FUNCȚIONEAZĂ.
Încerc să găsesc soluția, o voi posta când o voi găsi
Aici linia care funcționează
efibootmgr -c -L "Arch Linux" -l / vmlinuz-linux -u "root = UUID = d5e93b09-02a8-4597-b059-3f87a8221825 initrd = / initramfs-linux.img quiet loglevel = 0"
Întreb pe oricine poate edita intrarea, vă rugăm să faceți acest lucru
Gata, corectată nu? 🙂
Mulțumesc
Salut. Am făcut asta deja cu ceva timp în urmă (la fel și în Arch Linux) și vă pot spune că cel puțin computerul meu nu a suferit niciun fel de daune, laptopul meu este un Lenovo G480. Dacă s-a întâmplat, atunci când kernel-ul a fost actualizat, acesta nu mai putea reîncărca sistemul și din nou a trebuit să fac toată procedura descrisă aici; După ce am făcut experimente, am încărcat sistemul (clarific că a fost vina mea, nu a sistemului), așa că a trebuit să reinstalez și nu știu din ce motiv nu l-am mai putut lăsa fără bootloader. Din moment ce nu am avut timp să mă distrez cu puzzle-uri și ghicitori de sfinx grecesc, am instalat grub și nu am mai încercat niciodată.
Ei bine, folosesc această metodă pe laptopul meu (un HP pavilion n029-la), am actualizat nucleul și nu am avut probleme. Dar, în cazul în care mi se întâmplă așa ceva, port întotdeauna un arhiv livecd în servieta cu care o port.
Am citit și da, este adevărat că, după o actualizare a nucleului, comanda (efibootmgr) nu este capabilă să creeze o intrare (este capabilă doar să o șterge) în unele cazuri izolate. https://bugs.archlinux.org/task/34641
Îmi poți explica relația cu grub? Nu înțeleg diferența. sau dacă explicați conceptele de efi / uefi cu privire la grub, bootloader-ul
Tocmai ideea intrării este de a începe echipa fără a trece prin Grub. Adică, același EFI (adică înlocuirea curentă a BIOS-ului) este însărcinat cu încărcarea nucleului și a imaginii de boot.
Ceea ce a făcut BIOS-ul a fost să citească prima parte a primului hard disk, unde este instalat de obicei Grub, care este responsabil pentru încărcarea nucleului și a imaginii. EFI permite nucleelor să se încarce singur (și astfel permite opțiuni avansate de securitate, cum ar fi SecureBoot iubit / urât).
Din punct de vedere practic, nu are niciun avantaj pentru mine să folosesc această metodă pentru a porni computerul.
În ceea ce priveşte
O intrebare:
Vreau să cumpăr un computer nou (sau nu atât de nou) doar pentru a instala GNU / Linux. În cazul în care vine cu Windows $ 8, voi avea o problemă cu Secure Boot?
Poate sa. Problema va fi că, în funcție de computer, dacă are W8, va veni cu UEFI activat și va trebui să îl dezactivați pentru a instala în funcție de ce distribuții. În a mea activată aș putea instala ubuntu dacă îmi amintesc corect, dar când am instalat manjaro nu a funcționat și a trebuit să-l dezactivez pentru a-l putea instala corect. (De fapt, acum în archlinux cred că poate fi instalat fără mari dificultăți și cred că grub2 îl suportă, dar presupun că atunci când am instalat sistemul cu mult timp în urmă nu era încă complet lustruit).
Dezactivați UEFI și Secure Boot, apoi porniți CD-ul, când instalați înainte de a șterge partițiile Win8 și UEFI.
Aproape toate EFI-urile permit încărcarea sistemelor de operare în modul „Legacy”, adică clasic. Dacă configurați EFI în acest fel, nu veți avea probleme.
Există ceva ce nu înțeleg. Să presupunem că am un computer nou cu Windows și UEFI. Unde pot efectua acești pași? În instalarea Arch sau de pe un LiveCD?
Când am făcut-o, a fost de pe Live CD-ul instalând un sistem de la zero, nu l-am încercat niciodată dintr-un sistem deja instalat. Îmi imaginez că odată ce sistemul este instalat, trebuie să fie posibil și prin eliminarea bootloader-ului, a grub-ului sau a gummiboot-ului pentru a menționa cele mai frecvente și apoi ștergerea intrărilor bootloaderului pentru a urma instrucțiunile de la început a trăi?. Dacă n-ar fi afurisita de absorbantă treabă pe care o am, deja o făceam, mi-ai dat un spin.
Ce se întâmplă dacă nu cred că poți este să gestionezi un boot dual cu această metodă.
În cazul meu, am o placă de bază MSI B85M-E45 și, deși a funcționat pentru mine, a corupt firmware-ul în așa fel încât să nu mai pot intra în setările BIOS-ului; Am făcut o resetare BIOS de la jumperii de pe placa de bază și problema persistă. Voi încerca să blochez din nou firmware-ul. Apoi vă voi spune dacă aș putea recupera BIOS-ul
În orice caz, îl consider un proces care nu merită încercat din cauza riscantului în schimbul câtorva beneficii
Din fericire am reușit să flashez firmware-ul, deși nu mi-a permis să intru în configurația BIOS-ului, totuși puteam porni de pe hard disk și apoi să creez un pendrive DOS bootabil cu programul pentru a bloca din nou BIOS-ul și fișierul firmware.
Am fugit cu noroc și, odată ce m-am întâmplat, firmware-ul unui laptop ACER cu UEFI a fost deteriorat când am instalat openSUSE când începeau să apară distribuții compatibile UEFI.
Phew mai puțin rău, noroc de data asta !!!!