Zamień nie działa na czystej instalacji 14.04 przy użyciu zaszyfrowanego domu

28

Aktualizacja 3:

Postanowiłem ponownie zainstalować system od zera, aby usunąć wszelkie stare cruft leżące w pobliżu, ponieważ miałem również inne problemy po aktualizacji. Jednak problem nadal występował.

W przypadku czystej instalacji wybór instalacji za pomocą „szyfrowanego domu” prowadzi do zepsutej konfiguracji szyfrowanej wymiany.

Aktualizacja 2:

Naprawiłem kolejność podziału, na którą narzekał cfdisk, ale problem nadal występuje. Wymiana jest teraz włączona / dev / sda6 i mogę ją uruchomić w następujący sposób:

~$ sudo mkswap /dev/sda6
Setting up swapspace version 1, size = 7998460 KiB
no label, UUID=18881d0f-d9ec-43be-a23f-0cbd78ea6d22

$sudo nano /etc/crypttab # Update crypttad with new UUID

$ sudo /etc/init.d/cryptdisks reload
 * Stopping remaining crypto disks...
 * cryptswap1 (stopped)...                                               [ OK ] 
 * Starting remaining crypto disks...                                        
 * cryptswap1 (starting)..
 * cryptswap1 (started)...                                               [ OK ] 
$ sudo swapon -a

$ls -l /dev/disk/by-uuid/
total 0
lrwxrwxrwx 1 root root 10 May 11 09:04 08b07f88-6da5-4b40-b062-42b3bb1c5f00 -> ../../sda3
lrwxrwxrwx 1 root root 10 May 11 09:08 18881d0f-d9ec-43be-a23f-0cbd78ea6d22 -> ../../sda6
lrwxrwxrwx 1 root root 10 May 11 09:04 19aa372c-05c8-4226-8f09-c54e5566e816 -> ../../sda5
lrwxrwxrwx 1 root root 10 May 11 09:04 A800B16E00B143DA -> ../../sda1
lrwxrwxrwx 1 root root 10 May 11 09:04 D28230E68230D129 -> ../../sda2
lrwxrwxrwx 1 root root 10 May 11 09:08 fcc8c419-8fec-4d4d-b55e-9e4c3b04d21d -> ../../dm-0

Ale po ponownym uruchomieniu swap nie aktywuje się i po raz kolejny wygląda następująco:

$ ls -l /dev/disk/by-uuid/
total 0
lrwxrwxrwx 1 root root 10 May 11 09:12 08b07f88-6da5-4b40-b062-42b3bb1c5f00 -> ../../sda3
lrwxrwxrwx 1 root root 10 May 11 09:12 19aa372c-05c8-4226-8f09-c54e5566e816 -> ../../sda5
lrwxrwxrwx 1 root root 10 May 11 09:12 A800B16E00B143DA -> ../../sda1
lrwxrwxrwx 1 root root 10 May 11 09:12 D28230E68230D129 -> ../../sda2

W tej chwili domyślam się, że podczas konfigurowania dysku jako zaszyfrowanego linux nie rozpoznaje typu partycji i dlatego nie ładuje go poprawnie, co powoduje, że nie rejestruje się dla swojego identyfikatora UUID, a zatem zamiana kryptograficzna nie może go znaleźć, powodując awarię. Ale nie wiem jak to naprawić ...

Zaktualizowane pytanie:

Dalsze testy wykazały, że mogę uruchomić swap i uruchomić go, uruchamiając $ mkswap / dev / sda5

a następnie aktualizując / etc / crypttab z poprawnym UUID i postępując zgodnie z krokami opisanymi tutaj: Jak skonfigurować zaszyfrowany plik wymiany?

Problem pozostaje jednak po ponownym uruchomieniu komputera, / dev / sda5 nie pojawia się po uruchomieniu

$ ls -l /dev/disk/by-uuid/

Jeśli zrobię:

$ cfdisk /dev/sda 

Otrzymuję następujący błąd:

FATAL ERROR: Bad logical partition 6: enlarged logical partitions overlap
                      Press any key to exit cfdisk

Graficzne narzędzie „Dyski” nie narzeka na żaden błąd podczas otwierania używanego dysku.

$ sudo fdisk -l

Disk /dev/sda: 256.1 GB, 256060514304 bytes
255 heads, 63 sectors/track, 31130 cylinders, total 500118192 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x619aebf1

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048      206847      102400    7  HPFS/NTFS/exFAT
/dev/sda2          206848   100870143    50331648    7  HPFS/NTFS/exFAT
/dev/sda3       191397888   192397311      499712   83  Linux
/dev/sda4       192399358   500117503   153859073    5  Extended
/dev/sda5       484118528   500117503     7999488   82  Linux swap / Solaris
/dev/sda6       192399360   484118527   145859584   83  Linux

Partition table entries are not in disk order

Oryginalne pytanie:

Po aktualizacji do wersji 14.04 (od 13.04) na moim komputerze występują poważne spowolnienia, kiedy działając na górze zauważyłem, że kswap0 zajmuje dużo czasu procesora. Zauważyłem też, że nie mam miejsca na wymianę!

$ sudo swapon -a
swapon: /dev/mapper/cryptswap1: stat failed: No such file or directory

Wygląda na to, że jest jakiś problem z moją szyfrowaną konfiguracją wymiany (nawet nie wiedziałem, że ją mam)

$ cat /etc/crypttab 
cryptswap1 UUID=abe3c568-c8fd-4dfb-b8e9-0520d442dd61 /dev/urandom swap,cipher=aes-cbc-essiv:sha256

$ ls -l /dev/disk/by-uuid/
total 0
lrwxrwxrwx 1 root root 10 May  6 11:00 08b07f88-6da5-4b40-b062-42b3bb1c5f00 -> ../../sda3
lrwxrwxrwx 1 root root 10 May  6 11:00 19aa372c-05c8-4226-8f09-c54e5566e816 -> ../../sda6
lrwxrwxrwx 1 root root 10 May  6 11:00 A800B16E00B143DA -> ../../sda1
lrwxrwxrwx 1 root root 10 May  6 11:00 D28230E68230D129 -> ../../sda2

I patrząc na mój fstab

$ cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda6 during installation
UUID=19aa372c-05c8-4226-8f09-c54e5566e816 /               ext4    errors=remount-ro 0       1
# /boot was on /dev/sda3 during installation
UUID=08b07f88-6da5-4b40-b062-42b3bb1c5f00 /boot           ext2    defaults        0       2
# swap was on /dev/sda5 during installation
#UUID=abe3c568-c8fd-4dfb-b8e9-0520d442dd61 none            swap    sw              0       0
/dev/mapper/cryptswap1 none swap sw 0 0

Domyślam się, że jest coś nie tak w konfiguracji sda5, ale nie wiem, jak to naprawić, ponieważ jest skonfigurowany do szyfrowania. Byłbym wdzięczny za pomoc, jak postępować.

ajn
źródło
Nic nie wiem o zaszyfrowanych partycjach, ale ten pierwszy błąd sugeruje, że partycja wymiany nie została zamontowana. Komentowana jest również linia montażowa w pliku / etc / fstab. Spróbowałbym po prostu odkomentować tę linię i uruchomić ponownie, aby sprawdzić, czy to naprawia
Anake
Jestem całkiem pewien, że należy go skomentować, a linia cryptswap1 jest odpowiedzialna za zamontowanie go pośrednio przy użyciu informacji w / etc / crypttab. Twoja sugestia na pewno zamontowałaby go w sposób nieszyfrowany?
ajn
1
Czy to zadziała? https://ubuntuforums.org/showthread.php?t=2224129 Nie jestem pewien co do niektórych poleceń i nie chcę popsuć Ubuntu.
Wygląda podobnie do tego, czego próbowałem. Spodziewałbym się, że zadziała po jednym ponownym uruchomieniu, a potem przestanie działać po aktywacji zaszyfrowanej wymiany po raz pierwszy.
ajn
W tej chwili wróciłem do regularnej wymiany. Głównym scenariuszem, w którym używam szyfrowania jest to, że ktoś kradnie mój laptop, a ktoś z umiarkowanymi umiejętnościami w zakresie linuxa postanowił poszukać informacji, czy może znaleźć coś interesującego, tj. Najprawdopodobniej po prostu uruchomi się przy użyciu USB i zamontuje partycję domową. Nie mam nic, co uważam, że ktoś uznałby za wystarczająco wartościowe, aby spróbować odzyskać jego fragmenty z wymiany. Naprawdę powinna to być opcja instalacji, aby używać szyfrowanego domu + regularnej wymiany.
ajn

Odpowiedzi:

16

Znany błąd

Istnieje błąd (patrz poniżej), który zastępuje UUIDpartycję, gdy tylko dane zostaną do niej zapisane. Dlatego nie można użyć UUIDdo odwołania do partycji, która ma być używana do szyfrowanej wymiany.

Obecnie przestrzeń wymiany jest rzadko używana. Na mojej maszynie zamiana jest używana tylko wtedy, gdy otworzę 40 kartę. Gdy nie mam zamiany, nagle komputer zaczyna się opóźniać, a przeglądarka zamyka się. Lub w przypadku Chromiumprzeglądarki wiele kart nagle „umiera”.
Z tego powodu odwoływanie się /dev/disk/by-uuid/do twojego /etc/crypttabmoże wydawać się działać przez jakiś czas, ale gdy tylko przestrzeń wymiany zostanie faktycznie wykorzystana, zastąpi to, UUIDponieważ cała partycja jest używana do przechowywania zaszyfrowanych danych.

Łatwa naprawa

Łatwym rozwiązaniem jest odwołanie się do partycji wymiany według urządzenia w twoim /etc/crypttab, np .:

cryptswap1 /dev/sda5 /dev/urandom swap,cipher=aes-cbc-essiv:sha256

Ostrzeżenie: prawdopodobnie jest to bezpieczne na laptopie (używam go w ten sposób), ale jeśli jesteś na komputerze z wymiennymi dyskami lub masz inne powody, aby zmienić układ dysku / partycji, nie chcesz tego robić, ponieważ normalna partycja pamięci może nagle zostać użyta do wymiany.

Uwaga: Musisz zrestartować komputer, aby ta zmiana zaczęła obowiązywać, ponieważ tylko podczas rozruchu zostanie /dev/mapper/cryptswap1utworzony.

Prawidłowa naprawa

Właściwym sposobem na to jest upewnienie się, że część surowej partycji, która ją przechowuje, UUIDnie jest nadpisana przez zaszyfrowane dane wymiany, więc będzie ona nadal dostępna podczas ponownego uruchamiania. Nie jestem jednak pewien, gdzie UUIDjest zapisany i ile bajtów zajmuje. Możesz na własne ryzyko przetestować go w następujący sposób:

cryptswap1 UUID=abe3c568-c8fd-4dfb-b8e9-0520d442dd61 /dev/urandom swap,offset=36,cipher=aes-cbc-essiv:sha256

Uwaga offset=36.

Proszę, jeśli masz konto Ubuntu One, zaloguj się i przejdź do Bug # 1310058 na Launchpad i wybierz (lub kliknij tutaj): „Ten błąd też na mnie wpływa”, więc błąd zyska „popularność” i będzie bardziej podatny na naprawę.


Aktualizacja 27.10.2014

Natknąłem się na to. Nie zweryfikowany przeze mnie. Wygląda jak offsetsztuczka z większą szczegółowością i komentarzami na temat odbudowy zepsutej zamiany.

https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1310058/comments/22

Redsandro
źródło
5
Chcę tylko zauważyć, że błąd jest śledzony na stronie bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/953875 kilka dni temu (połowa marca 2015 r.) Status jest „naprawiony”, chociaż ta poprawka odnosi się tylko wyraźnie do 15.04. Szukam, czy jest to przeniesione do 14.04 LTS ... i jaka może być „oficjalna” procedura aktualizacji
Tommy Trussell
1
@TommyTrussell: Brak backportowania byłby szalony dla LTS. Błędy dotyczące takich kluczowych spraw, które wciąż są dostępne prawie rok po wydaniu, powodują, że nawet duże dystrybucje Linuksa nigdy nie będą na równi z OSX i Windows. Niestety.
Redsandro
Nie jestem świadomy publicznej dyskusji o błędach, ponieważ są one naprawiane w OSX i Windows, więc jak mogą być na równi? Z mojego doświadczenia z OSX, błędy są naprawiane lub nie; bez publicznej dyskusji, więc są „nieprzejrzyste”. Wspomniałem tylko o nowym numerze błędu (ponieważ ten, który podłączyłeś, został oznaczony jako duplikat), abyś mógł zaktualizować swoje referencje. Jak widać z dyskusji na forum, o której mowa w Bug 953875, najbardziej stabilna poprawka może się różnić w zależności od systemu init, który zmienia się w 15.04. W związku z tym poprawka 14.04 może wiązać się z problemami technicznymi związanymi z kompatybilnością do przodu.
Tommy Trussell
Mówię tylko, że nigdy nie zobaczysz czegoś takiego: „Och, przy okazji, SWAP jest zepsuty” w systemie takim jak Windows lub OSX. Jest to rodzaj podstawowej funkcjonalności, która nigdy nie uzyskałaby RTM przed przetestowaniem i naprawieniem. To wszystko. Jeśli chodzi o bezpieczeństwo, nie ma publicznych dyskusji, ale wciąż są statystyki .
Redsandro,
@ Redsandro Cóż, jest to darmowy system operacyjny i takie rzeczy zostaną naprawione przed wydaniem, jeśli ludzie wykryją błąd podczas testowania wydania. Po wydaniu jest zbyt ryzykowne, że usunięcie błędu spowoduje uszkodzenie innej konfiguracji. Można to jednak naprawić w nowszej wersji - warto więc z tego skorzystać - ale i tak wydania tymczasowe są zazwyczaj bardziej niestabilne niż wersje LTS, ponieważ bardziej skupiają się na aktualizacjach ogólnych. Ale ustaliłeś, dlaczego testowanie / naprawianie błędów / zapewnianie jakości (QA) jest tak ważne, a Ubuntu jest coraz lepszy.
Ads20000,
9

Miałem dokładnie ten sam problem w Ubuntu 14.04 i natknąłem się na ten wątek; ten link, który podał mutant, działał dobrze dla mnie. Użyłem /dev/disk/by-idreferencji zamiast / dev / sdXY, ponieważ referencja nie zawsze wskazuje na tę samą partycję fizyczną. Mój /etc/crypttabskończył jak:

cryptswap1 /dev/disk/by-id/wwn-0x500...-part6 /dev/urandom swap, cipher=aes-cbc-essiv:sha256
DoubleE
źródło
3
To jest właściwa i łatwa poprawka!
Serge Stroobandt
7

Wystarczy użyć nieszyfrowanej wymiany

... i szyfruj / home

Wypróbowałem kilka innych sugerowanych tutaj rozwiązań. Mimo że nadal pracowali po gorącym ponownym uruchomieniu, w końcu wszystkie zawiodły po wyłączeniu i zimnym ponownym uruchomieniu.

To mówi nam, że mamy do czynienia z podwójnym błędem:

  1. Identyfikator UUID dysku wymiany jest zastępowany przez system szyfrowania i
  2. Podczas uruchamiania występuje problem z przekroczeniem limitu czasu.

Te myśli znajdują również odzwierciedlenie w komentarzach do odpowiedniego błędu zgłoszonego na Launchpad . Jednak w związku z oczekującym przejściem z Upstart do systemd niewiele robi się, aby rozwiązać błąd w obecnych systemach LTS.

W tym momencie przyszło mi do głowy następujące myśli:

  1. Podczas instalacji systemu poprosiłem o szyfrowanie tylko mojej \homepartycji, nic więcej.
  2. Ryzyko związane z brakiem zaszyfrowanej partycji wymiany jest raczej ograniczone.
  3. Oczyszczanie ich działań należy do Canonical. Nie będę marnować na to więcej czasu.

Oto moje rozwiązanie, aby przywrócić zamianę jako normalną, niezaszyfrowaną zamianę bez konieczności ponownej instalacji całego systemu operacyjnego.

  1. Jeśli jeszcze tego nie zrobiłeś, zainstaluj blkid:$ sudo apt-get install blkid
  2. Edytuj /etc/crypttabi usuń całą cryptswap1linię:$ sudo nano /etc/crypttab
  3. Uruchom GParted z menu Ustawienia systemowe.
  4. Zobaczysz partycję z wykrzyknikiem. To powinna być wadliwa partycja wymiany. Ostrożnie wybierz go i sformatuj na linux-swappartycję. Po zastosowaniu tej operacji zostaniesz poinformowany o nowym UUID przywróconej normalnej partycji wymiany. Masz możliwość zapisania tych informacji. Jeśli nie, wiedz, że zawsze możesz pobrać nowy identyfikator UUID z wiersza polecenia za pomocą blkid:$ sudo blkid
  5. Czas przywrócić /etc/fstabdawną świetność:$ sudo nano /etc/fstab

    • Usuń całą linię zawierającą odniesienie do /dev/mapper/cryptswap1.
    • Odkomentuj starą swaplinię, usuwając hash #przed UUID=....
    • Teraz zastąp stary UUID nowym, uzyskanym wcześniej.
    • Zapisz plik, naciskając Ctrl+ O i wyjdź za nanopomocą Ctrl+ X.
  6. Po wykonaniu wszystkich tych czynności możesz już rozpocząć korzystanie z nowej niezaszyfrowanej swap z: $ sudo swapon -a
  7. To rozwiązanie przetrwa zarówno gorący restart, jak i zamknięcie z zimnym restartem.
Serge Stroobandt
źródło
1
To jedyna odpowiedź, która zadziałała dla mnie, chociaż próbowałem wszystkiego innego.
fifaltra
W gparted moja partycja wymiany ma flagę rozruchową. Czy to nadal będzie działać, czy nie będę mógł się uruchomić?
Christian Skjødt,
@ ChristianSkjødt Twoja partycja wymiany nie powinna mieć ustawionej flagi rozruchowej. W każdym razie powyższa procedura nie wpłynie na to.
Serge Stroobandt,
2

Spójrz na to . Rozwiązałem ten problem, po prostu zastępując UUID = ... przez / dev / sda3 w / etc / crypttab.

mutant
źródło
1
uruchom najpierw „sudo fdisk -l”, aby sprawdzić, jak nazywa się twoja partycja wymiany, może to być „/ etc / sda5” lub inna, a następnie edytuj cryptab zgodnie z opisem mutanta. To działało dla mnie i przetrwało restart. To zdecydowanie błąd, ponieważ dostałem ten problem ze świeżą instalacją na nowym dysku SSD. Po instalacji wybrałem opcję „szyfruj katalog domowy”, znacznie lepiej szyfrować / home po instalacji, szczególnie jeśli kopiujesz pliki ze starego / home z poprzedniej instalacji.
Paul Williams
sudo fdisk -lByło coś, nikt nie mówił. Dzięki za to! :)
Aman Alam
Powinieneś przynajmniej ostrzec ludzi, że /dev/sd*ścieżki mogą się zmieniać pod wpływem kaprysu i doprowadzić do zniszczenia niewłaściwej partycji przez zamianę danych. /dev/disk/by-idjest lepszy.
underscore_d
0

Mam ten problem, podobnie jak ludzie, o których mowa 332625 . Niektóre kombinacje zawieszenia i ponownego uruchomienia tracą identyfikator UUID partycji wymiany (jak mówi komentarz w pliku / etc / fstab , potwierdź to za pomocą sudo blkd), więc wiersz w pliku / etc / crypttab, aby użyć tego identyfikatora UUID, ponieważ szyfrowana zamiana kończy się niepowodzeniem.

Nie mam szczęścia, przełączając / etc / crypttab, aby użyć nazwy partycji /dev( / dev / sda6 w twoim przypadku) lub dev/disk/by-id/nazwy zamiast znikającego UUID.

Niestety, porzucenie szyfrowanej wymiany jest najłatwiejszym i jak dotąd najlepszym rozwiązaniem.

strona dla narciarzy
źródło
ten problem jest bardzo stary. Zastanawiam się, dlaczego go nie naprawili, teraz mam ten sam problem z komputerem i nie mogę go uruchomić, naprawiłem go na moim laptopie w przeszłości, ale nie pamiętam, jak :(
tomasb