동기화되지 않음: VFS: 알 수 없는 블록(0,0)에 루트 파일 시스템을 마운트할 수 없습니다.

Question 1

VFS: unable to mount root fs on unknown-block(0 0)커널이 루트 파일 시스템을 마운트할 수 없음을 의미합니다. 여기에는 두 가지 일반적인 이유가 있습니다.

커널이 장치의 파일 시스템을 지원하지 않습니다. 자신의 커널을 컴파일한 경우 이는 일반적으로 파일 시스템 드라이버가 커널의 기본 부분이 아닌 모듈로 구축되어야 한다고 지정했기 때문입니다. 배포판 커널을 사용한 경우 이는 일반적으로 A 고유 형식을 선택했기 때문입니다. 두 경우 모두 이 작업을 수행하지 마십시오.
커널에 전달된 루트 장치 이름이 잘못되었습니다. 이 문제는 해결하기 어려울 수 있습니다. 제가 찾은 가장 좋은 방법은 부트로더에서 커널 명령줄을 수정하여 root=작동하는 항목을 찾을 때까지 매개변수가 어떻게 보일지 교육받은 추측을 하는 것입니다.

Answer

VFS: unable to mount root fs on unknown-block(0 0)커널이 루트 파일 시스템을 마운트할 수 없음을 의미합니다. 여기에는 두 가지 일반적인 이유가 있습니다.

커널이 장치의 파일 시스템을 지원하지 않습니다. 자신의 커널을 컴파일한 경우 이는 일반적으로 파일 시스템 드라이버가 커널의 기본 부분이 아닌 모듈로 구축되어야 한다고 지정했기 때문입니다. 배포판 커널을 사용한 경우 이는 일반적으로 A 고유 형식을 선택했기 때문입니다. 두 경우 모두 이 작업을 수행하지 마십시오.
커널에 전달된 루트 장치 이름이 잘못되었습니다. 이 문제는 해결하기 어려울 수 있습니다. 제가 찾은 가장 좋은 방법은 부트로더에서 커널 명령줄을 수정하여 root=작동하는 항목을 찾을 때까지 매개변수가 어떻게 보일지 교육받은 추측을 하는 것입니다.

Question 2

커널 메시지를 기반으로 완전한 진단 프로세스

이것을 사용하여QEMU 에뮬레이션 설정문제를 디버깅하는 데 도움이 되도록 가능한 각 오류 유형에 대해 최소한의 예를 제공하려고 노력합니다.

이 간단한 설정에서 QEMU는 다음을 통해 시스템을 에뮬레이트합니다.

실제 하드웨어의 하드 드라이브 또는 SDD를 나타내는 단일 virtio 디스크
virtio 디스크에는 분할되지 않은 원시 ext4 이미지가 포함되어 있습니다. 정상 작동 시 장치는 아래에 표시됩니다 /dev/vda( v는 virtio에 대한 지정 문자이고, 파티션이 분할된 경우 파티션은 입니다 /dev/vda1. /dev/vda2등).

발생할 수 있는 오류는 다음과 같습니다.

Linux는 디스크에서 바이트를 읽을 수 없습니다.

이는 디스크가 손상되었거나 해당 유형의 하드웨어를 읽도록 Linux를 구성하지 않았기 때문일 수 있습니다.

내 QEMU의 경우 커널이 virtio 디스크를 읽을 수 있도록 허용하는 키 옵션을 제거하여 이를 재현할 수 있었습니다.
```
CONFIG_VIRTIO_BLK=y
CONFIG_VIRTIO_PCI=y
```
결과 오류 메시지는 다음과 같습니다
```
<4>[    0.541708] VFS: Cannot open root device "vda" or unknown-block(0,0): error -6
<4>[    0.542035] Please append a correct "root=" boot option; here are the available partitions:
<0>[    0.542562] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
```
따라서 Linux는 vda에서 전혀 읽을 수 없다고 말합니다 VFS: Cannot open root device "vda" or unknown-block(0,0): error -6.

그런 다음 Please append a correct "root=" boot option; here are the available partitions:읽을 수 있는 파티션 목록을 제공합니다.

그러나 우리의 경우에는 다음 행이 전혀 관련이 없기 때문에 목록이 비어 있습니다.
Linux는 디스크에서 바이트를 읽을 수 있지만 디스크에서 파일을 읽는 파일 시스템을 이해하지 못합니다.

이는 일반적으로 해당 파일 시스템 유형을 읽도록 커널을 구성하지 않았기 때문입니다.

ext4 파일 시스템을 읽는 커널의 기능을 제거하여 이 상황을 해결할 수 있었습니다.
```
CONFIG_EXT4_FS=y
```
삭제 후 오류 메시지는 다음과 같습니다.
```
<4>[    0.585296] List of all partitions:
<4>[    0.585913] fe00          524288 vda
<4>[    0.586123]  driver: virtio_blk
<4>[    0.586471] No filesystem could mount root, tried:
<4>[    0.586497]  squashfs
<4>[    0.586724]
<0>[    0.587360] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(254,0)
```
vda따라서 Linux는 장치를 사용하여 디스크를 읽어 파티션을 성공적으로 찾았다 고 알려줍니다 virtio_blk.

하지만 그러면 파티션을 읽을 수 없습니다. 그것은 시도했다squashfs, 이는 우리가 활성화하는 유일한 다른 파일 시스템이지만 ext4 파티션이 있기 때문에 작동하지 않습니다.
root=잘못된 커널 명령줄 옵션을 전달했습니다 .

이 질문은 매우 간단합니다. 올바르게 대답하세요! 커널은 알고 있는 내용의 목록도 제공합니다!

예를 들어 오류를 전달하는 경우:
```
root=/dev/vda2
```
존재하지도 않으며 커널은 다음과 같은 유형의 오류를 제공합니다.
```
<4>[    0.608475] Please append a correct "root=" boot option; here are the available partitions:
<4>[    0.609563] fe00          524288 vda
<4>[    0.609723]  driver: virtio_blk
<0>[    0.610433] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(254,2)
```
vda2Cleanup은 "안녕하세요: 아니요 , 하지만 있습니다 vda!"라고 말합니다.

이 예 (0,0)에서는 이전 사례 (254,0)의 및 의 의미도 잘 보여줍니다 (254,2).
- (0,0): 첫 번째 숫자 0은 디스크에서 전혀 읽을 수 없음을 의미합니다.
- (254,2): 254는 디스크에 할당된 일부 ID입니다. 2에 표시된 대로 해당 ID를 가진 파티션입니다 /dev/vda2. 파티션은 0그림과 같이 파티션되지 않은 원래 파티션을 나타냅니다 /dev/vda.

Linux 5.4.3에서 테스트되었습니다.

Answer

커널 메시지를 기반으로 완전한 진단 프로세스

이것을 사용하여QEMU 에뮬레이션 설정문제를 디버깅하는 데 도움이 되도록 가능한 각 오류 유형에 대해 최소한의 예를 제공하려고 노력합니다.

이 간단한 설정에서 QEMU는 다음을 통해 시스템을 에뮬레이트합니다.

실제 하드웨어의 하드 드라이브 또는 SDD를 나타내는 단일 virtio 디스크
virtio 디스크에는 분할되지 않은 원시 ext4 이미지가 포함되어 있습니다. 정상 작동 시 장치는 아래에 표시됩니다 /dev/vda( v는 virtio에 대한 지정 문자이고, 파티션이 분할된 경우 파티션은 입니다 /dev/vda1. /dev/vda2등).

발생할 수 있는 오류는 다음과 같습니다.

Linux는 디스크에서 바이트를 읽을 수 없습니다.

이는 디스크가 손상되었거나 해당 유형의 하드웨어를 읽도록 Linux를 구성하지 않았기 때문일 수 있습니다.

내 QEMU의 경우 커널이 virtio 디스크를 읽을 수 있도록 허용하는 키 옵션을 제거하여 이를 재현할 수 있었습니다.
```
CONFIG_VIRTIO_BLK=y
CONFIG_VIRTIO_PCI=y
```
결과 오류 메시지는 다음과 같습니다
```
<4>[    0.541708] VFS: Cannot open root device "vda" or unknown-block(0,0): error -6
<4>[    0.542035] Please append a correct "root=" boot option; here are the available partitions:
<0>[    0.542562] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
```
따라서 Linux는 vda에서 전혀 읽을 수 없다고 말합니다 VFS: Cannot open root device "vda" or unknown-block(0,0): error -6.

그런 다음 Please append a correct "root=" boot option; here are the available partitions:읽을 수 있는 파티션 목록을 제공합니다.

그러나 우리의 경우에는 다음 행이 전혀 관련이 없기 때문에 목록이 비어 있습니다.
Linux는 디스크에서 바이트를 읽을 수 있지만 디스크에서 파일을 읽는 파일 시스템을 이해하지 못합니다.

이는 일반적으로 해당 파일 시스템 유형을 읽도록 커널을 구성하지 않았기 때문입니다.

ext4 파일 시스템을 읽는 커널의 기능을 제거하여 이 상황을 해결할 수 있었습니다.
```
CONFIG_EXT4_FS=y
```
삭제 후 오류 메시지는 다음과 같습니다.
```
<4>[    0.585296] List of all partitions:
<4>[    0.585913] fe00          524288 vda
<4>[    0.586123]  driver: virtio_blk
<4>[    0.586471] No filesystem could mount root, tried:
<4>[    0.586497]  squashfs
<4>[    0.586724]
<0>[    0.587360] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(254,0)
```
vda따라서 Linux는 장치를 사용하여 디스크를 읽어 파티션을 성공적으로 찾았다 고 알려줍니다 virtio_blk.

하지만 그러면 파티션을 읽을 수 없습니다. 그것은 시도했다squashfs, 이는 우리가 활성화하는 유일한 다른 파일 시스템이지만 ext4 파티션이 있기 때문에 작동하지 않습니다.
root=잘못된 커널 명령줄 옵션을 전달했습니다 .

이 질문은 매우 간단합니다. 올바르게 대답하세요! 커널은 알고 있는 내용의 목록도 제공합니다!

예를 들어 오류를 전달하는 경우:
```
root=/dev/vda2
```
존재하지도 않으며 커널은 다음과 같은 유형의 오류를 제공합니다.
```
<4>[    0.608475] Please append a correct "root=" boot option; here are the available partitions:
<4>[    0.609563] fe00          524288 vda
<4>[    0.609723]  driver: virtio_blk
<0>[    0.610433] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(254,2)
```
vda2Cleanup은 "안녕하세요: 아니요 , 하지만 있습니다 vda!"라고 말합니다.

이 예 (0,0)에서는 이전 사례 (254,0)의 및 의 의미도 잘 보여줍니다 (254,2).
- (0,0): 첫 번째 숫자 0은 디스크에서 전혀 읽을 수 없음을 의미합니다.
- (254,2): 254는 디스크에 할당된 일부 ID입니다. 2에 표시된 대로 해당 ID를 가진 파티션입니다 /dev/vda2. 파티션은 0그림과 같이 파티션되지 않은 원래 파티션을 나타냅니다 /dev/vda.

Linux 5.4.3에서 테스트되었습니다.

Question 3

VFS: 알 수 없는 블록에 루트 파일 시스템을 마운트할 수 없습니다(0 0) _ _ _

전원 버튼을 길게 눌러 노트북을 끕니다.
"고급" 옵션을 선택하세요.
공통 최소 버전 선택("복구 모드")
"청소"를 클릭하고 "여유 공간을 확보해 보세요"를 클릭하세요.
그런 다음 "복원" "정상 시작 재개"

Answer

VFS: 알 수 없는 블록에 루트 파일 시스템을 마운트할 수 없습니다(0 0) _ _ _

전원 버튼을 길게 눌러 노트북을 끕니다.
"고급" 옵션을 선택하세요.
공통 최소 버전 선택("복구 모드")
"청소"를 클릭하고 "여유 공간을 확보해 보세요"를 클릭하세요.
그런 다음 "복원" "정상 시작 재개"

Question 4

@HasanQ는 정답에 가장 가깝지만 아직 불완전합니다.

Arch 기반 배포판과 관련되어 커널에서 intel-ucode 및 amd-ucode를 로드하는 대신 별도로 실행합니다. 이는 "e"를 눌러 편집하고 확인하면 Grub 메뉴의 해당 항목에서 쉽게 볼 수 있습니다. 시작 매개변수 - 결론을 참조하세요.

이는 Debian 기반 배포판(예: Mint, Ubuntu), RPM 기반 배포판(예: Fedora, Mageia) 및 Gentoo 기반 배포판(Calulate 및 Sabayon)에서 발생합니다. 아직 Slackware에서는 시도해보지 않았습니다. Arch 기반 부트로더를 사용할 필요는 없습니다.

파일을 생성하고 일반적으로 custom.cfg어디에나 배치할 수 있습니다. Grub을 업데이트할 필요 없이 재부팅하고 메뉴 하단의 항목을 선택하기만 하면 됩니다.grub.cfg/boot/grub

이에 대한 내용은 다음에서 읽을 수 있습니다.리눅스 포인트 조직또는노력포럼.

다른 곳에서,Manjaro 또는 기타 Arch 및 기타 배포판을 설치한 다음 커널 패닉, 나는 다음과 같이 썼습니다 :

컴퓨터에서 Manjaro(또는 다른 Arch 기반 배포판)만 실행하거나 Windows로 이중 부팅한 다음 Arch 기반이 아닌 다른 배포판을 설치하기로 선택한 경우 이 문서가 적합합니다.

Arch 기반이 아닌 Linux에서도 이중 부팅 또는 다중 부팅을 수행하는 경우 커널 패닉이 발생할 수 있습니다.

이는 Arch가 아닌 배포판에서 업데이트 및 업그레이드를 수행한 후에 발생하며, 이는 해당 배포판이 Grub 메뉴 상단에 있는 기본 파티션의 위치를 차지하기에 충분합니다.

이 기사는 GRUB에만 적용되지만 rEFInd 사용자 및 기타 부트로더 사용자의 의견을 듣고 싶습니다.

업데이트 및 업그레이드된 패키지는 다음의 일부 조합을 포함하되 이에 국한되지 않는 이러한 변경 사항을 순차적으로 생성합니다.

당신의 핵심

Grub, grub-efi, grub-pc, grub-signed 등

개스킷, 개스킷 서명

일부 주요 펌웨어 업데이트

기타(당신이 그들을 찾을 것이고, 그렇지 않으면 그들이 당신을 찾을 것입니다!)

컴퓨터를 다시 시작하면 다른 배포판이 이제 맨 위에 있고 제대로 작동합니다. 그런 다음 키를 눌러 Manjaro를 선택하고...

커널 패닉

커널 패닉이 발생하면 다음과 유사한 출력이 있는 흑백(tty 스타일) 화면이 표시됩니다.
Kernel Panic – not syncing : VFS: unable to mount root fs on unknown-block(0,0)
다음은 CPU 참조, 하드웨어 이름, 호출 추적, 커널 오프셋이며 다음으로 끝납니다.
---[ end Kernel Panic – not syncing : VFS: unable to mount root fs on unknown-block(0,0) ]---
이번에는 Manjaro를 선택하지 않고 전원을 껐다가 다시 시작하는 것 외에는 종료하거나 응답을 받을 수 없습니다.

아마도 이를 방지하는 유일한 방법은 Manjaro(또는 다른 아치 기반) Grub을 제어하는 것입니다.

그러나 실제로는 그렇지 않습니다.

라는 파일을 생성하여 ( ) 폴더(일부 배포 시리즈에 있을 수도 있음 ) custom.cfg에 저장 하면 재부팅하면 Grub 메뉴 끝에 해당 항목이 나타납니다. Grub을 업데이트할 필요가 없습니다. 그냥 해./boot/grub/boot/grub2

지금 이 작업을 수행하는 방법을 보여 드리겠습니다.

이 기능이 필요한 사용자가 있다는 것을 알고 있기 때문에 가능한 한 가장 짧은 방법으로 요약하고 일반적으로 관심이 있는 분들을 위해 더 자세한 내용을 입력하겠습니다. 따라서 할부 스레드가 될 수 있습니다.

준비하다

Timeshift, BackInTime, Snapper 또는 유사한 시스템 복구 도구를 사용하는 경우 먼저 실행 중인 운영 체제의 스냅샷/이미지를 찍어 보호하십시오.

Endeavour 또는 기타 Arch 기반 배포판의 루트 파티션의 UUID를 가져와서 준비하고 입력해야 합니다. 이는 다음을 포함하되 이에 국한되지 않는 다양한 방법을 통해 달성할 수 있습니다.

Gparted에서 루트 파티션을 마우스 오른쪽 버튼으로 클릭하고 정보를 클릭합니다.

터미널에서 사용blkid | grep -i <label of distro if labelled>

확인하다/etc/fstab

다른 방법

작은 텍스트 파일을 생성하기 위해 사용할 텍스트 편집기(CLI 또는 GUI)를 결정하고 결과 파일을 ( ) 또는 구체적으로 /boot/grub파일이 저장된 폴더에 배치해야 한다는 점에 유의하세요.grub.cfg

이를 위해서는 sudo와 같은 루트 권한이 필요하거나 루트로 가정해야 합니다. Endeavour나 Arch 기반이 아닌 배포판(예: Linux Mint로 부팅)의 경우 배포판은 Grub 메뉴의 기본(상단) 섹션에 있습니다.

Grub 메뉴의 기본 섹션(상단)에 있는 Endeavour나 Arch 기반이 아닌 배포판(예: Linux Mint로 부팅)으로 부팅합니다.

속도

일반적인 EXT4 UUID는 32개의 숫자 및 알파벳 문자 형식이며 다음과 같이 구성됩니다(8, 4, 4, 4, 12, 대시로 구분).
7b52a802-aa6d-4aa2-aab5-5dffbe6833c6 
이 연습에서는 다음을 사용합니다.
nnnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnnn 
그런 다음 준비 단계 2.1.-4에서 얻은 결과를 복사/붙여넣어 이 값을 바꿉니다. 이상.
다음을 사용하여 touch파일을 만든 custom.cfg다음 선호하는 텍스트 편집기를 사용하거나 nano다음과 같이 사용합니다.
sudo nano custom.cfg

여기서 n 문자열은 Endeavour 또는 기타 Arch 기반 배포판의 루트 파티션 UUID입니다.
menuentry "Manjaro - configfile" { 
insmod part_gpt 
part part_msdos 
insmod ext2 
search --no-floppy --fs-uuid --set=root nnnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnnn
configfile /boot/grub/grub.cfg
}
첫 번째 줄의 따옴표 부분은 귀하의 선택입니다. 원하는 경우 "My dear Manjaro"라고 부를 수 있습니다.

그 외에도 두 개의 중괄호를 포함하여 구문이 정확히 일치하는지 확인하세요.
파일을 저장하고 종료하거나 종료하고 파일을 저장하여 ( /boot/grub) 또는 grub.cfg파일이 있는 곳에 배치합니다.

다시 시작(grub을 업데이트할 필요 없음)
위 단계를 올바르게 수행했다면 GRUB 메뉴를 볼 때 마지막 줄에 첫 번째 줄의 내용을 설명하는 추가 항목이 표시됩니다. 이것은 Manjaro 또는 선택한 Arch 기반 배포판에 대한 새로운 진입점입니다.

주문한 GRUB 메뉴 목록에는 Manjaro에 대한 또 다른 항목이 있지만 이를 선택하면 여전히 커널 패닉이 발생하므로 마지막 항목 선택을 연습하십시오.

Answer