(và chào mừng bạn đến với chủ đề mới "hãy ghét Microsoft")
Máy tính xách tay Asus với ổ SSD 500 GB, với phân vùng Windows NTFS 150 GB và phân vùng Ubuntu 20.04 350 GB (gần như chắc chắn đó là ext4). Khởi động kép với GRUB/Ubuntu được ưu tiên hơn Windows. Dữ liệu quan trọng trên phân vùng Ubuntu, không phải trên Windows.
Sau 1 giờ cập nhật Windows, không có sự cố gì (không mất điện hay gì cả), máy tính khởi động vào dòng lệnh GRUB ("grub>", không phải "grub rescue>"). Khó chịu hơn, điều này cũng xảy ra khi cắm khóa USB trực tiếp (18.04, đã được thử nghiệm tốt trên một máy tính xách tay khác). Khi sử dụng "thoát" trên dấu nhắc Windows sẽ khởi động bình thường.
Đó là tổng quan, bây giờ cho các chi tiết cụ thể.Với phím USB trực tiếp, trước tiên, một màn hình nhanh chóng xuất hiện có nội dung
Không thể mở EFI\BOOT\grubx64.efi - Không tìm thấy
Không thể tải hình ảnh EFI\BOOT\grubx64.efi - Không tìm thấy
start_image() trả về Không tìm thấy
sau một giây, dấu nhắc "grub>" xuất hiện
Trên dấu nhắc "grub>", ls trả về
(proc) (hd0) (hd0,msdos1) (hd1) (hd2) (hd2,gpt6) (hd2,gpt5) (hd2,gpt4) (hd2,gpt3) (hd2,gpt2) (hd2,gpt1)
ls (proc) trả về
Proc thiết bị: Procfs loại hệ thống tệp - Kích thước cung 512B - Tổng kích thước 0KiB
USB trực tiếp là hd0 và như mong đợi ls (hd0,1) trả về
Phân vùng hd0,msdos1: Loại chất béo của hệ thống tệp - Nhãn 'Ubuntu 18_0', UUID 864E-2850 - Phân vùng bắt đầu ở 1024KiB - Tổng kích thước 15150080KiB
Tôi không biết hd1 là gì; máy tính trước đây có ổ cứng HDD đã được thay thế bằng SSD cách đây vài năm, có lẽ đó là dấu vết của điều đó. ls (hd1) trả về
Thiết bị hd1: Không phát hiện thấy hệ thống tệp đã biết - Kích thước cung 2048B - Tổng kích thước 514KiB
hd2 là ổ cứng thật. ls (hd2) mô tả thiết bị
Thiết bị hd2: Không phát hiện thấy hệ thống tệp đã biết - Kích thước cung 512B - Tổng kích thước 488386584KiB
ls (hd2,xx) for xx= 6 to 1 mô tả các phân vùng
Phân vùng hd2,6: Không phát hiện thấy hệ thống tệp đã biết - Phân vùng bắt đầu tại 14684736KiB - Tổng kích thước 341580800KiB
Phân vùng hd2,5: Loại hệ thống tệp ntfs, UUID84127C1A127C1380 - Phân vùng bắt đầu tại 146205696KiB - Tổng kích thước 598016KiB
Phân vùng hd2,4: Loại hệ thống tệp ntfs, UUID22FE5C86FE5C53DF - Phân vùng bắt đầu ở 661504KiB - Tổng kích thước 145543516KiB
Phân vùng hd2,3: Không phát hiện thấy hệ thống tệp đã biết - Phân vùng bắt đầu ở 645120KiB - Tổng kích thước 16384KiB
Phân vùng hd2,2: Loại chất béo của hệ thống tệp, UUID 0057-5017 - Phân vùng bắt đầu ở 542720KiB - Tổng kích thước 102400KiB
Phân vùng hd2,1: Loại hệ thống tệp ntfs, Nhãn 'Rcupration' - Phân vùng bắt đầu ở 1024KiB - Tổng kích thước 541696KiB
hd2,6 dường như là phân vùng Ubuntu 350 GB. Theo như tôi có thể nói thì không nên nói "Không phát hiện hệ thống tệp đã biết", trong một máy tính xách tay khác, cấu trúc ext được phát hiện chính xác bằng lệnh grub ls.
hd2,4 dường như là phân vùng Windows.
hd2,1 có tên lạ vì dấu trong tiếng Pháp không hiển thị
Khi tôi cố khởi động từ phân vùng linux bằng
đặt tiền tố = (hd2, gpt6)/boot/grub
đặt gốc=(hd2,gpt6)
insmod bình thường
thông thường
không có gì xảy ra (tôi cho rằng nó được mong đợi nếu nó không thể báo cho hệ thống tập tin). Khi tôi thử khởi động khóa, sử dụng
đặt tiền tố = (hd0,1)/boot/grub
đặt gốc = (hd0,1)
insmod bình thường
thông thường
Tôi nhận được lời nhắc USB trực tiếp, nhưng sau đó khi tôi chọn "Dùng thử Ubuntu mà không cần cài đặt" hoặc bất kỳ tùy chọn nào khác, tôi nhận được
lỗi: /casper/vmlinuz có chữ ký không hợp lệ.
lỗi: bạn cần tải kernel trước.
Bấm phím bất kỳ để tiếp tục...
sau đó quay lại menu phím trực tiếp, bị mắc kẹt trong một vòng lặp. Điều này hơi kỳ lạ, vì trước đó nó đã cảnh báo tôi rằng không tìm thấy grubx64.efi và từ những gì tôi thu thập được (Cập nhật Windows 8 đã phá vỡ GRUB của tôi) thực tế là nó không yêu cầu shimx64.efi có nghĩa là Khởi động an toàn bị vô hiệu hóa, nhưng chữ ký này là gì? Trong mọi trường hợp, việc thiếu khả năng khởi động thích hợp trên khóa USB trực tiếp khiến tôi không thể sử dụng các công cụ sửa chữa thông thường.
Bây giờ tôi vẫn có thể gõ "thoát" và sau đó Windows khởi động bình thường. Trên Windows, tôi đã thử tải xuống Testdisk. Testdisk phát hiện đúng phân vùng Linux, như sau:
Phân vùng Bắt đầu Kết thúc Kích thước trong các lĩnh vực
1 P Windows Recovery Env 2048 1085439 1083392 [Phân vùng dữ liệu cơ bản]
2 P Hệ thống EFI 1085440 1290239 204800 [Phân vùng hệ thống EFI]
Không có điểm đánh dấu FAT, NTFS, ext2, JFS, Reiser, cramfs hoặc XFS
3 P MS Dành riêng 1290240 1323007 32768 [Phân vùng dành riêng của Microsoft]
3 P MS Dành riêng 1290240 1323007 32768 [Phân vùng dành riêng của Microsoft]
4 P Dữ liệu MS 1323008 292410039 291087032 [Phân vùng dữ liệu cơ bản]
5 P Phục hồi Windows Env 292411392 293607423 1196032
6 P Hệ thống tập tin Linux. dữ liệu 293609472 976771071 683161600
Tuy nhiên, khi tôi đi vào phân vùng đó (với Advanced Utils) và cố gắng liệt kê các tệp, tôi nhận được
Hỗ trợ cho hệ thống tập tin này không được kích hoạt trong quá trình biên dịch
Chỉ Windows khởi động đúng cách, vì vậy tôi không có sẵn phiên bản khác để cố gắng hoạt động trên phân vùng ext4. Ngoài ra, tôi mới tải xuống .exe và không tự biên dịch nó, vì tôi không đủ kinh nghiệm để làm điều đó.
Một số chủ đề trên các diễn đàn Testdisk gợi ý rằng khi một phân vùng được liệt kê hai lần như 3 ở trên, điều đó có nghĩa là có vấn đề.
Cho nên...
Mục tiêu chính của tôi là giành quyền truy cập vào các tệp của phân vùng Ubuntu, mặc dù việc sửa chữa mọi thứ như ngày hôm qua sẽ thực sự tốt đẹp. Tôi thấy một vài con đường có thể:
- bằng cách nào đó làm cho GRUB khởi động phân vùng Ubuntu, đọc nó là ext4
- làm cho GRUB khởi động khóa USB trực tiếp đúng cách (với chữ ký đó), sau đó sử dụng các công cụ khôi phục từ đó
- sử dụng Testdisk (trên Windows) để sửa chữa phân vùng ext4 để GRUB có thể nhìn thấy nó đúng cách hoặc một công cụ tương tự khác trong Windows
- sử dụng bất kỳ công cụ nào để đọc phân vùng Ubuntu dưới dạng ext4, lấy các tệp ra và ném máy tính ra ngoài cửa sổ.
Có ai có ý tưởng gì không ?
Dù bằng cách nào, cảm ơn vì đã đọc!
