bootctl — Kontroluj ustawienia rozruchu oprogramowania układowego EFI i zarządzaj programem ładującym
bootctl [OPTIONS...] {COMMAND}
bootctl może sprawdzać oprogramowanie układowe EFI i status programu ładującego, wyświetlać listę dostępnych programów ładujących i wpisów programu ładującego oraz zarządzać nimi, a także instalować, aktualizować lub usuwać systemd-boot(7) program ładujący w bieżącym systemie.
Te polecenia są dostępne w każdym systemie EFI, niezależnie od używanego programu ładującego.
Wyświetla krótkie informacje o oprogramowaniu układowym systemu, programie ładującym, który został użyty do uruchomienia systemu, programach ładujących dostępnych obecnie w ESP, programach ładujących wymienionych na liście oprogramowania układowego programów ładujących oraz bieżącej domyślnej pozycji modułu ładującego. Jeśli nie określono żadnego polecenia, jest to implikowana wartość domyślna.
Zobacz poniższy przykład, aby uzyskać szczegółowe informacje na temat danych wyjściowych.
Zapytanie lub ustaw flagę „Reboot-Into-Firmware-Setup” oprogramowania układowego EFI. Pobiera argument logiczny, który kontroluje, czy pokazywać konfigurację oprogramowania układowego przy następnym uruchomieniu systemu. Jeśli argument zostanie pominięty, pokazuje aktualny stan flagi lub czy flaga jest obsługiwana. Kontroluje tę samą flagę, co systemctl reboot --firmware-setup, ale jest na niższym poziomie i umożliwia ustawienie flagi niezależnie od rzeczywistego żądania ponownego uruchomienia.
Wskazówka: użyj systemctl reboot --firmware-setup, aby raz ponownie uruchomić komputer w celu konfiguracji oprogramowania układowego. Zobacz systemctl(1), aby uzyskać szczegółowe informacje.
W przypadku wywołania bez opcjonalnego argumentu drukuje bieżącą wartość zmiennej EFI „SystemdOptions”. Po wywołaniu z argumentem ustawia zmienną na tę wartość. Zobacz systemd(1), aby poznać znaczenie tej zmiennej.
Te polecenia są dostępne dla wszystkich programów ładujących, które implementują specyfikację programu ładującego[1], na przykład systemd-boot.
Pokazuje wszystkie dostępne wpisy modułu ładującego implementujące specyfikację modułu ładującego[1], a także wszelkie inne wpisy wykryte lub automatycznie wygenerowane przez program ładujący obsługujący interfejs modułu ładującego[2 ]. Dane wyjściowe JSON można zażądać za pomocą --json=.
Zobacz poniższy przykład, aby uzyskać szczegółowe informacje na temat danych wyjściowych.
Usuwa wpis modułu ładującego, w tym pliki, do których się odnosi. Jako argument przyjmuje pojedynczy ciąg identyfikatora wpisu programu ładującego rozruchu lub wzorzec globalny. Pliki odniesienia, takie jak jądro lub initrd, są usuwane tylko wtedy, gdy nie odnosi się do nich żaden inny wpis.
Usuwa pliki z partycji ESP i XBOOTLDR, które należą do tokena wejścia, ale nie są przywoływane we wpisach modułu ładującego.
Te polecenia są dostępne dla wszystkich programów ładujących, które implementują specyfikację modułu ładującego[1] i interfejs modułu ładującego[2], na przykład systemd-boot.
Ustawia domyślny wpis modułu ładującego. Jako argument przyjmuje pojedynczy ciąg identyfikatora wpisu programu ładującego rozruchu lub wzorzec globalny. Polecenie set-oneshot ustawi domyślny wpis tylko dla następnego rozruchu, set-default ustawi go na stałe dla wszystkich przyszłych rozruchów.
bootctl list może służyć do wyświetlania listy dostępnych wpisów modułu ładującego i ich identyfikatorów.
Ponadto identyfikator wpisu modułu ładującego można określić jako jeden z następujących: @default, @oneshot lub @current, które odpowiadają bieżącemu domyślny wpis programu ładującego dla wszystkich przyszłych rozruchów, bieżący domyślny wpis programu ładującego dla następnego rozruchu oraz aktualnie uruchamiany wpis programu ładującego. Te identyfikatory specjalne są tłumaczone na bieżące wartości zmiennych EFI LoaderEntryDefault, LoaderEntryOneShot i LoaderEntrySelected, patrz Specyfikacja modułu ładującego >[1], aby uzyskać szczegółowe informacje. Te specjalne identyfikatory są przede wszystkim przydatne jako szybki sposób trwałego ustawienia aktualnie uruchamianego wpisu programu ładującego jako domyślny wybór lub uaktualnienia domyślnego wpisu programu ładującego dla następnego rozruchu do domyślnego wpisu programu ładującego dla wszystkich przyszłych rozruchów, ale mogą być używane również do innych operacji.
Jeśli ustawione na @saved, wybrany wpis zostanie zapisany jako zmienna EFI przy każdym uruchomieniu i automatycznie wybrany przy następnym uruchomieniu programu ładującego.
Jeśli jako identyfikator zostanie określony pusty ciąg („”), odpowiadająca mu zmienna EFI zostanie anulowana.
Wskazówka: użyj systemctl reboot --boot-loader-entry=ID, aby ponownie uruchomić komputer do określonego wpisu rozruchowego i systemctl reboot --boot-loader-menu=<timeout, aby raz ponownie uruchomić komputer w menu modułu ładującego. Zobacz systemctl(1), aby uzyskać szczegółowe informacje.
Ustawia limit czasu menu modułu ładującego w sekundach. Polecenie set-timeout-oneshot ustawi limit czasu tylko dla następnego rozruchu. Zobacz systemd.time(7), aby uzyskać szczegółowe informacje na temat składni okresów czasu.
Jeśli jest to ustawione na menu-hidden lub 0, żadne menu nie jest wyświetlane, a pozycja domyślna zostanie uruchomiona natychmiast, przy ustawieniu na menu-force wyłącza limit czasu, jednocześnie wyświetlając menu. Po określeniu pustego ciągu znaków ("") program ładujący powróci do domyślnego limitu czasu menu.
Te polecenia zarządzają programem ładującym EFI systemd-boot i nie działają w połączeniu z innymi programami ładującymi.
Instaluje systemd-boot na partycji systemowej EFI. Kopia systemd-boot zostanie zapisana jako domyślny/awaryjny program ładujący EFI w ESP/EFI/BOOT/BOOT*.EFI. Program ładujący jest następnie dodawany na początek listy programów ładujących oprogramowanie układowe.
Aktualizuje wszystkie zainstalowane wersje systemd-boot(7), jeśli dostępna wersja jest nowsza niż wersja zainstalowana na partycji systemowej EFI. Obejmuje to również domyślny/rezerwowy program ładujący EFI w ESP/EFI/BOOT/BOOT*.EFI. Program ładujący jest następnie dodawany na końcu listy programów ładujących oprogramowanie układowe, jeśli go brakuje.
Usuwa wszystkie zainstalowane wersje systemd-boot z partycji systemowej EFI i listy programów ładujących oprogramowanie sprzętowe.
Sprawdza, czy systemd-boot jest zainstalowany w ESP. Zauważ, że jeden ESP może obsługiwać wiele programów ładujących; sprawdza to zatem, czy systemd-boot jest jednym (z prawdopodobnie wielu) zainstalowanych programów ładujących — ani czy jest domyślny, ani czy jest zarejestrowany w jakichkolwiek zmiennych EFI.
Generuje losowe ziarno i przechowuje je w partycji systemowej EFI do wykorzystania przez program ładujący systemd-boot. Ponadto generuje losowy token systemowy i przechowuje go na stałe jako zmienną EFI, jeśli nie został wcześniej ustawiony. Jeśli program ładujący znajdzie losowe ziarno w ESP i token systemowy w zmiennej EFI, uzyska losowe ziarno do przekazania do systemu operacyjnego i nowe ziarno do przechowywania w ESP z kombinacji obu. Losowe ziarno przekazane do systemu operacyjnego jest przypisywane do puli entropii jądra przez menedżera systemu podczas wczesnego rozruchu i umożliwia uruchomienie przestrzeni użytkownika z w pełni zainicjowaną pulą entropii bardzo wcześnie. Zobacz też systemd-boot-random-seed.service(8).
Zobacz Losowe nasiona[3], aby uzyskać więcej informacji.
Pobiera obraz jądra jako argument. Sprawdza, jakiego rodzaju jądra jest obraz. Zwraca jedno z „uki”, „pe” i „nieznane”.
Pobiera obraz jądra jako argument. Drukuje szczegółowe informacje o obrazie.
Rozumie się następujące opcje:
Ścieżka do partycji systemowej EFI (ESP). Jeśli nie określono, kolejno sprawdzane są /efi/, /boot/ i /boot/efi/. Zaleca się zamontowanie ESP w /efi/, jeśli to możliwe.
Ścieżka do rozszerzonej partycji modułu ładującego, zgodnie z definicją w specyfikacji modułu ładującego[1]. Jeśli nie określono, /boot/ jest zaznaczone. Jeśli to możliwe, zaleca się zamontowanie partycji Extended Boot Loader w katalogu /boot/.
Pobiera ścieżkę katalogu jako argument. Wszystkie ścieżki zostaną poprzedzone podaną alternatywną ścieżką root, w tym ścieżki wyszukiwania konfiguracji.
Pobiera ścieżkę do pliku obrazu dysku lub węzła urządzenia blokowego. Jeśli określono, wszystkie operacje są stosowane do systemu plików we wskazanym obrazie dysku. Ta opcja jest podobna do --root=, ale działa na systemach plików przechowywanych w obrazach dysków lub urządzeniach blokowych. Obraz dysku powinien zawierać tylko system plików lub zestaw systemów plików w tablicy partycji GPT, zgodnie ze specyfikacją wykrywalnych partycji[4]. Aby uzyskać więcej informacji na temat obsługiwanych obrazów dysków, zobacz przełącznik systemd-nspawn(1) o tej samej nazwie.
Podczas instalowania plików binarnych za pomocą --root= lub --image= wybiera źródło ich pochodzenia. Przyjmuje jedną z opcji „auto” (domyślnie), „image” lub „host”. Przy opcji „auto” pliki binarne zostaną pobrane z określonego katalogu lub obrazu, a jeśli nie zostaną znalezione, zostaną pobrane z hosta. W przypadku „obrazu” lub „hosta” żadne wyszukiwanie awaryjne nie zostanie przeprowadzone, jeśli pliki binarne nie zostaną znalezione w wybranym źródle.
Ta opcja modyfikuje zachowanie statusu. Wypisuje tylko ścieżkę do partycji systemowej EFI (ESP) na standardowe wyjście i kończy działanie.
Ta opcja modyfikuje zachowanie statusu. Wypisuje tylko ścieżkę do partycji rozszerzonego modułu ładującego, jeśli taka istnieje, oraz ścieżkę do ESP w przeciwnym razie na standardowe wyjście i wyjście. To polecenie jest przydatne do określenia, gdzie umieścić wpisy programu ładującego, ponieważ są one najlepiej umieszczane na partycji rozszerzonego modułu ładującego, jeśli istnieje, aw przeciwnym razie na partycji ESP.
Wpisy Boot Loader Type #1 powinny być umieszczone w katalogu „$ (bootctl -x)/loader/entries/”. Istnienie tego katalogu może być również wykorzystane jako wskazówka, że w systemie dostępna jest obsługa wpisów modułu ładującego. Podobnie wpisy Boot Loader Specification Type #2 należy umieścić w katalogu „$ (bootctl -x)/EFI/Linux/”.
Zauważ, że ta opcja (podobnie jak wspomniana powyżej opcja --print-booth-path) jest dostępna niezależnie od używanego programu ładującego, tj. także bez użycia systemd-boot zainstalowany.
Nie dotykaj listy programów ładujących oprogramowania układowego przechowywanej w zmiennych EFI.
Zignoruj błąd, gdy nie można znaleźć partycji systemowej EFI, gdy nie można zapisać zmiennych EFI lub jest już zainstalowany inny lub nowszy program ładujący. Obecnie dotyczy tylko czasowników jest-zainstalowany, aktualizuj i losowo-początkowo.
Pomiń drukowanie wyników różnych poleceń, a także podpowiedzi o niedostępności ESP.
Steruje tworzeniem i usuwaniem specyfikacji modułu ładującego[1] Wpisz #1 katalog wpisu w systemie plików zawierający zasoby, takie jak obrazy jądra i initrd podczas instalowania i usuwania odpowiednio. Katalog jest nazwany zgodnie z tokenem wejścia, zgodnie z parametrem --entry-token= opisanym poniżej, i jest umieszczony bezpośrednio pod katalogiem głównym $BOOT (tj. system plików zwrócony przez opcję --print-boot-path, patrz wyżej). Domyślnie „nie”.
Kontroluje sposób nazywania i identyfikowania wpisów modułu ładującego dla tej instalacji systemu operacyjnego. Akceptowane podczas instalacji i jako argument przyjmuje jedno z „auto”, „machine-id”, „os-id”, „os-image-id” lub dowolny ciąg znaków poprzedzony „literal:” .
Jeśli ustawione na machine-id, wpisy są nazywane po identyfikatorze komputera działającego systemu (np. „b0e793a9baf14b5fa13ecbe84ff637ac”). Zobacz machine-id(5), aby uzyskać szczegółowe informacje na temat koncepcji i pliku identyfikatora komputera.
Jeśli ustawione na os-id, wpisy są nazwane na podstawie identyfikatora systemu operacyjnego działającego systemu, tj. pole ID= elementu os-release( 5) (np. „fedora”). Podobnie, jeśli ustawione na os-image-id, wpisy są nazywane na podstawie identyfikatora obrazu systemu operacyjnego działającego systemu, tj. pola IMAGE_ID= w os-release (np. „ vendorx-kasjer-system").
Jeśli ustawione na auto (domyślnie), plik /etc/kernel/entry-token zostanie odczytany, jeśli istnieje, i wykorzystana zostanie zapisana wartość. W przeciwnym razie, jeśli identyfikator komputera lokalnego zostanie zainicjowany, zostanie użyty. W przeciwnym razie zostanie użyte IMAGE_ID= z os-release, jeśli jest ustawione. W przeciwnym razie zostanie użyte ID= z os-release, jeśli jest ustawione.
O ile nie ustawiono na „machine-id” lub gdy użyto --make-entry-directory=yes, wybrany ciąg tokena jest zapisywany w pliku /etc/kernel/entry-token, aby zapewnić będzie używany do przyszłych wpisów. Ten plik jest również odczytywany przez kernel-install(8), w celu określenia, pod jaką nazwą mają być generowane wpisy modułu ładującego dla nowo zainstalowanych jąder, lub określenia nazw wpisów do usuwania starych.
Ogólnie preferowane jest używanie identyfikatora komputera do nazywania wpisów, jednak istnieją przypadki, w których dobrym rozwiązaniem jest użycie innych identyfikatorów. W szczególności: jeśli dane identyfikacyjne, które pociąga za sobą identyfikator komputera, nie powinny być przechowywane na (nieszyfrowanej) partycji $BOOT lub jeśli identyfikator ma być generowany przy pierwszym uruchomieniu i nie wiadomo, kiedy wpisy są przygotowywane . Należy zauważyć, że korzystanie z identyfikatora komputera ma tę zaletę, że wiele równoległych instalacji tego samego systemu operacyjnego może współistnieć na tym samym nośniku i mogą niezależnie aktualizować swoje wpisy programu ładującego. W przypadku korzystania z innego identyfikatora (takiego jak identyfikator systemu operacyjnego lub identyfikator obrazu systemu operacyjnego) równoległe instalacje tego samego systemu operacyjnego będą próbowały użyć tej samej nazwy wpisu. Aby zapewnić obsługę instalacji równoległych, instalator musi użyć innego tokena wejścia podczas dodawania drugiej instalacji.
Zainstaluj pliki binarne dla wszystkich obsługiwanych architektur EFI (oznacza to --no-variables).
Korzystanie z domyślnej nazwy wpisu „Linux Boot Manager” jest generalnie preferowane, ponieważ tylko jeden program ładujący zainstalowany na pojedynczej partycji ESP powinien być używany do uruchamiania dowolnej liczby instalacji systemu operacyjnego znajdujących się na różnych dyskach zainstalowanych w systemie. W szczególności dystrybucje nie powinny używać tej flagi do instalowania markowego wpisu na liście opcji rozruchu. Jednak w sytuacjach z wieloma dyskami, z których każdy ma własną partycję ESP, korzystne może być ułatwienie identyfikacji używanego programu ładującego w menu opcji rozruchu oprogramowania układowego.
Przebieg próbny dla --unlink i --cleanup.
W trybie pracy na sucho operacje odłączania i czyszczenia powodują wydrukowanie tylko tych plików, które zostałyby usunięte, bez faktycznego ich usuwania.
Nie przesyłaj danych wyjściowych do pagera.
Pokazuje dane wyjściowe sformatowane jako JSON. Oczekuje jednego z „krótkich” (dla najkrótszego możliwego wyniku bez zbędnych białych znaków lub łamania linii), „ładnego” (dla ładnej wersji tego samego, z wcięciami i podziałami linii) lub „wyłączony” (aby wyłączyć wyjście JSON, domyślny).
Wydrukuj krótki tekst pomocy i wyjdź.
Wydrukuj krótki ciąg wersji i wyjdź.
bootctl install i update będą szukać pliku systemd-boot zakończonego sufiksem „.efi.signed” najpierw i skopiuj go zamiast normalnego pliku „.efi”. Dzięki temu dystrybucje lub użytkownicy końcowi mogą dostarczać podpisane obrazy dla UEFI SecureBoot.
W przypadku sukcesu zwracane jest 0, w przeciwnym razie niezerowy kod błędu.
Jeśli ustawione jest $SYSTEMD_RELAX_ESP_CHECKS=1, sprawdzanie poprawności dla ESP jest rozluźnione, a ścieżka określona za pomocą --esp-path= może odnosić się do dowolnego systemu plików na dowolny rodzaj partycji.
Podobnie $SYSTEMD_RELAX_XBOOTLDR_CHECKS=1 wyłącza niektóre sprawdzanie poprawności partycji rozszerzonego modułu ładującego.
Przykład 1. Dane wyjściowe ze stanu i listy
$ bootctl status System: Firmware: UEFI 2.40 (firmware-version) ← firmware vendor and version Secure Boot: disabled (setup) ← Secure Boot status TPM2 Support: yes Boot into FW: supported ← does the firmware support booting into itself Current Boot Loader: ← details about sd-boot or another boot loader Product: systemd-boot version implementing the Boot Loader Interface[2] Features: ✓ Boot counting ✓ Menu timeout control ✓ One-shot menu timeout control ✓ Default entry control ✓ One-shot entry control ✓ Support for XBOOTLDR partition ✓ Support for passing random seed to OS ✓ Load drop-in drivers ✓ Boot loader sets ESP information ESP: /dev/disk/by-partuuid/01234567-89ab-cdef-dead-beef00000000 File: └─/EFI/systemd/systemd-bootx64.efi Random Seed: ← random seed used for entropy in early boot Passed to OS: yes System Token: set Exists: yes Available Boot Loaders on ESP: ESP: /boot/efi (/dev/disk/by-partuuid/01234567-89ab-cdef-dead-beef00000000) File: └─/EFI/systemd/systemd-bootx64.efi (systemd-boot 251 File: └─/EFI/BOOT/BOOTX64.EFI (systemd-boot 251 Boot Loaders Listed in EFI Variables: Title: Linux Boot Manager ID: 0x0001 Status: active, boot-order Partition: /dev/disk/by-partuuid/... File: └─/EFI/systemd/systemd-bootx64.efi Title: Fedora ID: 0x0000 Status: active, boot-order Partition: /dev/disk/by-partuuid/... File: └─/EFI/fedora/shimx64.efi Title: Linux-Firmware-Updater ID: 0x0002 Status: active, boot-order Partition: /dev/disk/by-partuuid/... File: └─/EFI/fedora/fwupdx64.efi Boot Loader Entries: $BOOT: /boot/efi (/dev/disk/by-partuuid/01234567-89ab-cdef-dead-beef00000000) Default Boot Loader Entry: type: Boot Loader Specification Type #1 (.conf) title: Fedora Linux 36 (Workstation Edition) id: ... source: /boot/efi/loader/entries/entry-token-kernel-version.conf version: kernel-version machine-id: ... linux: /entry-token/kernel-version/linux initrd: /entry-token/kernel-version/initrd options: root=...
$ bootctl list Boot Loader Entries: type: Boot Loader Specification Type #1 (.conf) title: Fedora Linux 36 (Workstation Edition) (default) (selected) id: ... source: /boot/efi/loader/entries/entry-token-kernel-version.conf version: kernel-version machine-id: ... linux: /entry-token/kernel-version/linux initrd: /entry-token/kernel-version/initrd options: root=... type: Boot Loader Specification Type #2 (.efi) title: Fedora Linux 35 (Workstation Edition) id: ... source: /boot/efi/EFI/Linux/fedora-kernel-version.efi version: kernel-version machine-id: ... linux: /EFI/Linux/fedora-kernel-version.efi options: root=... type: Automatic title: Reboot Into Firmware Interface id: auto-reboot-to-firmware-setup source: /sys/firmware/efi/efivars/LoaderEntries-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f
Na liście „(domyślnie)” określa wpis, który będzie używany domyślnie, a „(wybrany)” określa wpis, który został wybrany ostatnim razem (tj. jest obecnie uruchomiony).
systemd-boot(7), Boot Loader Specification[1], Boot Loader Interface[2], systemd-boot-random-seed.service(8)
Specyfikacja modułu ładującego: https://uapi-group.org/specifications/specs/boot_loader_specification
Interfejs modułu ładującego: https://systemd.io/BOOT_LOADER_INTERFACE
Losowe nasiona: https://systemd.io/RANDOM_SEEDS
Specyfikacja wykrywalnych partycji: https://uapi-group.org/specifications/specs/discoverable_partitions_specification