시작 시 UUID 시작 작업으로 인해 시스템이 90초 동안 정지됩니다. 이것은 다음에서 답변되었습니다.아쿠분투. 솔루션에는 /etc/fstab
.
그런데 제 경우에는 cat /etc/fstab
문제의 UUID가 기재되어 있지도 않고, 기재되어 있지도 않았습니다 blkid
.
다음은 중단의 스크린샷입니다.
fstab
그리고 터미널 blkid
.
$ 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>
PARTUUID=83e38dbb-a281-4157-9ae8-06361a40475b /boot/efi vfat umask=0077 0 0
PARTUUID=ab479d41-e3b9-46aa-9f1d-2a8c442b0dac /recovery vfat umask=0077 0 0
UUID=89a5c36c-2f93-4723-a1fe-f7791802190d / ext4 noatime,errors=remount-ro 0 0
/dev/disk/by-uuid/ef824484-7f7c-464b-83ac-71298f8631b9 /mnt/2tb_slow auto nosuid,nodev,nofail,x-gvfs-show,x-gvfs-name=2tb%20slow 0 0
/dev/disk/by-uuid/166f7ef4-e8e5-496a-8f69-6e7b65fdb5aa /mnt/120gb_fast auto nosuid,nodev,nofail,x-gvfs-show,x-gvfs-name=120GB%20fast 0 0
/dev/disk/by-uuid/3bdf3b47-1078-432d-9633-987de4291e60 /mnt/4tb_slow auto nosuid,nodev,nofail,x-gvfs-show,x-gvfs-name=4tb_slow 0 0
/dev/disk/by-id/wwn-0x5000cca371e75713-part1 /mnt/320gb_slow auto nosuid,nodev,nofail,x-gvfs-show,x-gvfs-name=320gb_slow 0 0
/swapfile none swap sw 0 0
/dev/disk/by-id/wwn-0x5000cca726c633e8-part1 /mnt/500gb_slow auto nosuid,nodev,nofail,x-gvfs-show 0 0
/dev/disk/by-id/wwn-0x5000c5004ae4aa2c-part1 /mnt/1TB_slow auto nosuid,nodev,nofail,x-gvfs-show 0 0
$ sudo blkid
/dev/nvme0n1p3: UUID="89a5c36c-2f93-4723-a1fe-f7791802190d" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="26fad6b9-31ed-4039-8918-c26777f7401b"
/dev/loop0: TYPE="squashfs"
/dev/loop1: TYPE="squashfs"
/dev/loop2: TYPE="squashfs"
/dev/loop3: TYPE="squashfs"
/dev/loop4: TYPE="squashfs"
/dev/loop5: TYPE="squashfs"
/dev/loop6: TYPE="squashfs"
/dev/loop7: TYPE="squashfs"
/dev/nvme0n1p1: UUID="1483-0D53" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="83e38dbb-a281-4157-9ae8-06361a40475b"
/dev/nvme0n1p2: UUID="1482-F2BD" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="recovery" PARTUUID="ab479d41-e3b9-46aa-9f1d-2a8c442b0dac"
/dev/sda: LABEL="4tb_slow" UUID="3bdf3b47-1078-432d-9633-987de4291e60" BLOCK_SIZE="4096" TYPE="ext4"
/dev/sdb: LABEL="brain" UUID="ef824484-7f7c-464b-83ac-71298f8631b9" BLOCK_SIZE="4096" TYPE="ext4"
/dev/sdc1: LABEL_FATBOOT="EFI" LABEL="EFI" UUID="67E3-17ED" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="11005b63-b700-4c10-b836-ab0142703c64"
/dev/sdc2: UUID="b52766bf-5bf0-303d-9c85-0e9115322d95" BLOCK_SIZE="4096" LABEL="WININSTALL" TYPE="hfsplus" PARTLABEL="WININSTALL" PARTUUID="ffa5f15c-fb1d-4822-a3ad-122b6b3fe019"
/dev/sdd1: BLOCK_SIZE="2048" UUID="2021-02-09-19-06-26-00" LABEL="Ubuntu 20.04.2.0 LTS amd64" TYPE="iso9660" PTUUID="38b1c112" PTTYPE="dos" PARTUUID="38b1c112-01"
/dev/sdd2: SEC_TYPE="msdos" UUID="54C5-9C6C" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="38b1c112-02"
/dev/sde1: LABEL="backup320" UUID="88607df4-477e-4ecf-b02b-06760ace6e24" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="000aff57-01"
/dev/sdg1: LABEL="500 GB slow" UUID="8e86976e-059c-44c8-8fe0-f3480530161b" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="df86a2f1-5804-4515-a091-c55d0fe630ce"
/dev/sdf1: LABEL="storage" UUID="f5d68032-eae7-404c-9762-19962f97261c" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="51bb1bd8-01"
/dev/loop8: TYPE="squashfs"
/dev/loop9: TYPE="squashfs"
/dev/loop10: TYPE="squashfs"
/dev/loop11: TYPE="squashfs"
/dev/loop12: TYPE="squashfs"
/dev/loop13: TYPE="squashfs"
/dev/loop14: TYPE="squashfs"
/dev/loop15: TYPE="squashfs"
/dev/loop16: TYPE="squashfs"
운영 체제: Pop 20.10 groovy 커널: x86_64 Linux 5.11.0-7614-generic
답변1
이 /etc/fstab
줄은 첫 번째 그림에서 보류 중인 파일 시스템의 UUID와 일치합니다.
/dev/disk/by-uuid/166f7ef4-e8e5-496a-8f69-6e7b65fdb5aa /mnt/120gb_fast auto nosuid,nodev,nofail,x-gvfs-show,x-gvfs-name=120GB%20fast 0 0
두 번째 사진에는 UUID가 마운트되어 있는데, 내가 아는 한 c04ab358-de52-4c2d-9291-3a140d74b252
이것은 어디에도 언급되지 않았습니다. 출력에도 언급 /etc/fstab
되지 않았으므로 어떤 이유로 제거되거나 다시 프로비저닝된 디스크/파티션을 의미할 수 있으며 , 현재 UUID와 일치하기 위해 필요에 따라 구성을 제거하거나 수정해야 합니다.blkid
mkfs
그러나 .NET 시스템 systemd
에서 /etc/fstab
파일 시스템 마운트를 구성할 수 있는 유일한 장소는 아닙니다 .누군가가 *.mount
에서 사용자 정의 단위 파일을 작성했거나 /etc/systemd/
프로세스가 에서 사용자 정의 단위 파일을 동적으로 생성했을 수 있습니다 /run/systemd/
.
grep -ri c04ab358- /etc/systemd /run/systemd /lib/systemd
문제의 UUID가 파일의 어느 곳에나 언급되어 있는지 확인하려면 실행하세요 *.mount
.
해당 *.mount
파일이 아래에 있으면 /etc/systemd/
삭제하세요.
아래에 있는 경우 /run/systemd/
생성자 프로세스를 식별하는 주석이 있는 경우 유닛 파일을 확인하는 것이 좋습니다. tmpfs 파일 시스템 이므로 /run
부팅할 때마다 그 안에 있는 모든 내용이 자동으로 생성되거나 다른 곳에서 복사되어야 합니다. 단위 파일을 생성하는 프로세스를 식별하고 결과 설치 단위가 더 이상 적합하지 않으면 이를 중지해야 합니다.
*.mount
다음 문서에서 UUID가 언급되는 경우 는 드물지만 /lib/systemd/
누군가 권장 시스템 관리 관행을 위반하고 있는 것입니다. 파일이 패키지에서 가져온 경우 버그 보고서를 보내주십시오. 사용된 파일 시스템 UUID로 인해 특정 시스템에 고유한 항목을 만드는 것은 /lib/systemd/
부적절합니다. 특별한 이유가 없다면 에 들어가 /etc/systemd/
거나 맞춤형 마운트 장치를 사용해야 합니다./etc/fstab
답변2
sudo lsblk -f
모든 실제 장치의 장치, 파티션, UUID, 크기 및 마운트 지점이 표시됩니다.