Sony VAIO z biosami Insyde H2O EFI nie uruchamia się w GRUB EFI

Kupiłem nowy laptop Sony Vaio z serii S. Używa Insyde H2O BIOS EFI, a próba instalacji Linuksa doprowadza mnie do szału.

root@kubuntu:~# parted /dev/sda print
Model: ATA Hitachi HTS72756 (scsi)
Disk /dev/sda: 640GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start  End    Size    File system  Name                          Flags
 1      1049kB  274MB  273MB  fat32        EFI system partition          hidden
 2      274MB  20.8GB  20.6GB  ntfs        Basic data partition          hidden, diag
 3      20.8GB  21.1GB  273MB  fat32        EFI system partition          boot
 4      21.1GB  21.3GB  134MB                Microsoft reserved partition  msftres
 5      21.3GB  342GB  320GB  ntfs        Basic data partition
 6      342GB  358GB  16.1GB  ext4        Basic data partition
 7      358GB  374GB  16.1GB  ntfs        Basic data partition
 8      374GB  640GB  266GB  ntfs        Basic data partition

Zaskakujące jest to, że na dysku znajdują się 2 partycje systemowe EFI. Partycja sda2 to partycja odzyskiwania o pojemności 20 GB, która ładuje system Windows z podstawowym interfejsem odzyskiwania. Jest to dostępne po naciśnięciu przycisku „ASSIST” w przeciwieństwie do normalnego przycisku zasilania. Zakładam, że partycja systemowa EFI sda1 ładuje się do tego odzyskiwania.

Sda3 ESP ma więcej rozwiniętych wpisów dla systemu Microsoft Windows, który faktycznie wchodzi w system Windows 7 (co potwierdza bcdedit.exe w systemie Windows). Ubuntu jest zainstalowany na sda6, a podczas instalacji wybrałem sda3 jako moją partycję rozruchową. Instalator poprawnie utworzył aplikację sda3 / EFI / ubuntu / grubx64.efi.

Prawdziwy problem: przez całe życie nie mogę ustawić go jako domyślnego! Próbowałem utworzyć plik sda3 / startup.nsh, który nazywał się grubx64.efi, ale to nie pomogło - po ponownym uruchomieniu system nadal uruchamia się w systemie Windows. Próbowałem użyć efibootmgr, a to pokazuje, jak to działało:

root@kubuntu:~# efibootmgr 
BootCurrent: 0000
BootOrder: 0000,0001
Boot0000* EFI USB Device
Boot0001* Windows Boot Manager
root@kubuntu:~# efibootmgr --create --gpt --disk /dev/sda --part 3 --write-signature --label "GRUB2" --loader "\\EFI\\ubuntu\\grubx64.efi" 
BootCurrent: 0000
BootOrder: 0002,0000,0001
Boot0000* EFI USB Device
Boot0001* Windows Boot Manager
Boot0002* GRUB2
root@kubuntu:~# efibootmgr
BootCurrent: 0000
BootOrder: 0002,0000,0001
Boot0000* EFI USB Device
Boot0001* Windows Boot Manager
Boot0002* GRUB2

Jednak po ponownym uruchomieniu komputera, jak się domyślałeś, komputer uruchomił się ponownie bezpośrednio w systemie Windows.

Jedyne rzeczy, o których mogę myśleć to:

1. Partycja sda1 jest w jakiś sposób używana
2. Zastąp /EFI/Boot/bootx64.efi i /EFI/Microsoft/Boot/bootmgfw.efi za pomocą grubx64.efi [ale to wydaje się naprawdę radykalne].

Czy ktoś może mi pomóc? Dzięki - każda pomoc jest mile widziana, ponieważ ten problem doprowadza mnie do szału!

W końcu udało mi się to rozwiązać. Plik EFI / Microsoft / boot / bootmgfw.efi zastąpiłem grub64.efi. Zmieniłem nazwę tego pierwszego na bootmgfw.efi.old i użyłem grub, aby dodać opcję menu, aby załadować do niego łańcuch.

Oznacza to, że oprogramowanie wbudowane jest na stałe w poszukiwaniu programu ładującego system Windows dla systemu Microsoft Windows i nie przestrzega ustawień efibootmgr ani startup.nsh. To naprawdę okropne.

Dowiedziałem się, jak działa proces rozruchu Sony EFI:

1. Zajrzyj do /EFI/Microsoft/Boot/fwbootmgr.efi; jeśli jest obecny, uruchom go.
2. Poszukaj grubx64.efi we wszystkich podkatalogach / EFI /. Jeśli jest obecny, uruchom go.
3. Uruchom /EFI/Boot/bootx64.efi
4. Wyświetl komunikat o błędzie, taki jak „Nie znaleziono systemu operacyjnego”.

W systemie Linux narzędzie efibootmgr działa, ale wyświetla wiele automatycznie generowanych bzdur, w tym ostatnio używany dysk USB.

Oto jak nauczyłem się tego wszystkiego:

1. Otworzyłem moją nową maszynę i zwinąłem partycję Windows, aby zainstalować Linuxa i Maca obok siebie.
2. Zainstalowałem Ubuntu 12.10 i instalator nadpisał fwbootmgr.efi, tworząc kopię zapasową starego programu ładującego Windows.
3. Przywróciłem stary program ładujący systemu Windows, ale nie mogłem uruchomić niczego oprócz systemu Windows.
4. Zmieniłem nazwę bootloadera Windows na coś fałszywego, a potem Grub BL przejął kontrolę.
5. Zmieniłem nazwę katalogu ubuntu na coś innego, a Grub wciąż się ładuje, mimo że zainstalowałem rEFInd.

6. Jedynym sposobem, aby uzyskać rEFInd, aby zrobić to, co chciałem, było:

7. Przenieś plik fwbootmgr.efi do jego katalogu nadrzędnego; rEFInd nadal go znajdzie, a Windows nie będzie narzekał, że zmieniłeś jego nazwę.

8. Zmień nazwę grubx64.efi na rfgrubx64.efi lub na inny rozpoznawalny element.
9. Skopiuj rEFInd z / EFI / refind do / EFI / boot, zmień nazwę /EFI/refind_x64.efi na * .bak, a na koniec zmień nazwę /Boot/refind_x64.efi na bootx64.efi. Powinieneś być teraz w stanie uruchomić Windows BL lub GRUB z rEFInd. Planuję uaktualnić moją instalację MacOS do Clover i załadować Clover również z rEFInd.

(Być może można to zrobić za pomocą Menedżera rozruchu systemu Windows, ale obsługa EFI w EeasyBCD nadal jest nieprzyjemna z mojego doświadczenia. Przez chwilę nie chcę jej dotykać.)

Po pierwsze, nie masz dwóch ESP. ESP to partycja z kodem typu partycji C12A7328-F81F-11D2-BA4B-00A0C93EC93B, która rozstaje się jako partycja z ustawioną „flagą rozruchową”. Twoje dane wyjściowe wskazują, że tylko / dev / sda3 ma ustawioną „flagę rozruchową”, więc masz tylko jeden ESP - / dev / sda3. W GPT partycje mogą mieć nazwy, a ty masz dwie partycje o nazwie „partycja systemowa EFI”, ale nazwy te są używane wyłącznie do celów identyfikacji człowieka. Tak więc, zgaduję, że ty (lub jakieś automatyczne narzędzie) stworzyłeś / dev / sda1 z zamiarem uczynienia go ESP, ale albo wystąpił błąd podczas ustawiania kodu typu partycji, albo jakieś inne narzędzie nieprawidłowo zmieniło kod typu z C12A7328-F81F-11D2-BA4B-00A0C93EC93B na coś innego.

Istnieje wiele sposobów na poprawienie tego. Najprościej jest po prostu zmienić nazwę / dev / sda1, aby uniknąć nieporozumień. Jeśli uważasz, że / dev / sda1 nie ma żadnego sensu, możesz wykonać kopię zapasową i usunąć. To usunie to z drogi i pozwoli uniknąć nieporozumień, ale oczywiście będziesz mieć 273 MB nieużywanego miejsca na dysku. Alternatywnie możesz poświęcić miejsce na inny cel, w razie potrzeby zmieniając nazwę i kod typu, aby uniknąć nieporozumień. EFI wyraźnie zezwala na wiele ESP, więc możesz zmienić kod typu (ustawiając na przykład „flagę rozruchową” używając parted) i używać obu ESP; ale może to być mylące.

Istnieje prawdopodobieństwo, że problem ten nie jest związany z niemożnością uruchomienia systemu Linux, ponieważ wygląda na to, że wszystkie odpowiednie pliki znajdują się w katalogu / dev / sda3. Przyszło mi do głowy kilka możliwych przyczyn tego problemu:

• Możliwe, że źle wpisałeś coś w poleceniu efibootmgr. Nie widzę żadnych oczywistych literówek, ale jeśli plik binarny GRUB nie znajduje się w określonym miejscu, polecenie nie będzie działać. Opcje „--gpt” i „--write-podpis” są prawie na pewno niepotrzebne i prawdopodobnie mogą powodować problemy, ale najprawdopodobniej nie są.
• Oprogramowanie układowe może zawierać błąd, który powoduje, że efekty polecenia efibootmgr są tymczasowe. Spróbuj ponownie uruchomić komputer, a następnie wpisz „sudo efibootmgr -v”, aby sprawdzić, czy utworzony wpis przetrwał ponowne uruchomienie.
• W oprogramowaniu może występować błąd, który powoduje, że zmienna kolejności uruchamiania jest ignorowana. Mam taką płytę główną; uruchamia się w kolejności, w której są tworzone wpisy rozruchu, a nie w kolejności, w jakiej są określone przez zmienną BootOrder. Aby obejść ten błąd, musisz usunąć wszystkie wpisy i ponownie je utworzyć w kolejności uruchamiania, której chcesz użyć.
• Twój plik binarny grubx64.efi może zostać uszkodzony w taki sposób, że oprogramowanie układowe nie chce go uruchomić, i przechodzi do następnego elementu w kolejności rozruchu.

Możesz spróbować dostosować polecenie efibootmgr, zlokalizować nowy plik binarny lub co innego, aby przetestować te możliwości. Jeśli wszystko inne zawiedzie, zalecamy wykonanie następujących czynności:

1. Usuń wszystkie wpisy rozruchu za pomocą efibootmgr lub oprogramowania wewnętrznego (jeśli udostępnia interfejs do wykonania tej czynności).
2. Skopiuj grubx64.efi do EFI / Boot / bootx64.efi na ESP.
3. Jeśli po ponownym uruchomieniu nadal otrzymujesz system Windows, zmień nazwę EFI / Microsoft / Boot / bootmgfw.efi na EFI / Microsoft / bootmgfw.efi.

Powinno to spowodować uruchomienie GRUB-a przy użyciu domyślnej nazwy modułu ładującego (EFI / Boot / bootx64.efi). Jednym z problemów jest to, że GRUB może nie mieć działającego wpisu dla systemu Windows. Prawdopodobnie możesz utworzyć go ręcznie; taki wpis powinien działać:

menuentry "Windows 7" {
    set root='(hd0,gpt3)'
    chainloader /EFI/Microsoft/bootmgfw.efi
}

Alternatywnie, możesz zainstalować rEFIt lub rEFInd jako EFI / Boot / bootx64.efi. Należy pamiętać, że pliki binarne rEFIt dostępne z jego strony nie będą działać na komputerach z systemem UEFI; musisz użyć wersji z repozytoriów Ubuntu. rEFInd to rozwidlenie rEFIt z licznymi poprawkami i aktualizacjami błędów, w tym lepszą obsługą UEFI. (REFI Wydaje się, że został porzucony około dwa lata temu.) Dlatego zalecam raczej użycie rEFInd zamiast rEFIt - ale jestem jego opiekunem, więc nie jestem niezależnym obserwatorem tego wyniku. Niestety, AFAIK rEFInd nie jest (jeszcze) zawarty w repozytoriach Ubuntu, więc będziesz musiał go pobrać i zainstalować ręcznie.

Ta sama pozycja początkowa w nowej serii Sony Vaio e. Dziękuję Rod za twoją odpowiedź.

Na wypadek, gdyby ktoś potrzebował instrukcji, oto, co dla mnie zadziałało:

Zainstalowano Ubuntu 12.04 z USB wraz z Win7.

mocowanie / dev / sda3 z sesji na żywo

• skopiuj EFI / ubuntu / grubx64.efi do EFI / Boot /
• zmień nazwę EFI / Boot / bootx64.efi na bootx64.efi.old
• zmień nazwę EFI / Boot / grubx64.efi na bootx64.efi

teraz uruchomił się bezpośrednio w grub2, ale bez wpisu win7

po załadowaniu ubuntu edytowałem

/etc/grub.d/40_custom

dodawanie

menuentry "Windows 7" {
    set root='(hd0,gpt3)'
    chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}

oraz po

sudo update-grub

wszystko dziala

Proponuję dwie różne alternatywy:

1. Nie nadpisuj Windows mbr, ale używaj go do uruchamiania grub

2. zmień ustawienia bios ( f2lub f3przy uruchomieniu) w opcjach rozruchu z UEFI na LEGACY, wtedy normalnie uruchomi ostatni zainstalowany system jak zawsze

1. Uruchom Boot-Repair z liveCD / liveUSB
2. Kliknij Recommended Repairprzycisk. (spowoduje to automatyczne zainstalowanie poprawnych parametrów dla grub-efi, w tym parametrów SecureBoot, jeśli to konieczne, i zmianę nazwy plików EFI w przypadku zablokowania oprogramowania układowego UEFI w plikach Windows). Wskaż adres URL, który pojawi się w przypadku problemów.