lvmetad 때문에 우분투가 부팅되지 않습니다

Question 1

나는 오늘 Ubuntu 15.10을 실행하는 노트북에서 동일한 오류를 보았습니다. 항상 최신 상태를 유지했지만 현재 커널을 테스트하기 전까지(즉, 최근 변경이 있었을 수 있음) 한 달 동안 재부팅하지 않았습니다.

어쨌든, 제 경우에는 위의 튜토리얼을 따를 때 근본적인 원인이 실제로 설정 결함으로 인한 "누락" 스왑 파티션이라는 것을 발견했습니다. 이 경우 및/또는 실제로 를 사용하는 경우 lvm아래 2단계를 건너뛸 수 있습니다. 물론 시스템(또는 보조 데이터) 파티션이 손상되었거나 찾을 수 없는 경우 위의 오류 메시지가 표시될 수도 있습니다(3단계 참조).

1단계: 위에서 언급한 튜토리얼에 따라 시스템을 마운트하고 파티션을 부팅합니다.

(ext2) 부팅 파티션이 /dev/sdX1이고, (암호화된) 스왑 파티션이 /dev/sdX2이고, (암호화된) 데이터 파티션이 /dev/sdX3이고 를 사용하여 후자를 성공적으로 해독한 cryptsetup luksOpen /dev/sdX3 data다음 마운트했다고 가정해 보겠습니다. 그것: mkdir /tmp/data; mount /dev/mapper/data /tmp/data.

튜토리얼의 바인드 마운트에 주의를 기울이고 시스템 파티션의 /boot 디렉터리에서 액세스할 수 있도록 /dev/sdX1을 마운트했는지 확인하세요. (이는 실행해야 하므로 중요합니다 update-initramfs.)

chroot /tmp/data/@ubuntu1510다음에서는 (또는 마운트된 시스템 파티션이 무엇이든) 성공적으로 실행했다고 가정합니다.

2단계: 위의 오류 메시지 제거

저는 (언급된 하위 볼륨 이름에서 짐작할 수 있듯이) btrfs를 사용하고 있으므로 기능 손실 없이 다음과 같이 lvmetad를 쉽게 비활성화할 수 있습니다.

/etc/lvm/lvm.conf를 편집하고 use_lvmetad=1다음으로 변경합니다.use_lvmetad=0
실행하다update-initramfs -k $(uname -r) -u ; sync

이제 당신은~할 수 있었다재부팅하면 오류 메시지가 사라져야 합니다.하지만,내 경우에는 다음 오류 메시지[1]가 위에서 언급한 근본적인 문제를 지적해 주었기 때문에 그 문제를 해결하는 동안 ...

3단계: /etc/crypttab이 손상되지 않은 올바른 파티션을 가리키는지 확인하세요.

먼저, sfdisk --list /dev/sdX암호화된 스왑 파티션(제 경우에는 /dev/sdX2)이 실제로 암호화된 스왑 파티션을 실행하고 확인합니다.~ 아니다(일반) 스왑 파티션으로 표시됩니다. 만약 그렇다면(내 경우처럼) 이는 복구 디스크를 사용하여 부팅하면 사용 가능한 스왑 파티션을 활용하게 되어 cryptsetup 관련 메타데이터(키프레이즈 및 UUID)를 덮어쓰게 된다는 의미입니다.

다음으로, /dev/disk/by-uuid를 살펴보고 암호화된 파티션의 각 UUID를 /etc/crypttab에 포함된 UUID와 비교하십시오. 현재 내 추측은 다음과 같습니다. 귀하의 경우에는 불일치가 있습니다.

암호화된 전용 스왑 파티션이 /dev/disk/by-uuid 아래 어디에도 없다면 이는 현재 복구 시스템에서 사용 중이기 때문입니다. 이 경우 다음을 수행하십시오.

파티션 사용을 중지하십시오.swapoff -a
다시 포맷하세요: mkfs.ext2 /dev/sdX2(이것은중대한특히 GPT 파티션[2]을 사용하는 경우 앞서 언급한 결함을 취소할 수 있습니다. sfdisk 목록에 "swap" 유형으로 파티션이 나타나는 원인은 mkswap /dev/sdX2처음에 파티션을 설정할 때 귀하/내가 실수로 사용했기 때문일 수 있습니다.)
튜토리얼을 따라 파티션을 암호화하고 암호를 설정하세요. 그런 다음 cryptsetup을 사용하여 열고 올바르게 다시 포맷하세요.지금 해독됨파티션 (다음과 같은 것을 사용 mkswap /dev/mapper/swap)
스왑 파티션을 식별하지 않도록 하십시오 sfdisk --list /dev/sdX(이 경우 마지막 단계를 반복하십시오).

이제 /etc/crypttab에 나열된 UUID가 각각의 암호화된 파티션에 대해 /dev/disk/by-uuid 아래에 표시되는 것과 일치하는지 다시 확인하세요.

다시 한 번 변경 사항을 영구적으로 적용하려면 update-initramfs위에 표시된 대로 실행해야 합니다.

만족스러우면 모든 것이 디스크에 기록되었는지 확인하고 시스템을 재부팅하십시오(모든 것을 수동으로 마운트 해제할 필요는 없습니다). 그러면 문제가 사라질 것입니다.

[1] 처음에는 주의를 기울이지 않았거나 첫 번째 오류 메시지가 두 번째 메시지를 "가렸을" 수도 있습니다. 즉, (을 사용하여) 재부팅한 후에야 use_lvmetad=0"모든 물리적 볼륨을 읽습니다. 시간이 좀 걸릴 수 있습니다..."(여러 번 반복) 다음에 "알리다! /dev/disk/by-uuid/...가 존재하지 않습니다.update-initramfs". ( 파티션 누락에 대한 불만도 표시되어 있습니다 .)

[2] 해당 유형은 내용 분석에서 공제되고 궁극적으로 플래그/바이트로 지정되지 않기 때문입니다. 예를 들어 를 사용하여 GPT 파일 시스템 유형을 변경하는 등의 쉬운 방법이 없습니다 [g]parted.

Answer

나는 오늘 Ubuntu 15.10을 실행하는 노트북에서 동일한 오류를 보았습니다. 항상 최신 상태를 유지했지만 현재 커널을 테스트하기 전까지(즉, 최근 변경이 있었을 수 있음) 한 달 동안 재부팅하지 않았습니다.

어쨌든, 제 경우에는 위의 튜토리얼을 따를 때 근본적인 원인이 실제로 설정 결함으로 인한 "누락" 스왑 파티션이라는 것을 발견했습니다. 이 경우 및/또는 실제로 를 사용하는 경우 lvm아래 2단계를 건너뛸 수 있습니다. 물론 시스템(또는 보조 데이터) 파티션이 손상되었거나 찾을 수 없는 경우 위의 오류 메시지가 표시될 수도 있습니다(3단계 참조).

1단계: 위에서 언급한 튜토리얼에 따라 시스템을 마운트하고 파티션을 부팅합니다.

(ext2) 부팅 파티션이 /dev/sdX1이고, (암호화된) 스왑 파티션이 /dev/sdX2이고, (암호화된) 데이터 파티션이 /dev/sdX3이고 를 사용하여 후자를 성공적으로 해독한 cryptsetup luksOpen /dev/sdX3 data다음 마운트했다고 가정해 보겠습니다. 그것: mkdir /tmp/data; mount /dev/mapper/data /tmp/data.

튜토리얼의 바인드 마운트에 주의를 기울이고 시스템 파티션의 /boot 디렉터리에서 액세스할 수 있도록 /dev/sdX1을 마운트했는지 확인하세요. (이는 실행해야 하므로 중요합니다 update-initramfs.)

chroot /tmp/data/@ubuntu1510다음에서는 (또는 마운트된 시스템 파티션이 무엇이든) 성공적으로 실행했다고 가정합니다.

2단계: 위의 오류 메시지 제거

저는 (언급된 하위 볼륨 이름에서 짐작할 수 있듯이) btrfs를 사용하고 있으므로 기능 손실 없이 다음과 같이 lvmetad를 쉽게 비활성화할 수 있습니다.

/etc/lvm/lvm.conf를 편집하고 use_lvmetad=1다음으로 변경합니다.use_lvmetad=0
실행하다update-initramfs -k $(uname -r) -u ; sync

이제 당신은~할 수 있었다재부팅하면 오류 메시지가 사라져야 합니다.하지만,내 경우에는 다음 오류 메시지[1]가 위에서 언급한 근본적인 문제를 지적해 주었기 때문에 그 문제를 해결하는 동안 ...

3단계: /etc/crypttab이 손상되지 않은 올바른 파티션을 가리키는지 확인하세요.

먼저, sfdisk --list /dev/sdX암호화된 스왑 파티션(제 경우에는 /dev/sdX2)이 실제로 암호화된 스왑 파티션을 실행하고 확인합니다.~ 아니다(일반) 스왑 파티션으로 표시됩니다. 만약 그렇다면(내 경우처럼) 이는 복구 디스크를 사용하여 부팅하면 사용 가능한 스왑 파티션을 활용하게 되어 cryptsetup 관련 메타데이터(키프레이즈 및 UUID)를 덮어쓰게 된다는 의미입니다.

다음으로, /dev/disk/by-uuid를 살펴보고 암호화된 파티션의 각 UUID를 /etc/crypttab에 포함된 UUID와 비교하십시오. 현재 내 추측은 다음과 같습니다. 귀하의 경우에는 불일치가 있습니다.

암호화된 전용 스왑 파티션이 /dev/disk/by-uuid 아래 어디에도 없다면 이는 현재 복구 시스템에서 사용 중이기 때문입니다. 이 경우 다음을 수행하십시오.

파티션 사용을 중지하십시오.swapoff -a
다시 포맷하세요: mkfs.ext2 /dev/sdX2(이것은중대한특히 GPT 파티션[2]을 사용하는 경우 앞서 언급한 결함을 취소할 수 있습니다. sfdisk 목록에 "swap" 유형으로 파티션이 나타나는 원인은 mkswap /dev/sdX2처음에 파티션을 설정할 때 귀하/내가 실수로 사용했기 때문일 수 있습니다.)
튜토리얼을 따라 파티션을 암호화하고 암호를 설정하세요. 그런 다음 cryptsetup을 사용하여 열고 올바르게 다시 포맷하세요.지금 해독됨파티션 (다음과 같은 것을 사용 mkswap /dev/mapper/swap)
스왑 파티션을 식별하지 않도록 하십시오 sfdisk --list /dev/sdX(이 경우 마지막 단계를 반복하십시오).

이제 /etc/crypttab에 나열된 UUID가 각각의 암호화된 파티션에 대해 /dev/disk/by-uuid 아래에 표시되는 것과 일치하는지 다시 확인하세요.

다시 한 번 변경 사항을 영구적으로 적용하려면 update-initramfs위에 표시된 대로 실행해야 합니다.

만족스러우면 모든 것이 디스크에 기록되었는지 확인하고 시스템을 재부팅하십시오(모든 것을 수동으로 마운트 해제할 필요는 없습니다). 그러면 문제가 사라질 것입니다.

[1] 처음에는 주의를 기울이지 않았거나 첫 번째 오류 메시지가 두 번째 메시지를 "가렸을" 수도 있습니다. 즉, (을 사용하여) 재부팅한 후에야 use_lvmetad=0"모든 물리적 볼륨을 읽습니다. 시간이 좀 걸릴 수 있습니다..."(여러 번 반복) 다음에 "알리다! /dev/disk/by-uuid/...가 존재하지 않습니다.update-initramfs". ( 파티션 누락에 대한 불만도 표시되어 있습니다 .)

[2] 해당 유형은 내용 분석에서 공제되고 궁극적으로 플래그/바이트로 지정되지 않기 때문입니다. 예를 들어 를 사용하여 GPT 파일 시스템 유형을 변경하는 등의 쉬운 방법이 없습니다 [g]parted.

Question 2

오류Failed to connect to lvmetad~할 수 있다디스크가 100% 꽉 차서 발생합니다. 이 문제를 해결하려면 USB 썸 드라이브에서 부팅하고 전체 디스크를 마운트한 후 불필요한 파일을 삭제하고 재부팅하세요. 부팅 시스템도 다시 설치했는데 필요한지 아닌지는 모르겠습니다.

이것은 USB 드라이브에서 부팅한 후 터미널에서 실행하여 문제를 해결한 명령입니다. 전체 드라이브 암호화 기능을 갖춘 Ubuntu 18.04 재고가 있습니다. YMMV.

드라이브를 마운트합니다:

sudo cryptsetup luksOpen /dev/sda5 sda5_crypt
sudo vgscan --mknodes
sudo vgchange -ay
sudo mount /dev/mapper/ubuntu--vg-root /mnt

불필요한 파일 삭제( cd /mnt/home/your_username... rm ...)

(필요하지 않을 수도 있음) 부팅 시스템을 다시 설치하십시오.

cd /mnt/
sudo mount /dev/sda1 boot
for d in dev sys proc run; do sudo mount --bind /$d $d; done
sudo vi etc/crypttab # make sure first line uses "sda5_crypt"
sudo chroot .
update-grub
grub-install /dev/sda
update-initramfs -u -k all
exit
sudo umount dev sys proc run boot

마운트 해제:

cd /
sudo umount /mnt
sudo vgchange -an
sudo cryptsetup close sda5_crypt

재부팅:
```
sudo reboot
```

Answer

오류Failed to connect to lvmetad~할 수 있다디스크가 100% 꽉 차서 발생합니다. 이 문제를 해결하려면 USB 썸 드라이브에서 부팅하고 전체 디스크를 마운트한 후 불필요한 파일을 삭제하고 재부팅하세요. 부팅 시스템도 다시 설치했는데 필요한지 아닌지는 모르겠습니다.

이것은 USB 드라이브에서 부팅한 후 터미널에서 실행하여 문제를 해결한 명령입니다. 전체 드라이브 암호화 기능을 갖춘 Ubuntu 18.04 재고가 있습니다. YMMV.

드라이브를 마운트합니다:

sudo cryptsetup luksOpen /dev/sda5 sda5_crypt
sudo vgscan --mknodes
sudo vgchange -ay
sudo mount /dev/mapper/ubuntu--vg-root /mnt

불필요한 파일 삭제( cd /mnt/home/your_username... rm ...)

(필요하지 않을 수도 있음) 부팅 시스템을 다시 설치하십시오.

cd /mnt/
sudo mount /dev/sda1 boot
for d in dev sys proc run; do sudo mount --bind /$d $d; done
sudo vi etc/crypttab # make sure first line uses "sda5_crypt"
sudo chroot .
update-grub
grub-install /dev/sda
update-initramfs -u -k all
exit
sudo umount dev sys proc run boot

마운트 해제:

cd /
sudo umount /mnt
sudo vgchange -an
sudo cryptsetup close sda5_crypt

재부팅:
```
sudo reboot
```

Question 3

우분투 18.04.1 LTS는 여기에 있습니다. 몇 달 동안 무인 상태로 실행되었지만 다시 돌아왔을 때 키보드가 인식되지 않는 것을 발견했습니다. 재부팅했을 때 'lvmetad에 연결할 수 없습니다' 메시지와 "UEFI db 목록"을 가져올 수 없다는 자세한 내용이 표시되었습니다.

디스크 암호화 없이 설치했습니다.

UEFI 메시지는 걱정스러웠습니다. UEFI 컴퓨터에 처음 설치했기 때문에 경험이 없었고 솔직히 아직 유용성에 대해서도 잘 알지 못했습니다. 내 문제는 내가 '/', 루트, 볼륨이 될 항목에 'lvm'을 사용했다는 사실로 인해 더욱 복잡해졌습니다. (사실 저는 제가 처음에 그걸 어떻게 성취했는지 이미 잊어버렸어요! 안녕하세요. 저는 늙었어요.)

그러나 컴퓨터가 재부팅되지 않을 때 해결책을 검색했지만 확실한 것을 찾지 못했지만 a) 내 EFI 파티션이 한 사이트에서 권장하는 500MB보다 작고 b) 내가 준비한 별도의 /boot/ 파티션을 발견했습니다. for는 아마도 관련이 없고 사용되지 않았을 것입니다. 아마도 무인 업그레이드로 인해 할당된 공간이 꽉 찼을 가능성이 있다고 생각했습니다.

나는 다시 설치하기로 결정했습니다. 결과는 좋았고 /home/ 디렉토리 구조는 방해받지 않았습니다. 나는 /etc/를 확인하지 않았지만, 둘 다 미리 복사해 두었으므로[1] 나중에 확인할 수 있습니다. /etc/는 정말 작습니다.

또한 삭제하고 EFI 및 /boot/용 파티션을 하나의 더 큰 EFI 파티션(>750MB)으로 결합했습니다.

이제 재부팅되지만 단일 오류 메시지가 너무 빨리 깜박여서 읽을 수 없으며 부팅할 Linux 이미지의 부팅 '메뉴'가 제공되지 않고 대신 Ubuntu로 직접 부팅됩니다. 이 문제를 해결하려면 grub을 사용하여 아직 해야 할 일이 더 많이 남아 있습니다. 하지만 적어도 내 파일은 돌아왔습니다.

[1] USB 스틱에서 Ubuntu 설치를 부팅하고 Ubuntu를 "시도"하기로 선택했습니다. 이를 통해 데스크탑에서 "설치"를 선택하기 전에 etc 및 홈의 복사본을 만들 수 있었습니다.

Answer