Hoán đổi không hoạt động trên cài đặt sạch 14.04 bằng cách sử dụng nhà được mã hóa


28

Cập nhật 3:

Tôi quyết định cài đặt lại hệ thống từ đầu để loại bỏ bất kỳ hành trình cũ nào xung quanh vì tôi đã gặp một số vấn đề khác sau khi nâng cấp. Tuy nhiên, vấn đề này vẫn tồn tại.

Khi cài đặt sạch, việc chọn cài đặt bằng "nhà được mã hóa" dẫn đến cấu hình hoán đổi được mã hóa bị hỏng.

Cập nhật 2:

Tôi đã sửa lỗi thứ tự chia tay mà cfdisk phàn nàn, nhưng anh ta vẫn tồn tại. Việc hoán đổi bây giờ là trên / dev / sda6 và tôi có thể tải nó lên và chạy như sau:

~$ 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

Nhưng sau khi trao đổi khởi động lại không kích hoạt và nó một lần nữa trông như thế này:

$ 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

Tôi đoán tại thời điểm này là khi thiết lập đĩa là mã hóa linux không còn nhận ra loại phân vùng và do đó không tải đúng cách khiến nó không đăng ký được UUID và do đó cryptswap không thể tìm thấy nó gây ra lỗi. Nhưng tôi không biết làm thế nào để sửa nó ..

Câu hỏi cập nhật:

Thử nghiệm thêm cho thấy rằng tôi có thể nâng cấp và chạy bằng cách chạy $ mkswap / dev / sda5

và sau đó cập nhật / etc / crypttab với UUID chính xác và làm theo các bước được nêu ở đây: Làm cách nào để thiết lập tệp hoán đổi được mã hóa?

Tuy nhiên, sự cố vẫn còn khi tôi khởi động lại máy tính, / dev / sda5 không xuất hiện khi tôi chạy

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

Nếu tôi làm:

$ cfdisk /dev/sda 

Tôi nhận được lỗi sau đây:

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

Tiện ích "Đĩa" đồ họa không phàn nàn về bất kỳ lỗi nào khi mở đĩa bằng cách sử dụng nó.

$ 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

Câu hỏi gốc:

Sau khi nâng cấp lên 14.04 (từ 13.04), máy tính của tôi đã gặp sự cố chậm nghiêm trọng, khi chạy top tôi nhận thấy kswap0 chiếm rất nhiều thời gian của cpu. Tôi cũng nhận thấy rằng tôi không có bất kỳ không gian trao đổi!

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

Dường như có một số vấn đề với thiết lập trao đổi được mã hóa của tôi (thậm chí không biết rằng tôi đã có một)

$ 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

Và nhìn vào fstab của tôi

$ 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

Tôi đoán là có lỗi gì đó khi cài đặt sda5, nhưng tôi không biết cách khắc phục vì nó được thiết lập để được mã hóa. Sẽ đánh giá cao một số trợ giúp như làm thế nào để tiến hành.


Tôi không biết gì về các phân vùng được mã hóa, nhưng lỗi đầu tiên cho thấy phân vùng trao đổi đã không được gắn kết. Ngoài ra, đường lắp cho nó trong / etc / fstab được nhận xét. Tôi sẽ cố gắng bỏ ghi chú dòng đó và khởi động lại để kiểm tra xem nó có khắc phục được không
Anake

Tôi khá chắc chắn rằng nó đáng lẽ phải được bình luận và dòng cryptswap1 chịu trách nhiệm gắn kết nó một cách gián tiếp bằng cách sử dụng thông tin trong / etc / crypttab. Đề xuất của bạn chắc chắn sẽ gắn kết nó trong một thời gian không được mã hóa?
ajn

1
Điều này sẽ làm việc? https://ubuntuforums.org/showthread.php?t=2224129 Tôi không chắc chắn về một số lệnh và tôi không muốn làm hỏng Ubuntu.

Nó trông giống với những gì tôi đã thử, tôi hy vọng nó sẽ hoạt động cho một lần khởi động lại sau đó ngừng hoạt động trở lại sau khi bạn kích hoạt trao đổi được mã hóa lần đầu tiên.
ajn

Hiện tại tôi vừa quay lại sử dụng trao đổi thông thường. Kịch bản chính tôi đang sử dụng mã hóa là nếu ai đó đánh cắp máy tính xách tay của tôi và ai đó có kỹ năng linux vừa phải quyết định chọc ngoáy để xem họ có thể tìm thấy thứ gì đó thú vị hay không, nghĩa là rất có thể chỉ cần thử khởi động bằng usb và gắn kết phân vùng nhà của tôi. Tôi không có bất cứ điều gì mà tôi tin rằng ai đó sẽ thấy đủ giá trị để cố gắng bắt đầu khôi phục các mảnh của nó từ trao đổi. Nó thực sự nên là một tùy chọn cài đặt để sử dụng nhà được mã hóa + trao đổi thường xuyên.
ajn

Câu trả lời:


16

Lỗi đã biết

Có một lỗi (xem bên dưới) ghi đè lên UUIDphân vùng ngay khi dữ liệu được ghi vào nó. Do đó, bạn không thể sử dụng UUIDtham chiếu phân vùng để sử dụng cho trao đổi được mã hóa.

Ngày nay, không gian hoán đổi hầu như không bao giờ được sử dụng. Trên máy của tôi, trao đổi chỉ được sử dụng khi tôi mở tab thứ 40 của mình. Khi tôi không có trao đổi, đột nhiên máy tính của tôi bắt đầu bị lag và trình duyệt tự đóng lại. Hoặc trong trường hợp Chromiumtrình duyệt, rất nhiều tab sẽ đột nhiên 'chết'.
Vì lý do này, tham khảo /dev/disk/by-uuid/trong bạn /etc/crypttabsức mạnh dường như được làm việc trong một thời gian, nhưng ngay sau khi hoán đổi của bạn là thực sự được sử dụng, nó sẽ ghi đè lên UUIDbởi vì toàn bộ phân vùng được sử dụng để lưu trữ dữ liệu được mã hóa.

Dễ dàng sửa chữa

Cách khắc phục dễ dàng là tham chiếu phân vùng trao đổi theo thiết bị trong của bạn /etc/crypttab, ví dụ:

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

Cảnh báo: điều này có thể an toàn trên máy tính xách tay (tôi sử dụng nó như thế này), nhưng nếu bạn đang ở trên máy tính để bàn có ổ đĩa có thể tráo đổi hoặc có lý do khác để thay đổi bố cục ổ đĩa / phân vùng, bạn không muốn làm điều này, như một phân vùng lưu trữ bình thường có thể đột nhiên được sử dụng để trao đổi.

Lưu ý: Bạn cần khởi động lại để thay đổi này có hiệu lực, vì chỉ khi khởi động mới /dev/mapper/cryptswap1được tạo.

Sửa chữa đúng cách

Cách thích hợp để khắc phục điều này là đảm bảo một phần của phân vùng thô lưu trữ UUIDkhông bị ghi đè bởi dữ liệu trao đổi được mã hóa, vì vậy nó sẽ vẫn ở đó khi khởi động lại. Tuy nhiên, tôi không chắc UUIDnó được viết ở đâu và nó chiếm bao nhiêu byte. Bạn có thể, tự chịu rủi ro, kiểm tra nó như vậy:

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

Lưu ý offset=36.

Vui lòng nếu bạn đã đăng nhập tài khoản Ubuntu One và truy cập Bug # 1310058 trên Launchpad và chọn (hoặc nhấp vào đây): "Lỗi này cũng ảnh hưởng đến tôi" vì vậy lỗi sẽ trở nên 'phổ biến' và dễ bị sửa hơn.


Cập nhật 2014-10-27

Tôi cũng vấp phải điều này. Không được xác minh bởi tôi. Nó trông giống như offsetmánh khóe với nhiều lời nói và ý kiến ​​về việc xây dựng lại một trao đổi bị hỏng.

https://bugs.launchpad.net/ubfox/+source/ecryptfs-utils/+orms/1310058/comments/22


5
Tôi chỉ muốn lưu ý rằng lỗi đang được theo dõi tại bug.launchpad.net/ubfox/+source/ecryptfs-utils/+orms/953875 kể từ vài ngày trước (giữa tháng 3 năm 2015), trạng thái được "phát hành cố định" sửa chữa đó chỉ áp dụng rõ ràng cho 15.04. Tôi đang tìm hiểu xem liệu nó có được nhập vào 14.04 LTS không ... và quy trình cập nhật "chính thức" có thể là gì
Tommy Trussell

1
@TommyTrussell: Không backporting sẽ là điên rồ đối với LTS. Lỗi cho những thứ quan trọng như thế này vẫn mở gần một năm sau khi phát hành là lý do tại sao ngay cả các bản phân phối Linux lớn sẽ không bao giờ ngang hàng với OSX và Windows. Không may.
Redsandro 14/03/2015

Tôi không biết về các cuộc thảo luận công khai về các lỗi vì chúng đang được sửa trong OSX và Windows, vậy làm thế nào chúng có thể "ngang bằng"? Theo kinh nghiệm của tôi với OSX, các lỗi có được sửa hay không; không thảo luận công khai, vì vậy họ "mờ đục". Tôi chỉ đề cập đến số lỗi mới (vì số bạn đã liên kết đã được đánh dấu trùng lặp) để bạn có thể cập nhật tham chiếu của mình. Như bạn có thể thấy từ cuộc thảo luận tại bài đăng diễn đàn được đề cập trong Bug 953875, cách khắc phục ổn định nhất có thể khác nhau tùy thuộc vào hệ thống init, thay đổi trong 15.04. Vì vậy, bản sửa lỗi 14.04 có thể có những thách thức kỹ thuật để tương thích về phía trước.
Tommy Trussell

Tôi chỉ nói rằng bạn sẽ không bao giờ thấy một cái gì đó như "Ồ nhân tiện, SWAP bị hỏng" trên một hệ thống như Windows hoặc OSX. Đây là loại chức năng cốt lõi sẽ không bao giờ có được RTM trước khi được kiểm tra và sửa chữa. Đó là tất cả. Về bảo mật, không có thảo luận công khai nhưng vẫn có số liệu thống kê .
Redsandro

@Redsandro Vâng, đó là một hệ điều hành miễn phí và những thứ như thế này sẽ chỉ được sửa trước khi phát hành nếu mọi người phát hiện ra lỗi khi kiểm tra bản phát hành. Sau khi phát hành, thật quá rủi ro khi thực hiện sửa lỗi sẽ phá vỡ thứ khác trên cấu hình của ai đó. Tuy nhiên, nó có thể được sửa trong một bản phát hành gần đây hơn - vì vậy nó có thể đáng để sử dụng - nhưng bản phát hành tạm thời thường không ổn định hơn bản phát hành LTS vì dù sao tập trung vào các bản cập nhật chung. Nhưng bạn đã xác định được tại sao kiểm tra lỗi / sửa lỗi / Đảm bảo chất lượng (QA) lại quan trọng và Ubuntu đang trở nên tốt hơn ở đó.
Ads20000

9

Tôi đã gặp vấn đề chính xác tương tự trong Ubuntu 14.04 và đã gặp chủ đề này; liên kết này mà người đột biến cung cấp đã làm việc tốt cho tôi. Tôi đã sử dụng /dev/disk/by-idtham chiếu chứ không phải / dev / sdXY, vì tham chiếu đó không phải lúc nào cũng trỏ đến cùng một phân vùng vật lý. Tôi /etc/crypttabđã kết thúc như:

cryptswap1 /dev/disk/by-id/wwn-0x500...-part6 /dev/urandom swap, cipher=aes-cbc-essiv:sha256

3
Đây là sửa chữa thích hợpdễ dàng !
Serge Stroobandt

7

Chỉ cần sử dụng một trao đổi không được mã hóa

... và giữ / mã hóa nhà

Tôi đã thử một vài giải pháp khác được đề xuất ở đây. Mặc dù họ tiếp tục làm việc sau khi khởi động lại nóng, cuối cùng tất cả đều thất bại sau khi tắt máy và khởi động lại lạnh.

Điều này cho chúng ta biết chúng ta thực sự đang đối phó với một lỗi kép:

  1. UUID của ổ đĩa trao đổi bị hệ thống mã hóa ghi đè và
  2. Có một vấn đề thời gian chờ trong quá trình khởi động.

Những suy nghĩ này cũng được phản ánh trong các bình luận về lỗi liên quan được nộp tại Launchpad . Tuy nhiên, với việc chuyển từ trạng thái chờ xử lý từ Upstart sang systemd, rất ít việc được thực hiện để khắc phục lỗi trên các hệ thống LTS hiện tại.

Tại thời điểm này, những suy nghĩ sau đây xuất hiện trong tâm trí của tôi:

  1. Trong quá trình cài đặt hệ thống, tôi yêu cầu chỉ mã hóa \homephân vùng của mình , không có gì khác.
  2. Những rủi ro liên quan đến việc không có phân vùng trao đổi được mã hóa là khá hạn chế.
  3. Tùy thuộc vào Canonical để làm sạch hành động của họ. Tôi sẽ không lãng phí thời gian với điều này.

Vì vậy, đây là giải pháp của tôi để khôi phục trao đổi như một trao đổi bình thường, không được mã hóa mà không phải cài đặt lại toàn bộ hệ điều hành.

  1. Nếu bạn chưa làm như vậy, cài đặt blkid:$ sudo apt-get install blkid
  2. Chỉnh sửa /etc/crypttabvà xóa toàn bộ cryptswap1dòng:$ sudo nano /etc/crypttab
  3. Bắt đầu GParted từ menu Cài đặt hệ thống.
  4. Bạn sẽ thấy một phân vùng có dấu chấm than. Đây phải là phân vùng trao đổi bị lỗi. Cẩn thận chọn nó và định dạng lại nó vào một linux-swapphân vùng. Sau khi áp dụng thao tác này, bạn được thông báo về UUID mới của phân vùng trao đổi bình thường được khôi phục. Bạn được cung cấp một cơ hội để lưu thông tin này. Nếu bạn không, hãy biết rằng bạn luôn có thể truy xuất UUID mới từ dòng lệnh với blkid:$ sudo blkid
  5. Bây giờ, đã đến lúc khôi phục lại /etc/fstabvinh quang cũ của nó:$ sudo nano /etc/fstab

    • Xóa toàn bộ dòng chứa tham chiếu đến /dev/mapper/cryptswap1.
    • Bỏ ghi chú swapdòng cũ bằng cách loại bỏ hàm băm #trước mặt UUID=....
    • Bây giờ, thay thế UUID cũ bằng UUID mới thu được trước đó.
    • Viết tệp ra bằng cách nhấn Ctrl+ O và thoát nanobằng Ctrl+ X.
  6. Sau khi thực hiện tất cả điều đó, bạn đã có thể bắt đầu sử dụng trao đổi không được mã hóa mới với: $ sudo swapon -a
  7. Giải pháp này tồn tại cả khởi động lại nóng và tắt máy với khởi động lại lạnh.

1
Đây là câu trả lời duy nhất có hiệu quả với tôi, mặc dù tôi đã thử mọi cách khác.
fifaltra

Trong gparted phân vùng trao đổi của tôi có cờ khởi động. Điều này sẽ vẫn hoạt động, hoặc tôi sẽ không thể khởi động?
Christian Skjødt

@ ChristianSkjødt Phân vùng trao đổi của bạn không nên đặt cờ khởi động. Nhưng dù sao, thủ tục trên sẽ không ảnh hưởng đến bất kỳ điều đó.
Serge Stroobandt

2

Có một cái nhìn về điều này . Tôi đã khắc phục sự cố này bằng cách thay thế UUID = ... bằng / dev / sda3 trong / etc / crypttab.


1
trước tiên hãy chạy "sudo fdisk -l" để kiểm tra phân vùng trao đổi của bạn được gọi là gì, nó có thể là "/ etc / sda5" hoặc khác, sau đó chỉnh sửa cryptab như được mô tả bởi mutant. Điều này làm việc cho tôi và sống sót khi khởi động lại. Đây chắc chắn là một lỗi khi tôi gặp vấn đề này với cài đặt mới trên ổ SSD mới. Tôi đã sử dụng tùy chọn "mã hóa thư mục chính" khi cài đặt, tốt hơn nhiều là mã hóa / home sau khi cài đặt, đặc biệt nếu bạn đang sao chép các tập tin từ một bản cũ / home từ bản cài đặt trước.
Paul Williams

Đó sudo fdisk -llà điều mà không ai nói ra. Cảm ơn vì điều đó! :)
Aman Alam

Ít nhất bạn nên cảnh báo mọi người rằng /dev/sd*các đường dẫn có thể thay đổi bất chợt và dẫn đến phân vùng sai bị phá hủy bởi dữ liệu trao đổi. /dev/disk/by-idlà vượt trội.
gạch dưới

0

Tôi có vấn đề này, cũng như những người trong câu hỏi 332625 . Một số kết hợp đình chỉ và khởi động lại làm mất UUID của phân vùng trao đổi của bạn (như nhận xét trong / etc / fstab của bạn nói, xác nhận điều này với sudo blkd), do đó, dòng trong / etc / crypttab của bạn sử dụng UUID đó khi hoán đổi được mã hóa không thành công.

Tôi không có may mắn chuyển đổi / etc / crypttab để sử dụng /devtên của phân vùng ( / dev / sda6 trong trường hợp của bạn) hoặc dev/disk/by-id/tên thay vì UUID biến mất.

Từ bỏ trao đổi mã hóa là giải pháp dễ dàng nhất và tốt nhất cho đến nay, đáng buồn thay.


vấn đề này rất cũ tôi tự hỏi tại sao họ chưa sửa nó, bây giờ tôi đang gặp vấn đề tương tự với máy tính để bàn của tôi và không thể chạy nó, đã sửa nó trên máy tính xách tay của tôi trước đây nhưng không thể nhớ như thế nào :(
tomasb
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.