Ubuntu nie uruchamia się z powodu lvmetad

Wykonałem ten samouczek, aby zainstalować Ubuntu 15.10:

https://thesimplecomputer.info/full-disk-encryption-with-ubuntu

Po ponownym uruchomieniu komputera przeszedłem do menu grub i wybrałem Ubuntu. Wkrótce potem dostałem ten błąd:

/run/lvm/lvmetad.socket: connect failed: No such file or directory
WARNING: Failed to connect to lvmetad. Falling back to internal scanning.

Te wiadomości sumują się na czarnym ekranie co sekundę. Po chwili uzyskuję dostęp do initramfskonsoli jesionowej.

Co ja robię źle?

Dzisiaj widziałem ten sam błąd na laptopie z systemem Ubuntu 15.10, który zawsze aktualizowałem, ale nie restartowałem go przez miesiąc, dopóki nie chciałem przetestować bieżącego jądra (tj. Mogła nastąpić ostatnia zmiana).

W każdym razie okazało się, że w moim przypadku przyczyną była „brakująca” partycja wymiany z powodu usterki konfiguracji podczas wykonywania powyższego samouczka. W takim przypadku i / lub faktycznie używasz lvm, możesz pominąć krok 2 poniżej. Oczywiście powyższy komunikat o błędzie może również zostać wyświetlony w przypadku, gdy partycja systemowa (lub dane dodatkowe) została uszkodzona lub nie można jej znaleźć (patrz krok 3).

Krok 1: Zamontuj system, uruchom partycje zgodnie z wyżej wymienionym samouczkiem

Powiedzmy, że twoją (ext2) partycją rozruchową jest / dev / sdX1, twoją (zaszyfrowaną) partycją wymiany jest / dev / sdX2, twoją (zaszyfrowaną) partycją danych jest / dev / sdX3 i pomyślnie ją odszyfrowałeś cryptsetup luksOpen /dev/sdX3 data, a następnie montujesz to: mkdir /tmp/data; mount /dev/mapper/data /tmp/data.

Zwróć uwagę na podłączenia mount w tutorialu i upewnij się, że zamontowałeś / dev / sdX1, abyś mógł uzyskać do niego dostęp z katalogu / boot partycji systemowej (jest to bardzo ważne, ponieważ musimy wykonać update-initramfs).

Poniżej zakładamy, że pomyślnie wykonałeś chroot /tmp/data/@ubuntu1510(lub jakkolwiek nazywa się zamontowana partycja systemowa)

Krok 2: Pozbądź się powyższego komunikatu o błędzie

Używam btrfs (jak można się domyślić na podstawie wspomnianej nazwy podobjętości), więc lvmetad można łatwo wyłączyć w następujący sposób bez utraty funkcjonalności:

• edytuj /etc/lvm/lvm.conf i zmień use_lvmetad=1nause_lvmetad=0
• wykonać update-initramfs -k $(uname -r) -u ; sync

Teraz mógł restart i komunikat błędu powinien zniknąć. Jednak w moim przypadku następny komunikat o błędzie [1] wskazał mi na wspomniany wyżej problem podstawowy, więc skoro już go mamy, ...

Krok 3: Upewnij się, że / etc / crypttab wskazuje prawidłowe, nieuszkodzone partycje

Najpierw uruchom sfdisk --list /dev/sdXi sprawdź, czy twoja zaszyfrowana partycja wymiany (w moim przypadku / dev / sdX2) faktycznie nie wyświetla się jako (normalna) partycja wymiany. Jeśli tak (jak w moim przypadku), oznaczało to, że podczas rozruchu, np. Z dysku ratunkowego, prawdopodobnie wykorzystana zostanie ta dostępna partycja wymiany, zastępując w ten sposób metadane związane z szyfrowaniem (hasło i UUID).

Następnie spójrz na / dev / disk / by-uuid i porównaj odpowiednie UUID twoich zaszyfrowanych partycji z tymi zawartymi w / etc / crypttab. Zgaduję w tym momencie: w twoim przypadku istnieje rozbieżność.

Jeśli dedykowanej zaszyfrowanej partycji wymiany nie ma nigdzie poniżej / dev / disk / by-uuid, dzieje się tak, ponieważ jest ona obecnie używana przez system ratunkowy. W takim przypadku wykonaj następujące czynności:

• upewnij się, że przestałeś używać partycji: swapoff -a
• sformatuj go: mkfs.ext2 /dev/sdX2(jest to szczególnie ważne , szczególnie przy korzystaniu z partycji GPT [2], ponieważ usuwa usterkę, o której wspominałem wcześniej. Prawdopodobną przyczyną, dla której partycja pojawia się jako typ „swap” na liście sfdisk, jest to, że błędnie użyłeś / eś mkswap /dev/sdX2podczas konfigurowania partycji na początku.)
• postępuj zgodnie z samouczkiem, aby zaszyfrować partycję i ustawić hasło; następnie otwórz go za pomocą cryptsetup i odpowiednio sformatuj teraz odszyfrowaną partycję (używając czegoś podobnego mkswap /dev/mapper/swap)
• upewnij się, że sfdisk --list /dev/sdXnie zidentyfikuje partycji wymiany jako takiej (w takim przypadku powtórz ostatnie kroki)

Teraz sprawdź ponownie, czy identyfikatory UUID wymienione w / etc / crypttab są zgodne z tym, co widzisz poniżej / dev / disk / by-uuid dla odpowiednich zaszyfrowanych partycji.

Ponownie, aby zmiany były trwałe, musisz wykonać update-initramfsjak pokazano powyżej.

Jeśli jesteś zadowolony, upewnij się, że wszystko jest zapisane na dysku i uruchom ponownie system (nie musisz ręcznie odmontowywać wszystkiego). Potem twój problem powinien zniknąć.

[1] może nie zwracałem uwagi za pierwszym razem lub pierwszy komunikat o błędzie „zamaskował” drugi; tzn. dopiero po ponownym uruchomieniu (przy pomocy use_lvmetad=0) został wyświetlony komunikat „ Odczytywanie wszystkich woluminów fizycznych. Może to chwilę potrwać ... ” (powtarzane wiele razy), a następnie „ ALERT! / dev / disk / by-uuid / .. . nie istnieje. " (Należy zauważyć, że update-initramfsnarzekał również na brakującą partycję).

[2], ponieważ ich typ jest odejmowany od analizy zawartości i nie jest ostatecznie określany przez flagę / bajt (dlatego nie ma łatwego sposobu np. Zmiany typu systemu plików GPT [g]parted.)

Ubuntu 18.04.1 LTS tutaj. Działał przez kilka miesięcy bez opieki, ale kiedy wróciłem, nie rozpoznałem klawiatury. Po ponownym uruchomieniu dostałem komunikat „nie mogę się połączyć z lvmetad” i więcej o tym, że nie mogę uzyskać „listy db UEFI”.

Zainstalowałem bez szyfrowania dysku.

Komunikat UEFI był niepokojący, ponieważ była to moja pierwsza instalacja na komputerze UEFI, więc nie miałem doświadczenia i, szczerze mówiąc, wciąż nie jestem poinformowany o użyteczności. Mój problem spotęgował fakt, że użyłem lvm na tym, co miało być moim „/”, rootem, woluminem. (W rzeczywistości już zapomniałem, jak to osiągnąłem! Hej. Jestem stary.)

Jednak gdy komputer nie uruchomił się ponownie, szukałem rozwiązania i nie znalazłem nic ostatecznego, ale zauważyłem, że a) moja partycja EFI była mniejsza niż 500 MB zalecana na jednej stronie, oraz b) osobna / boot / partycja, którą zorganizowałem ponieważ był prawdopodobnie nieistotny i nieużywany. Pomyślałem, że możliwe, że nienadzorowane ulepszenie mogło spowodować, że coś wypełniło przydzielone miejsce.

Postanowiłem zainstalować ponownie - co zadziałało i pozostawiłem strukturę folderów / home / niezmąconą. Nie sprawdziłem / etc /, ale zrobiłem wcześniej kopie obu z nich [1], więc mogę to sprawdzić później. / etc / jest naprawdę mały.

Usunąłem również usunięte i połączyłem partycje dla EFI i / boot / w jedną, większą partycję EFI (> 750 MB).

Teraz uruchamia się ponownie, ale pojedynczy komunikat o błędzie miga zbyt szybko, aby go odczytać, i nie zaoferowano mi menu rozruchowego obrazów systemu Linux do uruchomienia, zamiast tego uruchamia się bezpośrednio w Ubuntu. Jest jeszcze wiele pracy do zrobienia, z grub, jak sądzę, aby rozwiązać ten problem. Ale przynajmniej moje pliki wróciły.

[1] Uruchomiłem instalację Ubuntu z pamięci USB i wybrałem „wypróbowanie” Ubuntu, co pozwoliło mi na wykonanie kopii itp. I domu, zanim wybrałem „Instaluj” z pulpitu.

Failed to connect to lvmetadBłąd może się zdarzyć, ponieważ dysk jest w 100% pełny. Aby to naprawić, uruchom komputer z napędu USB, zamontuj pełny dysk, usuń niepotrzebne pliki i uruchom ponownie. Ponownie zainstalowałem system rozruchowy - nie wiem, czy jest to konieczne, czy nie.

Są to polecenia, które rozwiązały problem, uruchamiany z terminala po uruchomieniu z dysku USB. Mam zapasowe Ubuntu 18.04 z szyfrowaniem pełnego dysku. YMMV.

• zamontuj dysk:

sudo cryptsetup luksOpen /dev/sda5 sda5_crypt
sudo vgscan --mknodes
sudo vgchange -ay
sudo mount /dev/mapper/ubuntu--vg-root /mnt

• usuń niepotrzebne pliki ( cd /mnt/home/your_username... rm ...)
• (może nie być konieczne) zainstaluj ponownie system rozruchowy:

cd /mnt/
sudo mount /dev/sda1 boot
for d in dev sys proc run; do sudo mount --bind /$d $d; done
sudo vi etc/crypttab # make sure first line uses "sda5_crypt"
sudo chroot .
update-grub
grub-install /dev/sda
update-initramfs -u -k all
exit
sudo umount dev sys proc run boot

• odmontować:

cd /
sudo umount /mnt
sudo vgchange -an
sudo cryptsetup close sda5_crypt

• restart:

sudo reboot

Nie jest konieczne uruchamianie systemu z USB lub czegoś innego. Miałem ten sam problem i przyczynę - ponieważ dysk jest w 100% pełny. Następne rozwiązanie pomogło mi.

1) Uruchom ponownie system. W systemie BIOS szybko naciśnij i przytrzymaj klawisz Shift, co spowoduje wyświetlenie menu GNU GRUB.

2) Po naciśnięciu „e”, aby edytować ustawienia Ubuntu. W tym problemie można znaleźć ekrany. Znajdź ciąg zaczynający się na „linux *”, jak poniżej:

linux     /boot/vmlinuz-4-4.0-22-generic root=UUID=43ad24d3-e\
c5b-44ee-a099-a88eb9520989 ro  quiet splash $vt_handoff

Kasować:

ro  quiet splash $vt_handoff

i dodaj:

init=/bin/bash

Po zakończeniu naciśnij CTRL + x lub F10, aby uruchomić.

3) Partycja główna jest zamontowana tylko do odczytu. Aby zamontować go do odczytu / zapisu, wprowadź polecenie

mount -o remount,rw /

4) Dowiedz się, co poszło nie tak:

df -hT