Sierpniowa poprawka do systemu Windows psuje niektóre systemy podwójnego rozruchu: jak to naprawić

Sierpniowa aktualizacja zabezpieczeń Sierpniowa aktualizacja zabezpieczeń dla systemu Windows załatała szereg kluczowych luk w zabezpieczeniach, ale wydaje się, że jedna z tych poprawek spowodowała problemy dla wielu użytkowników korzystających z Linuksa i Windowsa na tym samym sprzęcie. Problem dotyczy głównie systemów korzystających z programu ładującego GRUB 2, który jest dołączany do wielu dystrybucji Linuksa, wraz z funkcją Secure Boot. Na szczęście problem można naprawić bez większych trudności.

Jedna z poprawek bezpieczeństwa zawartych w aktualizacji ma na celu zablokowanie starszych bootloaderów, które Microsoft uważa za "podatne", przed użyciem z Secure Boot. Obejście, które umożliwiło to w pierwszej kolejności, jest zasadniczo sztucznym procesem podpisywania i jest łatane za pomocą ustawienia Secure Boot Advanced Targeting, w skrócie SBAT. Poprawka SBAT nie miała być wdrażana w systemach, w których aktualizator wykrył konfiguracje podwójnego rozruchu, ale coś poszło nie tak i wiele takich systemów zostało dotkniętych.

Użytkownicy podobno próbowali to naprawić na wiele sposobów, w tym bezpośrednio usuwając ustawienie SBAT, ale bezskutecznie. Ci, którzy dual-boot i nie pobrały jeszcze aktualizacji, są zachęcane do wstrzymania się z nią i mogą skorzystać ze specjalnego wpisu w rejestrze, aby zrezygnować z bieżącego cyklu aktualizacji, podczas gdy Microsoft i jego partnerzy Linux pracują nad poprawką.

Osoby, które już pobrały aktualizację i zostały zablokowane w swoim systemie podwójnego rozruchu, mogą po prostu wyłączyć Secure Boot w BIOS-ie, a następnie ponownie zainstalować wybraną wersję Linuksa i ponownie włączyć Secure Boot. Pozwoli to na pełną ponowną instalację bootloadera, który stał się bezużyteczny z powodu poprawki.

Wydaje się, że nie dotyczy to wszystkich użytkowników podwójnego rozruchu. Osoby korzystające z nowszych wersji Linuksa, ci, którzy trzymają Windows i Linuksa na oddzielnych dyskach fizycznych, a także ci, którzy skonfigurowali moduł kontrolny Secure Boot z własnymi kluczami niestandardowymi, należą do tych, którzy zgłaszają, że aktualizacja nie wyrządziła im żadnej szkody.