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ć.
Odpowiedzi:
Znany błąd
Istnieje błąd (patrz poniżej), który zastępuje
UUID
partycję, gdy tylko dane zostaną do niej zapisane. Dlatego nie można użyćUUID
do 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
Chromium
przeglądarki wiele kart nagle „umiera”.Z tego powodu odwoływanie się
/dev/disk/by-uuid/
do twojego/etc/crypttab
może wydawać się działać przez jakiś czas, ale gdy tylko przestrzeń wymiany zostanie faktycznie wykorzystana, zastąpi to,UUID
ponieważ 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 .: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/cryptswap1
utworzony.Prawidłowa naprawa
Właściwym sposobem na to jest upewnienie się, że część surowej partycji, która ją przechowuje,
UUID
nie jest nadpisana przez zaszyfrowane dane wymiany, więc będzie ona nadal dostępna podczas ponownego uruchamiania. Nie jestem jednak pewien, gdzieUUID
jest zapisany i ile bajtów zajmuje. Możesz na własne ryzyko przetestować go w następujący sposób: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
offset
sztuczka 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
źródło
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-id
referencji zamiast / dev / sdXY, ponieważ referencja nie zawsze wskazuje na tę samą partycję fizyczną. Mój/etc/crypttab
skończył jak:źródło
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:
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:
\home
partycji, nic więcej.Oto moje rozwiązanie, aby przywrócić zamianę jako normalną, niezaszyfrowaną zamianę bez konieczności ponownej instalacji całego systemu operacyjnego.
blkid
:$ sudo apt-get install blkid
/etc/crypttab
i usuń całącryptswap1
linię:$ sudo nano /etc/crypttab
linux-swap
partycję. 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
Czas przywrócić
/etc/fstab
dawną świetność:$ sudo nano /etc/fstab
/dev/mapper/cryptswap1
.swap
linię, usuwając hash#
przedUUID=...
.nano
pomocą Ctrl+ X.$ sudo swapon -a
źródło
Spójrz na to . Rozwiązałem ten problem, po prostu zastępując UUID = ... przez / dev / sda3 w / etc / crypttab.
źródło
sudo fdisk -l
Było coś, nikt nie mówił. Dzięki za to! :)/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-id
jest lepszy.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) lubdev/disk/by-id/
nazwy zamiast znikającego UUID.Niestety, porzucenie szyfrowanej wymiany jest najłatwiejszym i jak dotąd najlepszym rozwiązaniem.
źródło