Abból, amit már olvashattál a bejegyzés címében, elmagyarázom, hogyan indítsuk el az ArchLinux programot (fogalmam sincs, hogy működik-e más disztribúciókon), mindenféle boot betöltő nélkül az EFI vagy az UEFI számítógépeken.
Első lépés
Telepítse az efibootmgr programot (ha még nincs telepítve)
# pacman -S efibootmgr
Második lépés
Mount efivarfs (ha még nincs felszerelve)
# mount -t efivarfs efivarfs /sys/firmware/efi/efivars
Harmadik lépés
Adja hozzá a disztribúciót a számítógép "Rendszerindítási sorrendjéhez"
# efibootmgr -c -L "Arch Linux" -l /vmlinuz-linux -u "root=/dev/sdaX initrd=/initramfs-linux.img"
az én esetemben így tettem
# efibootmgr -c -L "Arch Linux" -l /vmlinuz-linux -u "root=UUID=d5e93b09-02a8-4597-b059-3f87a8221825 initrd=/initramfs-linux.img quiet loglevel=0"
Utolsó lépés
Nézze meg, hogy működött-e
# efibootmgr -v
Törölje a bootorder disztrót
Ha valamilyen oknál fogva nem működött az Ön számára, vagy csak nem tetszik az ötlet, hogy ne használja a rendszerbetöltőt, akkor a következőket teheti:
Első lépés
Nézze meg, melyik az a szám, amely megfelel a disztribúciónak a rendszerindítóban
# efibootmgr -v
Valami ilyesmit kellene látnia:
BootCurrent: 0000 Időtúllépés: 0 másodperc BootOrder: 0000,3000,2001,2002,2003 Boot0000 * Arch Linux HD (1,800,100000 49 02 7, bf7dd42-5af967-840bb-ac3d-8ea5e9.3f0.9) Fájl (\ vmlinuz-linux) gyökér = .UUID = .d.0.2.e.8.b.4.5.9.7 .-. 0.5.9.a.3 .-. 8.7 .-. B.8.2.2.1.8.2.5 .-. 0.f.2001.a.2002. .initrd =. /. initramfs-.linux..img .quiet .loglevel = .3000. Boot3001 * USB meghajtó (UEFI) RC Boot3002 * Belső CD / DVD ROM meghajtó (UEFI) RC BootXNUMX * Belső merevlemez vagy szilárdtestlemez RC BootXNUMX * Belső merevlemez vagy Solid State Disk RC BootXNUMX * Belső merevlemez vagy Solid State Disk RC
Látni fogják, hogy ez a Boot0000 * -t jelöli, de ebben az esetben csak a 0000 szám érdekel
Második lépés
Törölje a bootorder disztrót
# efibootmgr -b 0000 -B
forrás: Arch Linux Wiki
FONTOS HIRDETÉS
A bejegyzés harmadik lépésében az általam használt parancs NEM MŰKÖDIK.
Megpróbálom megtalálni a megoldást, ha megtalálom, felteszem
Itt a működő vonal
efibootmgr -c -L "Arch Linux" -l / vmlinuz-linux -u "root = UUID = d5e93b09-02a8-4597-b059-3f87a8221825 initrd = / initramfs-linux.img csendes loglevel = 0"
Kérek mindenkit, aki szerkesztheti a bejegyzést, kérem, tegye meg
Kész, kijavított igaz? 🙂
Köszönöm
Szia. Ezt már régebben megtettem (ugyanez az Arch Linux-ban), és elmondhatom, hogy legalább a számítógépem nem szenvedett sérülést, a laptopom egy Lenovo G480. Mi történt, ha megtörtént az, hogy a kernel frissítésekor már nem tudta újratölteni a rendszert, és megint el kellett végeznem az itt leírt összes eljárást; Kísérletek elvégzése után betöltöttem a rendszert (tisztázom, hogy az én hibám volt, nem a rendszeré), ezért újratelepítenem kellett, és nem tudom, miért nem hagyhatom tovább indítótöltő nélkül. Mivel akkoriban nem volt időm görög szfinx-rejtvényekkel és találós kérdésekkel szórakoztatni magam, telepítettem a grub-ot, és soha többé nem próbáltam.
Nos, ezt a módszert használom a laptopomon (egy HP pavilion n029-la), frissítettem a kernelt, és nem voltak problémáim. De ha velem valami ilyesmi történik, akkor mindig hordok egy boltíves livecd-t az aktatáskában, amellyel hordom.
Olvastam, és igen, igaz, hogy a kernel frissítése után az (efibootmgr) parancs egyes esetekben nem képes bejegyzést létrehozni (csak törölni képes). https://bugs.archlinux.org/task/34641
El tudnád magyarázni nekem a grubhoz fűződő kapcsolatot? Nem értem a különbséget. vagy ha elmagyarázza az efi / uefi fogalmát a grub, a bootloader vonatkozásában
Pontosan a nevezés ötlete az, hogy úgy indítsuk a csapatot, hogy ne menjünk át Grubon. Vagyis ugyanaz a EFI (vagyis a BIOS jelenlegi cseréje) felel a kernel és az indítókép betöltéséért.
Amit a BIOS csinált, az az első merevlemez első részét olvasta el, ahol általában a Grub van telepítve, amely a kernel és a kép betöltéséért felelős. Az EFI lehetővé teszi a kernek számára, hogy betöltse önmagát (és ezáltal fejlett biztonsági opciókat, például a szeretett / gyűlölt SecureBoot-ot is).
Gyakorlati szempontból nincs előnyöm, ha ezt a módszert használom a PC indításához.
Üdvözlet
Kérdés:
Új (vagy nem annyira új) számítógépet szeretnék vásárolni, csak a GNU / Linux telepítésére. Abban az esetben, ha Window 8 dollárral érkezik, problémám lesz a biztonságos indítással?
Tud. A probléma az lesz, hogy a számítógéptől függően, ha van W8, akkor az UEFI aktiválva lesz, és deaktiválnia kell, hogy milyen disztribúciók szerint telepítse. Az aktivált enyémben tudtam telepíteni az ubuntut, ha jól emlékszem, de a manjaro telepítésekor nem működött, és deaktiválnom kellett, hogy helyesen telepíthessem. (Valójában most az archlinuxban azt hiszem, hogy különösebb nehézség nélkül telepíthető, és azt hiszem, a grub2 támogatja, de feltételezem, hogy amikor régen telepítettem a rendszert, még mindig nem volt teljesen csiszolva).
A Win8 és UEFI partíció törlése előtt telepítéskor tiltsa le az UEFI és a Biztonságos indítást, majd indítsa el a CD-t.
Szinte az összes EFI lehetővé teszi az operációs rendszerek "Legacy", vagyis klasszikus módban történő betöltését. Ha így konfigurálja az EFI-t, akkor nem lesz semmi problémája.
Van valami, amit nem értek. Tegyük fel, hogy van egy új számítógépem, amelyen Windows és UEFI van. Hol végezhetem ezeket a lépéseket? Arch telepítésben vagy LiveCD-ről?
Amikor megcsináltam, a Live CD-ről volt szó, amely a semmiből telepített egy rendszert, soha nem próbáltam meg már telepített rendszerről. Úgy képzelem, hogy a rendszer telepítése után lehetővé kell tenni a rendszerbetöltő, a grub vagy a gummiboot eltávolításával, hogy megemlítsük a leggyakoribbakat, majd törölve a rendszerbetöltő bejegyzéseit, hogy az elejétől kezdve kövesse az utasításokat. . Ha nem az a rohadt nedvszívó munkám lett volna, akkor már csináltam, adtál nekem egy tüskét.
Mi van, ha nem hiszem, hogy tudsz, az a kettős rendszerindítás kezelése ezzel a módszerrel.
Az én esetemben van egy MSI B85M-E45 alaplapom, és bár nekem bevált, mégis megrongálta a firmware-t, így már nem tudok belépni a BIOS-beállításokba; Az alaplapon lévő jumperekről elvégeztem a BIOS visszaállítását, és a probléma továbbra is fennáll. Megpróbálom újra felvillantani a firmware-t. Akkor megmondom, hogy helyre tudnám-e állítani a BIOS-t
Mindenesetre olyan folyamatnak tartom, amelyet nem érdemes kipróbálni a kockázatos miatt, néhány előnyért cserébe
Szerencsére képes voltam villogni a firmware-re, bár ez nem engedte meg, hogy belépjek a BIOS-konfigurációba, mégis indíthattam a merevlemezről, majd létrehozhattam egy indítható DOS-pendrive-ot a programmal a BIOS és a firmware fájl újbóli felvillantására.
Szerencsével futottam, és egyszer megtörtént, hogy egy UEFI-vel rendelkező ACER laptop firmware-je megsérült, amikor az openSUSE-t telepítettem, amikor az UEFI-kompatibilis disztribúciók kezdtek megjelenni.
Phew kevésbé rossz, sok sikert ezúttal !!!!