21.05.2017 21:41, Ineiev пишет: > On Sun, May 21, 2017 at 08:39:09PM +0300, Andrei Borzenkov wrote: >>> >>> I tried `insmod ehci` anyway. Interestingly, the grub environment is sort >>> of broken after that, because the disk is gone after the insmod command. >>> Like, before that if I `ls`, it shows "(hd0), (hd0, gpt1), (hd0, gpt2), >>> (hd0, gpt3)"; and after that if I `ls`, it prints a blank new line. (I am >>> on a system that has one single drive which is a USB drive). >> >> Which is correct. Loading direct hardware drivers disables native >> platform drivers. >> >>> >>> It seems to me like if I load ehci, the current host controller driver is >>> replaced so grub can no longer see the USB drive it is on. However there is >>> not an "xhci" module, so I wonder what was being replaced. >>> >>> And if my assumption is true, why would usb_keyboard not work while the >>> storage drive works? >>> >> >> Because storage driver is using UEFI services by default (or in general >> on every platform grub prefers using native firmware to access devices). >> Why do you need usb_keyboard in the first place? Does native UEFI >> console access not work for you? > > Coincidentally, I'd like to extend the protocol of usb_keyboard; most > probably, native firmware won't do. is there any documentation about > what modules are needed (no, I don't use USB drives)? >
If you do not use USB drivers you cannot use usb_keyboard either.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Help-grub mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-grub
