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

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ć.

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

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

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.

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

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.