☰

systemd가 "fstab"에 존재하지 않는 디스크를 기다리는 이유는 무엇입니까?

tag-icon • tag-icon boot systemd fstab uuid ecryptfs
systemd가 "fstab"에 존재하지 않는 디스크를 기다리는 이유는 무엇입니까?

내 시스템은 부팅하는 데 95초가 걸립니다. 실제로 부팅하는 데 5초, 존재하지 않는 드라이브를 기다리는 데 90초가 걸립니다.

(...boot.log...)
A start job is running for dev-disk-by\x2duuid-6bbb4ed8\x2d53ea\x2d4603\x2db4f7\x2d1205c7d24e19.device (1min 29s / 1min 30s)
Timed out waiting for device dev-disk-by\x2duuid-6bbb4ed8\x2d53ea\x2d4603\x2db4f7\x2d1205c7d24e19.device.

장치가 목록에 없고 fstab하드웨어(USB 디스크 등)도 찾을 수 없습니다. 어디서 왔으며 어떻게 비활성화합니까?

홈 디렉터리에 ecryptfs가 있고 SSD 디스크를 저장하기 위해 스왑을 수동으로 비활성화했습니다.

답변1

grep -r 6bbb4ed8 /etc장치에 대한 참조를 찾은 후 initrd( )를 다시 빌드하는 데 사용됩니다 mkinitrd.

답변2

이 파일은 암호화된 파일 시스템 관리 /etc/crypttab에 대응하는(잘 알려지지 않은) 파일 입니다. fstabUbuntu의 기본 설치에서는 암호화된 스왑 파일을 구성합니다.

cryptswap1 UUID=6bbb4ed8-53ea-4603-b4f7-1205c7d24e19 /dev/urandom swap,offset=1024,cipher=aes-xts-plain64

처음에는 이 스왑 파티션만 비활성화했습니다 fstab.아니요충분한.

/etc/crypttab그 목적과 내부 작동 방식에 대해 더 많이 아는 사람은 누구나 이 모호한 자체 답변을 확장하는 것을 환영합니다 .

답변3

제 경우에는 Dell Latitude 노트북에 부팅 SSD와 데이터 HDD가 함께 제공되었습니다. 데이터 HDD에 불량 섹터가 발생했기 때문에 결국 데이터를 백업하고 HDD를 물리적으로 제거했는데 다음에는 HDD가 누락되어 90인치 시간 초과가 발생했습니다. 부팅 .

grep -r /etcHauke의 제안에 따라 systemd가 찾고 있던 /etc/crypttabHDD UUID(per)에 해당하는 항목이 발견되었습니다./dev/disk/by-uuid

그런 다음 몇 년 전에 두 디스크 모두에 하나의 LUKS 암호를 입력할 수 있도록 이 줄을 추가한 것을 기억하고 HDD 암호 해독을 루트 파일 시스템의 키 파일로 지정합니다(부팅 시 LUKS 암호를 입력하면 암호가 해독 crypttab(5)됩니다 . 다중 디스크 단일 LUKS 비밀번호 설정에 관심이 있습니까?).

이 /etc/crypttab줄을 주석 처리하면 SSD의 빠른 부팅 속도가 복원되었습니다(감사합니다!).

관련 정보