On 1 December 2010 00:32, Phil Meyer<pmeyer(a)themeyerfarm.com>
> On 11/30/2010 04:32 PM, Chris Northwood wrote:
>> Hi there,
>> So, I'm having a problem with my Fedora 14 setup. I've recently
>> installed the distro on the machine, and set up full disk encryption
>> using the standard method in Anaconda. However, on the passphrase
>> screen (the one which appears as the OS starts), any input on my
>> wireless USB keyboard (this one:
) doesn't work -
>> there appears to be no response to input from the keyboard. If I
>> connect a wired keyboard (this isn't a long-term solution, however -
>> the box is to become a media server, hidden behind my TV), then I can
>> enter the passphrase and continue just fine - once I get to the normal
>> user login screen, then I can enter my password and log in then. I
>> don't believe it's a BIOS problem as I can use the keyboard to
>> navigate around the BIOS setup screens no problem.
>> I did set up my machine using the wired keyboard, and only changed to
>> the wireless one at a later date, so I'm wondering if some relevant
>> kmod is missing when it's required, or something like that.
>> Any help to get my wireless keyboard up and running so I can enter my
>> passphrase with it would be much appreciated!
>> Chris Northwood
> Best Guess:
> By not having the wireless (USB dongle, I am assuming) when installing,
> the system did not put the USB human interface drivers in the initrd file.
> You can easily run dracut to correct that.
> You may want to substitute values in my example just to be sure ...
> # cd /boot
> # dracut --force initramfs-`uname -r`.img `uname -r`
> Next time you reboot you should be fine, or next time you get a kernel
> update from yum it will also get 'fixed' as long as the wireless
> keyboard is plugged in when you do it.
> Good Luck!
Thanks for the advice, but after manually recreating the initrd then
the same still occurs. My wired keyboard is also USB, so I don't think
it's that. I dug into it some more and checked dmesg - my
keyboard/mouse aren't getting recognised until after LUKS. Apparently
the module I'm interested in is hid_sunplus. I tried manually adding
that to the initrd with Dracut using:
dracut --force --add-drivers hid_sunplus initramfs-`uname -r`.img `uname -r`
Which works! Now, I believe I have an issue where the next time
there's a kernel update, this will be lost. So I guess the question
is, how do I make sure this is included in future initramfs
generations (or is this a bug in initramfs generation?)
Good you found the issue!
drakut is supposed to obey modprobe suggestions automatically, so I
would suggest making a /etc/modprobe.d/my_keyboard.conf file and just
add an alias to force the module to load.
From then on any future run of drakut should include it, which you can
test pretty easily.
Just run 'dracut /tmp/intiramfs.mytestfile `uname -r`', to an alternate
file, like /tmp/intiramfs.mytestfile, then cd to /tmp and 'gunzip -dc
intiramfs.mytestfile | cpio -icvdmu' and look in the results for your