Điểm:1

Tạo cuộc gặp gỡ LiveCD tùy chỉnh trên máy tính để bàn trên Ubuntu 20.04.2 Kiểm tra hoàn tất: tìm thấy lỗi trong 1 tệp! Bạn có thể gặp lỗi

lá cờ bg

Tôi tạo một phiên bản máy tính để bàn usb Ubuntu LiveCD 20.04.2 qua cái này mạo từ.

Tôi đã kiểm tra xem iso sha256 ban đầu của mình có đúng không. Ngoài ra, tôi đã kiểm tra khối usb qua rufus. Và kết quả là 0 khối xấu được tìm thấy. (0/0.0 lỗi)

Nhưng sau khi flash iso qua Windows rufus. Và khởi động ở chế độ uefi. Nó có thể gặp phải:

 Kiểm tra xong: tìm thấy lỗi trong 1 tệp! Bạn có thể gặp lỗi.

Những gì tôi gặp phải như thế này Check xong lỗi tìm được trong 1 file. Nhưng cuối cùng không có câu trả lời.

Có cách nào để kết xuất kết quả thông báo thông tin đĩa kiểm tra hoặc tệp kiểm tra không /boot/grub/efi.img là đúng/không chính xác?

Tôi đã kiểm tra đường dẫn /cdrom/boot/grub/efi.img bằng nhau trong md5sum.txt

Có một số bài báo liên quan đến vấn đề này Kiểm tra lỗi với 20.04-desktop ISO , Kiểm tra lỗi với 20.04-desktop ISO nhưng không phải về làm cd trực tiếp.

galexite avatar
lá cờ pk
Có báo lỗi như trong `efi.img` không? Có vẻ như nó có thể là bất kỳ một trong những tệp đó, chỉ là những vấn đề bạn đã đề cập trực tiếp nói về một lỗi trong tệp đó.
galexite avatar
lá cờ pk
Bạn có thể sử dụng `md5sum -c md5sum.txt | grep -v OK` trên thư mục gốc của ổ USB và xem tệp nào không được liệt kê là `OK` ở đầu ra?
laudai avatar
lá cờ bg
Kết quả kiểm tra là `./isolinux/isolinux.bin` KHÔNG ĐẠT. Nó là bình thường hay bất thường?
laudai avatar
lá cờ bg
Và tại sao rufus thay đổi tập tin của tôi?
laudai avatar
lá cờ bg
@galexite Cuối cùng, tôi kiểm tra [bài viết](https://help.ubuntu.com/community/LiveCDCustomization#Producing_the_CD_image) và xác nhận `isolinux.bin` đã được sửa đổi bởi `mkisofs -b`. Nó có thể khiến md5sum của `isolinux.bin` thay đổi sau khi sử dụng lệnh này. Không thay đổi bởi phần mềm rufus.
Điểm:1
lá cờ bg

Lý do tại sao gặp lỗi là tập lệnh md5sum trong Ubuntu LiveCD mạo từ.

Kịch bản này ngày nay sẽ tạo ra isolinx thư mục md5sum. Cái này không được băm trên hình ảnh 20.04.2 chính thức của Ubuntu. (Có thể wiki cần được sửa đổi. Bạn có thể thấy phần đầu của bài viết là ubuntu-18.04-desktop-AMD64.iso. Nhưng phần cuối của bài viết là ubuntu-9.04.1- máy tính để bàn-i386-custom.iso.)

Để tránh vấn đề này. Bạn có thể sửa đổi tập lệnh từ

tìm -type f -print0 | sudo xargs -0 md5sum | grep -v isolinux/boot.cat | sudo tee md5sum.txt #bản gốc

đến

tìm thấy . -type f -not -name md5sum.txt -not -path '*/isolinux/*' -print0 | sudo xargs -0 md5sum | grep -v isolinux/boot.cat | sudo tee md5sum.txt #mục đích của người khác

Trong vấn đề này. Nó không phải do vấn đề Windows rufus ESP gây ra. Mặc dù rufus có thể gây ra vấn đề tương tự. (như @Akeo đã nói. Bản cập nhật rufus trong 3.15. Trong phần này nhật ký thay đổi)

Điểm:0
lá cờ hk

Điều này là bình thường. Vấn đề là ở đó efi.img được ánh xạ tới ESP (Phân vùng hệ thống EFI), mà Windows sẽ cố gắn sau khi USB được tạo và khi thực hiện, nó sẽ tạo một Thông tin khối lượng hệ thống\ thư mục trong đó. Đây là một hành vi mặc định (đáng ghét) của Windows mà chúng tôi thực sự không thể kiểm soát được.

Kết quả cuối cùng là ESP được sửa đổi, có nghĩa là khởi động/grub/efi.img được sửa đổi và do đó tổng kiểm tra không khớp. tuy nhiên đây là một nhẹ vấn đề không phải là dấu hiệu của một vấn đề thực tế.

Rufus 3.15 mới phát hành đã cố gắng thêm các điều khoản chống lại việc Windows thay đổi ESP, để tổng kiểm tra Nên phù hợp, nhưng thực sự chúng ta chỉ có thể làm được rất nhiều điều để chống lại hành vi mặc định của Windows, và lý tưởng nhất là Ubuntu (và các bản phân phối khác) có lẽ sẽ tốt hơn nếu không cố gắng thêm nhiều bản hack ISOHybrid để ánh xạ một ESP vào một tệp được tổng kiểm tra, và thay vào đó chỉ cần sử dụng một Độc thân phân vùng, với EFI và nội dung cài đặt, khi hình ảnh được ghi ở chế độ DD...

galexite avatar
lá cờ pk
Cảm ơn bạn đã tạo Rufus, @Akeo! Cuối cùng, có vẻ như Rufus/Windows hoàn toàn không có lỗi và việc kiểm tra của Ubuntu chỉ đơn giản là chạy qua tệp `md5sum`, vì vậy có vẻ như nó không quan tâm đến các tệp bổ sung trên ESP. OP đã sửa đổi ISO của họ bằng `mkisofs`, và hóa ra, điều này đã tạo ra một `isolinux.bin` mới không khớp với hàm băm.
laudai avatar
lá cờ bg
@Akeo Cảm ơn bạn đã cống hiến cho Rufus. Như @galexite đã đề cập, đó là hàm băm `isolinux.bin` không khớp. Tất cả các thông tin đã được viết vào câu trả lời dưới đây.
Akeo avatar
lá cờ hk
Rất vui khi thấy bạn đã tìm ra nguyên nhân. Tôi đã đề cập đến vấn đề với `efi.img` vì trước đây tôi đã thấy vấn đề này dẫn đến việc xác thực tổng kiểm tra không thành công với các hình ảnh Ubuntu được viết ở chế độ DD, vì vậy nó có thể giúp ích cho những người khác gặp phải vấn đề này và thấy rằng đó là `efi của họ. img` không xác thực được.

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.