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 initramfs
konsoli jesionowej.
Co ja robię źle?
Odpowiedzi:
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:
use_lvmetad=1
nause_lvmetad=0
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/sdX
i 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:
swapoff -a
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/sdX2
podczas konfigurowania partycji na początku.)mkswap /dev/mapper/swap
)sfdisk --list /dev/sdX
nie 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-initramfs
jak 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ć, żeupdate-initramfs
narzekał 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
.)źródło
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.
źródło
mount /dev/mapper/data /tmp/data
dostajęunknown filesystem type LVM2_member
.Failed to connect to lvmetad
Błą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.
cd /mnt/home/your_username
...rm ...
)źródło
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:
Kasować:
i dodaj:
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
4) Dowiedz się, co poszło nie tak:
źródło