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:
- Uruchom przy użyciu Ubuntu Live CD / USB.
- Partycjonuje dyski SSD zgodnie z wymaganiami.
- Zainstaluj brakujące pakiety (mdadm i grub-efi).
- Utwórz partycje RAID.
- Uruchom instalator Ubiquity (ale nie uruchamiaj się w nowym systemie).
- Załataj zainstalowany system (initramfs), aby umożliwić rozruch z rootowanego RAID.
- Wypełnij partycję EFI pierwszego dysku SSD za pomocą GRUB i zainstaluj ją w łańcuchu rozruchowym EFI.
- Sklonować partycję EFI na drugą SSD i zainstalować go na łańcuchu rozruchowej.
- 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. xterm
Aby 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 ubuntu
jest 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-server
generuje 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-signed
zamiast tego, grub-efi-amd64
jeś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 ubiquity
instalacji 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ń md1p1
typ na ext4
, sformatuj: tak i punkt podłączenia /
. md0p1
Partycji 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_boot
pozwoli uniknąć zapisywania Diskfilter nie są obsługiwane błędy. Wyłączenie quiet_boot
odbywa 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/grub
aby 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/Ubuntu
on /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ć sda
dysk. Ponadto mdadm
powinien być w stanie poradzić sobie z awarią dysku sda
lub sdb
dysku. 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 sdb1
partycji (według zgłoszenia blkid
) będzie zgodny z sda1
i /etc/fstab
. (Pamiętaj jednak, że identyfikatory UUID dla partycji /dev/sda1
i /dev/sdb1
będą się nadal różnić - porównaj ls -la /dev/disk/by-partuuid | grep sd[ab]1
z blkid /dev/sd[ab]1
po instalacji, aby sprawdzić sam.)
Na koniec musimy wstawić sdb1
partycję 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 sda
i 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:
- Podziel nowy dysk na partycje.
- Dodaj partycje do urządzeń MD.
- Sklonuj partycję rozruchową.
- 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/grub
a 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=30
itd. 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 initramfs
bez pytania, co zrobić. Możliwe, że udało się uratować sytuację, a) uruchamiając pamięć USB Ubuntu Live, b) instalując mdadm
i 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 rootdelay
nie. Być może mdadm
są 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 mdadm
do 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 rootdelay
rozwią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.
mount | grep efi
). Najwyraźniej linux montuje pierwszą partycję, której blkid pasuje/etc/fstab
. Nie powinno to jednak stanowić problemu.apt-get install mdadm
imdadm -A /dev/md0
mdadm -A /dev/md1
.grub-efi-amd64-signed
przeciwnym razie pojawiał się błąd efi „nieprawidłowy podpis”, jeśli włączony był bezpieczny rozruch.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/sda1
do/boot/efi
ścieżki: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”.
źródło