Aktualizacja: Poniższe pytania i odpowiedzi dotyczą również Ubuntu 16.04

Mam komputer z podwójnymi dyskami SSD i systemem Windows (7) wstępnie zainstalowanym na innym dysku. Przed instalacją używa rozruchu (U) EFI / GPT. Chcę zainstalować 64-bitowy pulpit Ubuntu 14.04 na partycji głównej RAID1 na moich dyskach SSD i nadal móc uruchamiać system Win7 podwójnie. czy to możliwe?

Ten przewodnik przy użyciu instalatora pulpitu nie działał, prawdopodobnie dlatego, że (domyślnie) zakłada rozruch MBR. Ani instalacji dystrybucji serwera , prawdopodobnie z tego samego powodu.

AKTUALIZACJA: Sprawdziłem, że poniższy opis działa również dla Ubuntu 16.04. Inni użytkownicy zgłosili pracę nad 17.10 i 18.04.1.

UWAGA: To HOWTO nie da ci LVM. Jeśli chcesz także LVM, spróbuj zainstalować Ubuntu 18.04 na komputerze z RAID 1 i LVM na komputerze z UEFI BIOS .

Po wielu dniach prób mam teraz działający system! W skrócie, rozwiązanie składało się z następujących kroków:

1. Uruchom przy użyciu Ubuntu Live CD / USB.
2. Partycjonuje dyski SSD zgodnie z wymaganiami.
3. Zainstaluj brakujące pakiety (mdadm i grub-efi).
4. Utwórz partycje RAID.
5. Uruchom instalator Ubiquity (ale nie uruchamiaj się w nowym systemie).
6. Załataj zainstalowany system (initramfs), aby umożliwić rozruch z rootowanego RAID.
7. Wypełnij partycję EFI pierwszego dysku SSD za pomocą GRUB i zainstaluj ją w łańcuchu rozruchowym EFI.
8. Sklonować partycję EFI na drugą SSD i zainstalować go na łańcuchu rozruchowej.
9. Gotowy! Twój system będzie teraz miał nadmiarowość RAID 1. Zauważ, że nie trzeba nic specjalnego robić np. Po aktualizacji jądra, ponieważ partycje UEFI pozostają nietknięte.

Kluczowym składnikiem kroku 6 rozwiązania było opóźnienie w sekwencji rozruchowej, które w przeciwnym razie rzuciłoby mnie wprost na monit GRUB (bez klawiatury!), Jeśli brakuje któregoś z dysków SSD.

Szczegółowy HOWTO

1. Uruchom

Uruchom za pomocą EFI z pamięci USB. Dokładnie jak różni się w zależności od systemu. Wybierz Wypróbuj ubuntu bez instalacji .

Uruchom emulator terminala, np. xtermAby uruchomić poniższe polecenia.

1.1 Zaloguj się z innego komputera

Podczas wypróbowywania tego często często łatwiej było mi zalogować się z innego, w pełni skonfigurowanego komputera. To uproszczone wycinanie i wklejanie poleceń itp. Jeśli chcesz zrobić to samo, możesz zalogować się przez ssh, wykonując następujące czynności:

Na konfigurowanym komputerze zainstaluj serwer openssh:

sudo apt-get install openssh-server

Zmień hasło. Domyślne hasło użytkownika ubuntujest puste. Prawdopodobnie możesz wybrać hasło o średniej sile. Zostanie zapomniany, gdy tylko uruchomisz ponownie komputer.

passwd

Teraz możesz zalogować się do sesji ubuntu na żywo z innego komputera. Poniższe instrukcje dotyczą systemu Linux:

ssh -l ubuntu <your-new-computer>

Jeśli pojawi się ostrzeżenie o podejrzeniu ataku człowieka w środku, musisz wyczyścić klucze ssh użyte do identyfikacji nowego komputera. Wynika to z faktu, że openssh-servergeneruje nowe klucze serwera przy każdej instalacji. Polecenie do użycia jest zwykle drukowane i powinno wyglądać

ssh-keygen -f <path-to-.ssh/known_hosts> -R <your-new-computer>

Po wykonaniu tego polecenia powinieneś być w stanie zalogować się do sesji na żywo ubuntu.

2. Dyski partycji

Wyczyść wszystkie stare partycje i bloki rozruchowe. Ostrzeżenie! Spowoduje to zniszczenie danych na dyskach!

sudo sgdisk -z /dev/sda
sudo sgdisk -z /dev/sdb

Utwórz nowe partycje na najmniejszym dysku: 100M dla ESP, 32G dla RAID SWAP, reszta dla RAID root. Jeśli Twój dysk Sda jest najmniejszy, postępuj zgodnie z sekcją 2.1, w przeciwnym razie sekcją 2.2.

2.1 Utwórz tabele partycji (/ dev / sda jest mniejszy)

Wykonaj następujące czynności:

sudo sgdisk -n 1:0:+100M -t 1:ef00 -c 1:"EFI System" /dev/sda
sudo sgdisk -n 2:0:+32G -t 2:fd00 -c 2:"Linux RAID" /dev/sda
sudo sgdisk -n 3:0:0 -t 3:fd00 -c 3:"Linux RAID" /dev/sda

Skopiuj tablicę partycji na inny dysk i ponownie wygeneruj unikalne UUID (faktycznie zregeneruje UUID dla sda).

sudo sgdisk /dev/sda -R /dev/sdb -G

2.2 Utwórz tabele partycji (/ dev / sdb jest mniejszy)

Wykonaj następujące czynności:

sudo sgdisk -n 1:0:+100M -t 1:ef00 -c 1:"EFI System" /dev/sdb
sudo sgdisk -n 2:0:+32G -t 2:fd00 -c 2:"Linux RAID" /dev/sdb
sudo sgdisk -n 3:0:0 -t 3:fd00 -c 3:"Linux RAID" /dev/sdb

Skopiuj tablicę partycji na inny dysk i ponownie wygeneruj unikalne UUID (faktycznie zregeneruje UUID dla sdb).

sudo sgdisk /dev/sdb -R /dev/sda -G

2.3 Utwórz system plików FAT32 na / dev / sda

Utwórz system plików FAT32 dla partycji EFI.

sudo mkfs.fat -F 32 /dev/sda1
mkdir /tmp/sda1
sudo mount /dev/sda1 /tmp/sda1
sudo mkdir /tmp/sda1/EFI
sudo umount /dev/sda1

3. Zainstaluj brakujące pakiety

Ubuntu Live CD jest dostarczany bez dwóch kluczowych pakietów; grub-efi i mdadm. Zainstaluj je. (Nie jestem w 100% pewien, że potrzebny jest tutaj grub-efi, ale aby zachować symetrię z nadchodzącą instalacją, również ją wprowadź).

sudo apt-get update
sudo apt-get -y install grub-efi-amd64 # (or grub-efi-amd64-signed)
sudo apt-get -y install mdadm

Może być konieczne grub-efi-amd64-signedzamiast tego, grub-efi-amd64jeśli masz włączony bezpieczny rozruch. (Zobacz komentarz Alecz.)

4. Utwórz partycje RAID

Utwórz urządzenia RAID w trybie awaryjnym. Urządzenia zostaną ukończone później. Utworzenie pełnej macierzy RAID1 czasami sprawiało mi problemy podczas ubiquityinstalacji poniżej, nie jestem pewien, dlaczego. (format montowania / odmontowania?)

sudo mdadm --create /dev/md0 --bitmap=internal --level=1 --raid-disks=2 /dev/sda2 missing
sudo mdadm --create /dev/md1 --bitmap=internal --level=1 --raid-disks=2 /dev/sda3 missing

Sprawdź status RAID.

cat /proc/mdstat

Personalities : [raid1] 
md1 : active raid1 sda3[0]
      216269952 blocks super 1.2 [2/1] [U_]
      bitmap: 0/2 pages [0KB], 65536KB chunk

md0 : active raid1 sda2[0]
      33537920 blocks super 1.2 [2/1] [U_]
      bitmap: 0/1 pages [0KB], 65536KB chunk

unused devices: <none>

Podziel urządzenia MD na partycje.

sudo sgdisk -z /dev/md0
sudo sgdisk -z /dev/md1
sudo sgdisk -N 1 -t 1:8200 -c 1:"Linux swap" /dev/md0
sudo sgdisk -N 1 -t 1:8300 -c 1:"Linux filesystem" /dev/md1

5. Uruchom instalatora

Uruchom instalator wszechobecności, z wyjątkiem modułu ładującego, który i tak się nie powiedzie . ( Uwaga : jeśli zalogowałeś się przez ssh, prawdopodobnie będziesz chciał wykonać to na swoim nowym komputerze).

sudo ubiquity -b

Wybierz Coś innego jako typ instalacji i zmień md1p1typ na ext4, sformatuj: tak i punkt podłączenia /. md0p1Partycji zostanie automatycznie wybrany wymiany.

Wypij filiżankę kawy na zakończenie instalacji.

Ważne: po zakończeniu instalacji wybierz Kontynuuj testowanie, ponieważ system nie jest jeszcze gotowy do rozruchu.

Uzupełnij urządzenia RAID

Dołącz oczekujące partycje SDB do RAID.

sudo mdadm --add /dev/md0 /dev/sdb2
sudo mdadm --add /dev/md1 /dev/sdb3

Sprawdź, czy wszystkie urządzenia RAID działają poprawnie (i opcjonalnie synchronizują).

cat /proc/mdstat

Personalities : [raid1] 
md1 : active raid1 sdb3[1] sda3[0]
      216269952 blocks super 1.2 [2/1] [U_]
      [>....................]  recovery =  0.2% (465536/216269952)  finish=17.9min speed=200000K/sec
      bitmap: 2/2 pages [8KB], 65536KB chunk

md0 : active raid1 sdb2[1] sda2[0]
      33537920 blocks super 1.2 [2/2] [UU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

unused devices: <none>

Poniższy proces może być kontynuowany podczas synchronizacji, w tym restartów.

6. Skonfiguruj zainstalowany system

Skonfiguruj, aby włączyć chroot w systemie instalacyjnym.

sudo -s
mount /dev/md1p1 /mnt
mount -o bind /dev /mnt/dev
mount -o bind /dev/pts /mnt/dev/pts
mount -o bind /sys /mnt/sys
mount -o bind /proc /mnt/proc
cat /etc/resolv.conf >> /mnt/etc/resolv.conf
chroot /mnt

Skonfiguruj i zainstaluj pakiety.

apt-get install -y grub-efi-amd64 # (or grub-efi-amd64-signed; same as in step 3)
apt-get install -y mdadm

Jeśli urządzenia MD nadal synchronizują, możesz od czasu do czasu wyświetlać ostrzeżenia:

/usr/sbin/grub-probe: warning: Couldn't find physical volume `(null)'. Some modules may be missing from core image..

Jest to normalne i można je zignorować (patrz odpowiedź na dole tego pytania ).

nano /etc/grub.d/10_linux
# change quick_boot and quiet_boot to 0

Wyłączenie quick_bootpozwoli uniknąć zapisywania Diskfilter nie są obsługiwane błędy. Wyłączenie quiet_bootodbywa się wyłącznie według osobistych preferencji.

Zmodyfikuj /etc/mdadm/mdadm.conf, aby usunąć wszelkie odniesienia do etykiet, tj. Zmień

ARRAY /dev/md/0 metadata=1.2 name=ubuntu:0 UUID=f0e36215:7232c9e1:2800002e:e80a5599
ARRAY /dev/md/1 metadata=1.2 name=ubuntu:1 UUID=4b42f85c:46b93d8e:f7ed9920:42ea4623

do

ARRAY /dev/md/0 UUID=f0e36215:7232c9e1:2800002e:e80a5599
ARRAY /dev/md/1 UUID=4b42f85c:46b93d8e:f7ed9920:42ea4623

Ten krok może być niepotrzebny, ale widziałem, jak niektóre strony sugerują, że schematy nazewnictwa mogą być niestabilne (name = ubuntu: 0/1), co może powstrzymać idealnie prawidłowe urządzenie RAID przed zebraniem.

Zmodyfikuj linie, /etc/default/grubaby czytać

#GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""

Znowu ten krok może być niepotrzebny, ale wolę uruchomić z otwartymi oczami ...

6.1 Dodaj skrypt uśpienia

(Sugerowano przez społeczność, że ten krok może być zbędne i można zastąpić stosując GRUB_CMDLINE_LINUX="rootdelay=30"w /etc/default/grub. Dla powodów wyjaśnionych w dolnej części tego dokumentu, proponuję trzymać się scenariusza snu, mimo że jest brzydsza niż przy użyciu rootdelay. Tak więc, kontynuujemy nasz regularny program ... )

Utwórz skrypt, który będzie czekać na ustabilizowanie się urządzeń RAID. Bez tego opóźnienia montowanie roota może się nie powieść z powodu niedokończenia montażu RAID . Odkryłem to na własnej skórze - problem nie pojawił się, dopóki nie odłączyłem jednego z dysków SSD, aby zasymulować awarię dysku! Czas może wymagać dostosowania w zależności od dostępnego sprzętu, np. Wolnych zewnętrznych dysków USB itp.

Wpisz następujący kod w /usr/share/initramfs-tools/scripts/local-premount/sleepAwhile:

#!/bin/sh
echo
echo "sleeping for 30 seconds while udevd and mdadm settle down"
sleep 5
echo "sleeping for 25 seconds while udevd and mdadm settle down"
sleep 5
echo "sleeping for 20 seconds while udevd and mdadm settle down"
sleep 5
echo "sleeping for 15 seconds while udevd and mdadm settle down"
sleep 5
echo "sleeping for 10 seconds while udevd and mdadm settle down"
sleep 5
echo "sleeping for 5 seconds while udevd and mdadm settle down"
sleep 5
echo "done sleeping"

Ustaw skrypt jako wykonywalny i zainstaluj go.

chmod a+x /usr/share/initramfs-tools/scripts/local-premount/sleepAwhile
update-grub
update-initramfs -u

7. Włącz rozruch z pierwszego dysku SSD

Teraz system jest prawie gotowy, należy zainstalować tylko parametry rozruchowe UEFI.

mount /dev/sda1 /boot/efi
grub-install --boot-directory=/boot --bootloader-id=Ubuntu --target=x86_64-efi --efi-directory=/boot/efi --recheck
update-grub
umount /dev/sda1

Spowoduje to zainstalowanie modułu ładującego w /boot/efi/EFI/Ubuntu(aka EFI/Ubuntuon /dev/sda1) i zainstalowanie go najpierw w łańcuchu rozruchowym UEFI na komputerze.

8. Włącz rozruch z drugiego dysku SSD

Prawie skończyliśmy. W tym momencie powinniśmy móc ponownie uruchomić sdadysk. Ponadto mdadmpowinien być w stanie poradzić sobie z awarią dysku sdalub sdbdysku. Jednak EFI nie jest RAIDed, więc musimy go sklonować .

dd if=/dev/sda1 of=/dev/sdb1

Oprócz zainstalowania modułu ładującego na drugim dysku, spowoduje to, że identyfikator UUID systemu plików FAT32 na sdb1partycji (według zgłoszenia blkid) będzie zgodny z sda1i /etc/fstab. (Pamiętaj jednak, że identyfikatory UUID dla partycji /dev/sda1i /dev/sdb1będą się nadal różnić - porównaj ls -la /dev/disk/by-partuuid | grep sd[ab]1z blkid /dev/sd[ab]1po instalacji, aby sprawdzić sam.)

Na koniec musimy wstawić sdb1partycję do kolejności rozruchu. (Uwaga: Ten krok może być niepotrzebny, w zależności od systemu BIOS. Otrzymałem raporty, że niektóre BIOS-y automatycznie generują listę ważnych ESP.)

efibootmgr -c -g -d /dev/sdb -p 1 -L "Ubuntu #2" -l '\EFI\ubuntu\grubx64.efi'

Nie testowałem tego, ale prawdopodobnie konieczne jest posiadanie unikalnych etykiet (-L) między ESP na sdai sdb.

Spowoduje to wygenerowanie wydruku bieżącej kolejności rozruchu, np

Timeout: 0 seconds
BootOrder: 0009,0008,0000,0001,0002,000B,0003,0004,0005,0006,0007
Boot0000  Windows Boot Manager
Boot0001  DTO UEFI USB Floppy/CD
Boot0002  DTO UEFI USB Hard Drive
Boot0003* DTO UEFI ATAPI CD-ROM Drive
Boot0004  CD/DVD Drive 
Boot0005  DTO Legacy USB Floppy/CD
Boot0006* Hard Drive
Boot0007* IBA GE Slot 00C8 v1550
Boot0008* Ubuntu
Boot000B  KingstonDT 101 II PMAP
Boot0009* Ubuntu #2

Zauważ, że Ubuntu # 2 (sdb) i Ubuntu (sda) są pierwszymi w kolejności rozruchu.

Restart

Teraz jesteśmy gotowi do ponownego uruchomienia.

exit # from chroot
exit # from sudo -s
sudo reboot

System powinien teraz ponownie uruchomić się w Ubuntu (może być konieczne usunięcie nośnika instalacyjnego Ubuntu Live).

Po uruchomieniu możesz uruchomić

sudo update-grub

aby podłączyć moduł ładujący Windows do łańcucha rozruchowego grub.

Gotcha maszyny wirtualnej

Jeśli chcesz to najpierw wypróbować na maszynie wirtualnej, istnieją pewne zastrzeżenia: Najwyraźniej pamięć NVRAM przechowująca informacje o UEFI jest zapamiętywana między restartami, ale nie między cyklami zamykania i restartowania. W takim przypadku możesz skończyć w konsoli Shell UEFI. Następujące polecenia powinny uruchomić komputer z /dev/sda1(użyj FS1:dla /dev/sdb1):

FS0:
\EFI\ubuntu\grubx64.efi

Pomocne może być również pierwsze rozwiązanie z pierwszej odpowiedzi rozruchu UEFI w virtualbox - Ubuntu 12.04 .

Symulacja awarii dysku

Awarię dowolnego urządzenia składowego RAID można symulować za pomocą mdadm. Jednak, aby sprawdzić, czy bootowanie przetrwa awarię dysku, musiałem wyłączyć komputer i odłączyć zasilanie od dysku. Jeśli to zrobisz, najpierw upewnij się, że urządzenia MD są zsynchronizowane .

cat /proc/mdstat 

Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md1 : active raid1 sdb3[2] sda3[0]
      216269952 blocks super 1.2 [2/2] [UU]
      bitmap: 2/2 pages [8KB], 65536KB chunk

md0 : active raid1 sda2[0] sdb2[2]
      33537920 blocks super 1.2 [2/2] [UU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

unused devices: <none>

W poniższych instrukcjach sdX jest uszkodzonym urządzeniem (X = a lub b), a sdY jest urządzeniem ok.

Odłącz dysk

Wyłącz komputer. Odłącz dysk. Uruchom ponownie Ubuntu powinien teraz uruchamiać się z dyskami RAID w trybie awaryjnym. (Świętuj! Właśnie to starałeś się osiągnąć!;)

cat /proc/mdstat 

Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md1 : active raid1 sda3[0]
      216269952 blocks super 1.2 [2/1] [U_]
      bitmap: 2/2 pages [8KB], 65536KB chunk

md0 : active raid1 sda2[0]
      33537920 blocks super 1.2 [2/1] [U_]
      bitmap: 0/1 pages [0KB], 65536KB chunk

unused devices: <none>

Odzyskaj z uszkodzonego dysku

Jest to proces, który należy wykonać, jeśli trzeba wymienić uszkodzony dysk. Jeśli chcesz emulować zamiennik, możesz uruchomić się w sesji Ubuntu Live i użyć

dd if=/dev/zero of=/dev/sdX

wyczyść dysk przed ponownym uruchomieniem w prawdziwym systemie. Jeśli właśnie przetestowałeś redundancję rozruchową / RAID w powyższej sekcji, możesz pominąć ten krok. Należy jednak wykonać przynajmniej kroki 2 i 4 poniżej, aby odzyskać pełną nadmiarowość rozruchu / RAID dla systemu.

Przywracanie systemu rozruchowego RAID + po wymianie dysku wymaga następujących kroków:

1. Podziel nowy dysk na partycje.
2. Dodaj partycje do urządzeń MD.
3. Sklonuj partycję rozruchową.
4. Dodaj rekord EFI dla klonu.

1. Podziel nowy dysk na partycje

Skopiuj tablicę partycji ze zdrowego dysku:

sudo sgdisk /dev/sdY -R /dev/sdX

Ponownie randomizuj identyfikatory UUID na nowym dysku.

sudo sgdisk /dev/sdX -G

2. Dodaj do urządzeń md

sudo mdadm --add /dev/md0 /dev/sdX2
sudo mdadm --add /dev/md1 /dev/sdX3

3. Sklonuj partycję rozruchową

Sklonuj ESP ze zdrowego dysku. (Ostrożnie, może najpierw zrób zrzut do pliku obu ESP, aby włączyć odzyskiwanie, jeśli naprawdę to popsułeś).

sudo dd if=/dev/sdY1 of=/dev/sdX1

4. Włóż nowo przywrócony dysk do kolejności rozruchu

Dodaj rekord EFI dla klonu. Zmodyfikuj odpowiednio etykietę -L.

sudo efibootmgr -c -g -d /dev/sdX -p 1 -L "Ubuntu #2" -l '\EFI\ubuntu\grubx64.efi'

Teraz zrestartowanie systemu powinno przywrócić go do normy (urządzenia RAID mogą nadal synchronizować)!

Dlaczego skrypt snu?

Społeczność zasugerowała, że ​​dodanie skryptu uśpienia może być niepotrzebne i może zostać zastąpione przez użycie GRUB_CMDLINE_LINUX="rootdelay=30"in, /etc/default/gruba następniesudo update-grub . Ta sugestia jest z pewnością czystsza i działa w przypadku awarii / wymiany dysku. Istnieje jednak zastrzeżenie ...

Odłączyłem swój drugi dysk SSD i dowiedziałem się, że za pomocą rootdelay=30itd. Zamiast skryptu uśpienia:
1) System uruchamia się w trybie awaryjnym bez „uszkodzonego” napędu.
2) W przypadku rozruchu bez pogorszenia jakości (obecne są oba dyski) czas rozruchu jest skrócony. Opóźnienie jest zauważalne tylko przy braku drugiego napędu.

1) i 2) brzmiało świetnie, dopóki nie dodałem ponownie drugiego dysku. Podczas rozruchu macierz RAID nie udało się złożyć i pozostawił mnie initramfsbez pytania, co zrobić. Możliwe, że udało się uratować sytuację, a) ​​uruchamiając pamięć USB Ubuntu Live, b) instalując mdadmi c) ręcznie montując tablicę, ale ... gdzieś popełniłem błąd. Zamiast tego, kiedy ponownie uruchomiłem ten test ze skryptem uśpienia (tak, uruchomiłem HOWTO od góry po raz n-ty ...), system się uruchomił. Tablice były w trybie zdegradowanym i mogłem ręcznie dodawać /dev/sdb[23]partycje bez dodatkowej pamięci USB. Nie wiem, dlaczego skrypt uśpienia działa, podczas gdy rootdelaynie. Być może mdadmsą mylone przez dwa, nieco niesynchronizowane urządzenia składowe, ale pomyślałemmdadm został zaprojektowany do obsługi tego. W każdym razie, skoro skrypt uśpienia działa, trzymam się go.

Można argumentować, że usunięcie całkowicie zdrowego urządzenia składowego RAID, ponowne uruchomienie RAID do trybu awaryjnego, a następnie ponowne dodanie urządzenia składowego jest nierealnym scenariuszem: realistyczny scenariusz polega raczej na tym, że jedno urządzenie ulegnie awarii i zostanie zastąpione nowym , pozostawiając mniej okazji mdadmdo zagubienia. Zgadzam się z tym argumentem. Nie wiem jednak, jak przetestować, w jaki sposób system toleruje awarię sprzętu, poza faktycznym wyłączeniem niektórych urządzeń! Po testach chcę wrócić do nadmiarowego, działającego systemu. (Cóż, mógłbym podłączyć mój drugi dysk SSD do innego komputera i przesunąć go przed ponownym dodaniem, ale to nie jest możliwe).

Podsumowując: Według mojej wiedzy rootdelayrozwiązanie jest czyste, szybsze niż skrypt uśpienia dla rozruchów bez pogorszenia jakości i powinno działać w przypadku scenariusza rzeczywistej awarii / wymiany dysku. Nie znam jednak możliwego sposobu na przetestowanie tego. Na razie będę się trzymał brzydkiego scenariusza snu.

Moja sugestia dotyczy systemu operacyjnego Debian, ale myślę, że działałoby to również w Ubuntu i innych.

Jednym z możliwych sposobów rozwiązania problemu występującego w przypadku, gdy wiele płyt głównych nie obsługuje poprawnie wpisów UEFI (Debian nie uruchamia się, nawet jeśli wprowadziłeś poprawny wpis efibootmgr -c -g -d /dev/sda -p 1 -w -L "debian" -l /EFI/debian/grubx64.efi, UEFI BIOS pokazuje dysk startowy „debian”, ale nie uruchamia się z niego ), zamiast tego należy użyć wpisu rodzajowego /boot/efi/EFI/boot/bootx4.efi.

Na przykład Asus Z87C nie lubi /EFI/debian/grubx64.efi.

Jeśli więc zamontowałeś partycję efi /dev/sda1do /boot/efiścieżki:

mkdir /boot/efi/EFI/boot
cp /boot/efi/EFI/debian/grubx64.efi /boot/efi/EFI/boot/bootx4.efi

Następnie uruchom ponownie.

UEFI BIOS wyświetli ogólny dysk „UEFI OS”, a także wszelkie inne wpisy utworzone wcześniej za pomocą efibootmgr, ale bez problemu uruchomi się z ogólnego „UEFI OS”.