배경 이야기
Minikube를 설치하고 가상 박스가 필요하며 BIOS에서 AMD-V(하드웨어 가상화)를 찾아서 켠 후에도 사용할 수 없다는 오류가 발생합니다. 인터넷의 지혜에 따르면 내 버전의 Bios(F1)에는 AMD-V에 버그가 있으며 F3 이후의 모든 버전에서도 WRT 가상화가 중단되고 1950x 프로세서(29XX 시리즈에 더 중점을 둡니다)와 잘 작동하지 않는다고 합니다. Su....F3j로 플래시했습니다.
질문
이제 grub을 부팅하면 모든 것이 잘 작동하고 예상되는 옵션 목록(Ubuntu, 고급 Ubuntu 옵션, mem 검사 콘텐츠, Windows 10)이 제공되고 Ubuntu 고급 옵션으로 이동하여 복구 이미지를 선택하면 Windows가 제대로 작동합니다. 정상적으로 부팅됩니다. 그러나 시간 초과를 허용하거나 기본 Ubuntu 옵션을 선택하면 부팅이 진행되지 않고(때때로) 보라색 화면이 표시되거나 텍스트가 매우 빠르게 스크롤되어 에 대한 메시지가 표시됩니다 clocksource: Switched to clocksource tsc
. 이 데드 부팅 상태에서는 마우스나 키보드( Razer LED 조명 모델)이 켜지지만 Ctrl-Alt-Del
아무런 효과가 없습니다. 유일한 방법은 전원 버튼을 몇 초 동안 눌러 강제로 다시 시작하는 것입니다.
내가 시도한 것
여기와 웹의 다른 곳에서 내가 검색한 내용에 따르면 이는 EFI 변수가 사용 중이고 새로 고침으로 인해 해당 변수가 제거되었기 때문일 수 있습니다. 그러나 이러한 보고서에는 모두 다른 마더보드가 언급되어 있으므로 그것이 문제인지는 잘 모르겠습니다. 그러나 복구 모드에서 efibootmgr이 실행되지 않고 불평하는 것을 발견했습니다 EFI Variables are not supported on this system
. 그래서 활성화하려고 노력했습니다... BIOS를 로드하고 다음 옵션을 사용해 보았습니다.
Storage Boot Option Control
설정에서 다음으로 변경했습니다 .UEFI Only
Legacy
- 전환했는데
Boot Option 1
첫 번째인지 여부에는Boot Option 2
아무런 차이가 없는 것 같습니다.Samsung 960
UEFI 5.0
- UEFI를 우선시하도록 BBS 우선순위를 변경했습니다.
- IOMMU 설정 문제를 읽고 자동에서 활성화로 변경해 보았습니다.
이 중 어느 것도 눈에 띄는 효과가 없었습니다.
시스템 세부정보
- 지난 2년 동안 Ubuntu 18.04 LTS는 GRUB를 통해 Windows 10과의 이중 부팅에 성공했습니다.
- Rev 1.0 기가바이트 Aorus Gaming 7 X399 마더보드
- 라이젠 스레드리퍼 1950x CPU
- Samsung 960 NVME 500MB 메인 드라이브
- 삼성 970 NVME 보조 드라이브
- 48GB RAM, 1080ti 카드 등과 같은 주변 장치는 관련이 없을 수 있습니다.
질문
- 이 하드웨어 세트(또는 적어도 Aorus X399)에서 BIOS를 성공적으로 업그레이드한 사람이 있습니까? 그렇다면 이 문제가 발생한 적이 있습니까? 이 문제가 발생했다면 어떻게 해결하셨나요?
- Linux 부팅 전문가 중 모든 것을 정상으로 되돌리는 방법에 대한 아이디어가 있습니까?
복원할 수 있도록 BIOS를 백업했습니다(BIOS의 Quickboot 도구 사용).가능한정상적으로 부팅이 되지만 여전히 Minikube 설치에 머물고 있습니다.
고쳐 쓰다:960 Samsung(일반 부팅 드라이브)으로 처음 BBS 주문을 시도한 후 grub에서 정상적으로 부팅하려고 하면 다음 메시지가 나타납니다. Windows 시작 및 복구/복구 부팅에서 계속 작업
또한 참고하십시오:UEFI: Verbatim 5.0 부팅 옵션은 로더를 로드하는 데 사용한 메모리 스틱이었습니다(내 메모리 스틱에 이름이 붙어 있는 줄 몰랐고 내장된 것으로 생각했습니다).
요청된 정보를 기반으로 업데이트
gus@ns-l1:/$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.15.0-76-generic root=UUID=d44cf192-4f87-499a-b58a-573f498fc38a ro recovery nomodeset
gus@ns-l1:/$ cat /proc/partitions
major minor #blocks name
7 0 55952 loop0
7 1 9284 loop1
7 3 144044 loop3
7 4 93560 loop4
7 5 45960 loop5
7 6 163996 loop6
259 0 500107608 nvme1n1
259 1 512000 nvme1n1p1
259 2 250961856 nvme1n1p2
259 3 884736 nvme1n1p3
259 4 1 nvme1n1p4
259 5 247745536 nvme1n1p5
259 6 1000204632 nvme0n1
259 7 716800000 nvme0n1p1
259 8 283403264 nvme0n1p2
7 8 55952 loop8
7 9 144044 loop9
7 10 9284 loop10
7 12 160440 loop12
7 13 45240 loop13
7 14 93504 loop14
7 15 15112 loop15
7 16 15112 loop16
gus@ns-l1:/$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.15.0-76-generic root=UUID=d44cf192-4f87-499a-b58a-573f498fc38a ro recovery nomodeset
gus@ns-l1:/$ 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/nvme0n1p5 during installation
UUID=d44cf192-4f87-499a-b58a-573f498fc38a / ext4 errors=remount-ro 0 1
/swapfile none swap sw 0 0
UUID=710a8b10-00f4-4de9-88d6-d5b76f7593c5 /mnt/data f2fs defaults 0 0
UUID=1F11D42B4B32AACA /mnt/win ntfs rw,noexec,nouser,auto,async 0 0
gus@ns-l1:/$
UUID가 fstab의 내용과 일치하는 것 같습니다.
답변1
먼저 golimar 주석을 확인하고 필요한 UUID가 있는지 확인하세요.
nvme 설정에 문제가 있는 것 같습니다. 죽기 전 마지막 메시지는 "컨트롤러 식별 실패"입니다. 그 후에는 UUID를 찾을 수 없습니다. 이는 시스템이 UUID를 올바르게 읽을 수 없다면 의미가 있습니다.
- nvme SSD 부팅을 지원하는 경우 BIOS 옵션을 확인하세요(Windows가 제대로 작동하므로 괜찮지만 다시 확인하세요).
- 펌웨어를 업데이트한 경우 칩셋 드라이버도 업데이트해야 합니다(반대의 경우도 마찬가지).
답변2
진단하고 수리하려면 다음을 시도해 보십시오.
우분투 USB 썸 드라이브로 부팅하고 "blkid"를 사용하여 어떤 장치가 보이는지 확인하세요. 일부 BIOS 변경으로 인해 디스크가 AHCI에서 Linux가 좋아하지 않는 이상한 것으로 바뀌거나 UUID가 변경되었을 수 있습니다. 디스크가 전혀 보이지 않으면 AHCI로 설정되어 있는지 확인하세요. 일부 NVMe 시스템이 Intel의 RST를 사용하도록 구성되어 있다는 것을 알고 있지만 Linux 관점에서는 디스크를 사용할 수 없습니다.
그런 다음 grub을 사용하거나 원래 루트 파일 시스템을 마운트하고 수정하여 이 장애물을 일시적으로 극복할 수 있습니다. 여기에서 사용 가능한 Grub 옵션:
루트 드라이브를 식별할 때 경로가 /dev/sdXX 장치라는 점을 확인한 다음 부팅 프로세스 중에 grub을 일시 중지하고 부팅을 계속하기 전에 명령줄의 UUID 부분을 "root=/dev/sdXX"로 변경합니다. 이 방법을 사용하여 시스템을 시작하고 실행한 경우 /etc/fstab을 복구하고 grub 설치를 다시 실행할 수 있습니다.