#3 Szerintem a fórumtárs a Windows gyors rendszerindítás funkciójára célzott, azt ne a BIOS-ban keresd, hanem a Winben.

#1 Fast boot-ot nem találtam meg a BIOS-ban.

 

https://www.reddit.com/r/linuxmint/comments/1el5rou/cant_install_mint_mm...

„A fő gépem egy MSI GF76 Katana laptop.

Jelenleg OpenSUSE Tumbleweedet használok, amit fél évvel ezelőtt minden probléma nélkül telepítettem, a disztróhoppingos időszakom részeként.

Szeretnék visszatérni a Minthez, az első disztrómhoz.

Készítettem egy Mint 22-es live USB-t Balena Etcherrel. (A pendrive rendben van, egy másik laptopon kipróbáltam a Mint telepítést, ott minden működött.)

A telepítés nem indul el. A következő hibát kapom:

Failed to open \EFI\BOOT\mmx64.efi - Not Found
Failed to load image \EFI\BOOT\mmx64.efi: Not Found
Failed to start MokManager: Not Found
Something has gone seriously wrong: import_mok_state() failed : Not Found

A Secure Boot ki van kapcsolva (megpróbáltam bekapcsolva is indítani a telepítést, ki- és bekapcsolgatni is, mindhiába).

Könnyen találtam rá megoldást: egyszerűen csak át kell másolni a grubx64.efi fájlt, majd átnevezni mmx64.efi-re.

És itt a probléma: nem tudok fájlokat írni arra az USB-re, amin a Mint telepítője van. A rendszer megtagad minden próbálkozást, mert nincs jogosultságom rá. A grubx64.efi-t sem tudom átnevezni ugyanezen okból.

A mmx64.efi hibára adott megoldás amúgy működne, és könnyen megtalálható a neten, mert Windows alatt nincs jogosultsági gond a Rufus miatt — a Rufus ugyanis nem teszi írásvédetté a pendrive-ot. A Balena Etcher igen. És ha jól tudom, nincs normális alternatíva Etcherre Linuxon. Rufus pedig biztosan nincs.

Teljesen meg vagyok lőve, nem tudom mit tegyek, nincs elég tapasztalatom ahhoz, hogy kezelnem kelljen az írásvédett live USB-k jogosultságait. Teljesen zsákutcában vagyok.

FRISSÍTÉS: Nem találtam megoldást a problémára. Telepítettem a Mint 21.2-t (a 21.3 ugyanazt a hibát adta), frissítettem 21.3-ra, majd 22-re.”

Át tudod nevezni a Rufusszal készített pedrive-on az /EFI/boot/ grubx64.efi fájlt mmx64.efi-re? Vagy esetleg kipróbálnád a Mint 21.2-t, hátha?

#16 Szuper! Örülök! Egy lépéssel akkor már biztos előrébb vagy. Élesben még nem találkoztam soha ezzel a hibával, kíváncsi vagyok, hogy a telepített rendszer indul-e majd gond nélkül... Remélem igen!

#15 Köszönöm!! Ez viszont megoldotta az én problémámat. Ugyanis én Windows alatt Rufus-szal készítettem a pendrive-t, így át tudtam nevezni a fájlt. Telepít!!

Egyelőre nincs visszajelzés, de feltételezve, hogy probléma esetén a kérdező jelentkezett volna, valószínűsíthetjük, hogy a telepített rendszer már gond nélkül bootol, vagyis „csak” a telepítő bootolásával van ez a gond. Ebben az esetben a Linuxnak azt a tulajdonságát, hogy nem érzékeny a hardverkörnyezet változására is kiaknázhatjuk és így is eljuttathatjuk egy telepített rendszert erre a gépre.

Ha külön lemezt szánunk a Linuxnak, akkor
1. A célgép bootolási beállításait (UEFI vagy CSM/legacy) figyelembe véve egy másik gépen is elvégezhetjük erre a lemezre az általunk kiválasztott Linux rendszer telepítését,
2. Majd a célgépbe beszerelve (vagy ahhoz más módon csatlakoztatva) ezt a lemezt is viszonylag könnyedén elérhetjük a kívánt végeredményt.

Amennyiben a Windowszal azonos lemezre kívánunk dualboot megoldást elérni (nem ajánlom), az már némileg macerásabb, de szintén megoldható ennek a tulajdonságnak a kihasználásával.
1. Először is egy másik gépen a (a célgép bootolási beállításainak megfelelően) valamilyen olyan lemezre kell telepítenünk egy Linux rendszert, amelyet tudunk majd csatlakoztatni ehhez a célgéphez.
2. A Windowsban a gyors rendszerindítás/hibernálás és esetleg a BIOS-ban a Secure Boot kikapcsolása alap. Szintén a Windows alól érdemes előkészítenünk a megfelelő mennyiségű szabad helyet a Linux rendszer számára.
3. Bebootolunk a külső lemezre telepített Linux alól felmásoljuk ezt a rendszert a szabad helyre.
(Ez többféle módszerrel is megtehetjük, választásunktól függően az is lehet, hogy a kiindulási rendszerről készített rendszermentést másoljuk, de előtte még a szükséges partíciókat is a külső lemezről futó rendszer alól alakítjuk ki...)
4. Ha az általunk választott rendszermásolási metódus ezt nem foglalta magába, akkor kézzel telepítjük a belső lemezre került rendszer számára a rendszerbetöltőt.

#20
Nagyon köszönöm az értékes visszajelzést!
Használd egészséggel, leld benne sok örömöd!
(Régebben talán volt itt is egy szokás, hogy egy megoldott téma címébe beleszerkesztették a [Megoldva] címkét, ezzel segítve a későbbi tájékozódást. Ezt esetleg te vagy egy emelt joggal rendelkező oldalfenntartó tudja megtenni.
Ebben az esetben így nézne ki a cím: „[Megoldva] Linux telepítése Windows mellé”.)

#19 Tökéletesen működik a Linux Mint!

#22 A hardver nem nálam van, tehát én tesztelni más módon kiírt ISO-val nem tudom, de a Redit találaton a közelben nem volt Rufus. Ott a kérdezőnek az volt a problémája, hogy a gépe ugyanúgy hiányolta ezt az /EFI/boot/mmx64.efi fájlt, holott a telepítőt Balena Etcher-rel írta ki... Ez ellentmondani látszik az elméletednek.
Ha esetleg a probléma hardvertől (BIOS-tól) függ, és ráadásul szerencsére csak ritkán jelentkezik, akkor persze, hogy másik gépen nem fogod tapasztalni ugyanazzal az ISO-val és azt más (vagy akár ugyanolyan) módon kiírva.
Egy ilyen tapasztalásból én még korainak gondolom levonni azt a következtetést, hogy ez csakis a Rufus hülyesége lehet.
Ha nálam volna a hardver, természetesen csinálnék tesztet dd-vel; USB Image Writer-rel; Disks-szel; Ventoy-jal és Balena Etcher-rel kiírt telepítővel is...

Ez egy Rufus kaland volt. Annak a problémája, az kavarodott meg. Amúgy nincs egy hete, hogy Mint 22.2-t telepítettem dualboot módban (Ventoy-al), és semmi gond nem volt. Az mmx64.efi fájlt sem a Mint, sem a Windows nem használja, az csakis a Rufus hülyesége lehet.

Ti. A Rufus nem ISO-t ír, hanem saját bootloaderéhez igazítja a kicsomagolt ISO fájljait.