Vài tháng trước, tôi cuối cùng cũng giải quyết được "saga" BIOS read-only trên Lenovo G50. Bạn có thể đọc về vấn đề gốc, rồi giải pháp workaround đầu tiên của tôi, và cuối cùng, khi vấn đề thực sự trở nên phổ biến do "fiasco" (thảm họa) driver Ubuntu 17.10, giải pháp thực sự đến dưới dạng cập nhật kernel, và từ đó, UEFI của tôi hoạt động bình thường trở lại. Điều thú vị là, đây là vấn đề lớn hơn nhiều, không giới hạn ở Ubuntu, nhưng bị bỏ qua ngẫu nhiên một lúc lâu.
Bây giờ, trong khi chờ fix được tạo ra - không biết có bao giờ sẽ có, tôi thử tìm cách boot hệ điều hành mới trên Lenovo. Như đã nhắc, truy cập disk thô qua VirtualBox là một. Phương pháp khác, ít rủi ro hơn nhưng cũng ít hiệu quả hơn là: GRUB2 ISOBoot. Chúng ta sẽ thảo luận ngay bây giờ, vì có thể sẽ đến ngày bạn gặp (hoặc vẫn đang gặp) vấn đề BIOS/UEFI NVRAM read-only, và cần cách workaround, mà không có cập nhật kernel hay gì. Hãy tiến hành.
Khởi động (Boot up)
Khả năng boot trực tiếp từ file ISO là tính năng mới của bootloader GRUB2, và chúng ta sẽ khai thác nó để bypass việc không thể dùng removable media trên laptop. Tài liệu về việc sử dụng khả năng này khá ít, và như luôn và đúng đắn, biased (xu hướng) về Ubuntu, điều này hợp lý, vì nó là distro Linux phổ biến nhất. Vẫn thôi.
Dù sao, trước tiên, hãy đọc tutorial GRUB2 của tôi để quen với bootloader và cách nó hoạt động. Không có kiến thức đó, bạn sẽ không thể implement (triển khai) các gợi ý trong bài này.
Menu entry thủ công (Manual menu entry)
Tôi tin vào việc test thứ trước khi tự động hóa hoặc dùng công cụ hỗ trợ, vì như vậy bạn sẽ hiểu những gì xảy ra behind the scenes (đằng sau màn hình). Ý tưởng cơ bản như sau - bạn cần tạo script GRUB2 tùy chỉnh - hoặc dùng template có sẵn, trỏ nó đến file ISO liên quan trên một phân vùng trên ổ đĩa, mount ISO như loopback device, sau đó boot kernel và file initrd/initramfs có sẵn.
Chúng ta sẽ dùng script 40_custom, có sẵn dưới /etc/grub.d. Mặc định, file rỗng và chỉ liệt kê:
#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries. Simply type the
# menu entries you want to add after this comment. Be careful not to change
# the 'exec tail' line above.
Hãy tạo một entry và xem sao:
#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.
# Simply type the menu entries you want to add after this
# comment. Be careful not to change the 'exec tail' line above.
menuentry "<title>" {
set root=(<disk>,<partition>)
set isoname="<iso file name>"
set isofile="<path>${isoname}.iso"
loopback loop $isofile
linux (loop)<vmlinuz> <boot options>
initrd (loop)<initrd>
}
Chúng ta có gì ở đây?
Hãy xem script của chúng ta, nhé?
- Dòng đầu - title - chỉ định tiêu đề của boot entry cụ thể.
- Tiếp theo, chúng ta set root. Điều này nói cho GRUB biết trên phân vùng nào tìm các path liệt kê sau trong script. Lưu ý GRUB2 dùng notation (ký hiệu) hơi khác GRUB legacy và số phân vùng bắt đầu từ 1 chứ không phải 0.
- Chỉ thị thứ ba - isoname - chỉ định tên file ISO đã tải.
- Dòng thứ tư trỏ đến đường dẫn đầy đủ của vị trí file ISO. Chúng ta kết hợp dòng này dùng tên file ISO và hậu tố .iso.
- Lệnh tiếp theo nói cho bootloader mount file ISO như loopback device.
- Bây giờ, chúng ta load kernel - entry linux nên đọc là linuxefi trên hệ thống UEFI. Sau đó, chúng ta có một vài boot options bắt buộc, sẽ (buồn thay) khác nhau từ distro này sang distro khác. Cuối cùng, làm tương tự với initrd (lại là initrdefi cho hệ thống UEFI).
Vấn đề...
Vấn đề với cách tiếp cận này là hầu như mọi distro đều dùng phương pháp riêng để boot vào live session, bao gồm overlay filesystem, boot options, và hơn thế nữa. Không có cách đơn giản, thống nhất để boot bất kỳ entry generic nào. Lại nữa, nếu bạn xem các ví dụ có sẵn, bạn sẽ thấy sự khác biệt và phân mảnh khổng lồ trong không gian này - như mọi khía cạnh khác của Linux desktop.
Test Fedora
Tôi quyết định test với Fedora, vì ví dụ Ubuntu thực sự trivial (đơn giản). Đọc online, tôi tìm thấy ít nhất một chục tham chiếu trên họ F18-F27, mỗi cái liệt kê khác nhau một chút. Convention (quy ước) chung thu hẹp xuống, less or more (gần như):
menuentry "Fedora Live" --class fedora {
set root='hd0,msdos8'
set isofile="/home/roger/Downloads/
Fedora-Workstation-Live-x86_64-27-1.6.iso"
loopback loop $isofile
linux (loop)/isolinux/vmlinuz0 iso-scan/filename=${isofile}
root=live:CDLABEL=Fedora-Live rootfstype=auto ro rd.live.image
quiet rhgb rd.luks=0 rd.md=0 rd.dm=0
initrd (loop)/isolinux/initrd0.img
}
Tôi dùng ví dụ Fedora 27 mới nhất và hệ thống dual-boot với file ISO nằm trên phân vùng thứ tám (sda8). Sau khi thêm vào script tùy chỉnh, bước tiếp theo là cập nhật menu GRUB. Sau đó kiểm tra và xác thực file cấu hình GRUB được tạo có chứa entry của bạn không.
Test này không hoạt động - cũng như chục biến thể khác. Tôi cũng dùng UUID thay vì ký hiệu disk và partition, thử chèn các module khác nhau, và không cái nào cho phép boot đơn giản, seamless (liền mạch) file ISO non-Ubuntu.
Phương pháp không thủ công: grml
Cách tiếp cận dễ dàng hơn nhiều là dùng công cụ helper tự động thêm entry cho bất kỳ file ISO nào tìm thấy dưới /boot/grml. Cài đặt chương trình - sudo apt-get install grml, copy các file ISO liên quan, rồi chạy lệnh cập nhật GRUB.
Với phương pháp này, tôi có kết quả mixed (lẫn lộn) - một số distro boot được, số thì không. Nhìn file grub.cfg được sinh ra, lại không có convention chung, đơn giản về output nên trông như thế nào. Thảo luận, dù an toàn hơn dùng raw disk access trong VirtualBox, như tôi đã chỉ trong bài đầu tiên về chủ đề này, phương pháp ISOBoot ít khả năng hoạt động trong mọi trường hợp.
Các workaround khác
Không liên quan trực tiếp đến GRUB2 ISOBoot, nhưng có một vài công cụ khác bạn có thể cân nhắc. Một số là gợi ý từ độc giả, và tôi muốn cảm ơn họ vì sự giúp đỡ và đóng góp chân thành, vì họ cố gắng giúp tôi sửa laptop.
Khuyến nghị chính thức của Lenovo là thay mainboard. Điều này sẽ hoạt động, và bạn có thể muốn thử - nhưng chỉ sau khi cạn kiệt mọi giải pháp dựa trên phần mềm. Chúng rẻ hơn, và bạn luôn có thể fallback (quay lại) phần cứng. Và như chúng ta đã thấy, cập nhật kernel đã giúp, nên đã là lãng phí tiền thay mainboard ngay lúc đó (đó luôn là lựa chọn, và nên là cuối cùng).
Gợi ý phần cứng khác (khá expert) là thử flash image UEFI sạch trực tiếp lên chip của laptop, dùng USB SPI programmer được hỗ trợ bởi công cụ flashrom. Tôi chưa thử, nhưng đây là điều bạn có thể cân nhắc, nếu bạn ultra-bold (rất lớn gan) và savvy (am hiểu).
Một sub-lesson (bài học phụ) của câu chuyện này là việc chờ đợi là tốt. Trong trường hợp tôi, tôi kiên nhẫn chờ khoảng 4 tháng. Tôi không vội vàng chi tiền sửa phần cứng, hay mua laptop mới. Tuy nhiên, tôi hiểu rằng trong một số tình huống, bạn có thể không có lựa chọn.
Các tùy chọn khác, theo thứ tự ưu tiên giảm dần nên là: 1) Flash firmware BIOS/UEFI nếu có 2) Sử dụng boot manager rEFInd, thay thế GRUB; với chút hacking (có thể khám phá chi tiết một ngày), bạn có thể workaround thành công các hạn chế do BIOS/UEFI read-only gây ra 3) Một số chương trình quản lý UEFI khác như EasyUEFI 4) một cuốn sách cầu nguyện, mà với hầu hết geek sẽ là manual Python.
Hãy thảo luận điểm倒数第二 (thứ hai từ cuối) chi tiết hơn. Đây là chương trình dựa trên Windows, và có thể dùng để quản lý EFI bootloader, bao gồm enable/disable entry, thay đổi thứ tự entry liệt kê, và dọn dẹp item disabled.
Lệnh cleanup này có thể giúp NVRAM của bạn cooperate (hợp tác) (có lẽ). Trong menu chính, thử disable một entry, hoặc nếu bạn đã có vài cái ở trạng thái disabled, bạn có thể thử tùy chọn cleanup. Trong trường hợp tôi, nó không hoạt động. Tool ném ra system API error, có lẽ không khác gì interrupted system call issue chúng ta thấy trong báo cáo ban đầu về vấn đề. Đừng đặt hy vọng quá cao, nhưng nó có thể hoạt động cho bạn tốt hơn tôi.
Tôi muốn cảm ơn aigle, Ivan, L., Neal, Marcin, Richard, Nik, Floris, zloster, Georg, và Matthew vì gợi ý, ý tưởng, sự khích lệ qua cuộc phiêu lưu. Vì vấn đề đã được giải quyết, tôi sẽ không thể tiếp tục các công cụ hoặc cách khác để giải quyết, và với những gì bạn có ở trên, cộng với cập nhật kernel, cộng với VirtualBox raw disk access, bạn nên ổn.
Kết luận
Khi bạn đối mặt với tình huống phần cứng kỳ lạ, như chúng ta có ở đây, không có guarantee (bảo chứng). Trong bài workaround đầu tiên, tôi nhắc VirtualBox và raw disk access. Điều này chắc chắn hoạt động, nhưng rủi ro khá cao. Phương pháp ít intrusive (xâm lấn) hơn là thử boot từ file ISO dùng GRUB2, chủ đề hôm nay. Test của tôi cho thấy cách này ít successful (thành công) và effective (hiệu quả) hơn, nhưng cũng mang ít rủi ro hư hỏng dữ liệu ổ cứng. Cuối cùng, bạn có thể thử một số công cụ khác, và chúng ta sẽ khám phá thêm một số trong tương lai.
Hiện tại, gợi ý của tôi là - nếu cập nhật kernel không hoạt động cho bạn VÀ bạn không thực sự phải thay đổi setup hiện tại VÀ nó hoạt động tốt cho bạn - hãy để nó như vậy. Đối với tôi, đây là vấn đề dùng 8 hệ điều hành, nhiều hơn đủ cho một test box, và tôi vẫn có thể thực hiện in-vivo upgrades, nên chờ fix kernel cũng ổn. Nếu bạn muốn thử dùng thêm hệ điều hành mà không sửa phần cứng, bạn có vài workaround và semi-solution để cân nhắc. Tôi ước có thể cho bạn recipe (công thức) 100% foolproof 100% applicable, nhưng đó không bao giờ là trường hợp trong chiến tranh giữa phần mềm và phần cứng. Take care.
Cheers.