[gentoo-amd64] Re: Problem with USB-Keyboard at Install

[Duncan]

Mark Knecht <markknecht@×××××.com> posted
5bdc1c8b0908030920p36508cf8n8b95915c367a18e6@××××××××××.com, excerpted
below, on  Mon, 03 Aug 2009 09:20:35 -0700:

> Duncan<1i5t5.duncan@×××.net> wrote:
>> Mark Knecht <markknecht@×××××.com> posted:
>>> Lance Lassetter<lancelassetter@×××××.com> wrote:
>>>>
>>>> Have you tried enabling evdev in make.conf under INPUT_DEVICES?
>>>
>>> How could he do this when he's trying to boot from an install CD?
>>
>> Hmm, mount the ISO using loopback, make the change, umount, burn?

>    So I guess you are suggesting that someone doing a Gentoo install,
> and finding that the install CD fails to work, is then possibly going to
> modify the install CD?
>
>    Beyond that what make.conf are we speaking about? As I asked over
> the weekend, and as far as I can tell, there is no make.conf on the
> install CD to modify. (With the keyboard we don't have because we're
> running USB unless this is a completely different installation on the
> same machine, or we're doing it on a different machine.)
>
>    Maybe I'm underestimating INPUT_DEVICES but I thought that was only
> for xorg-server which isn't running when the install CD finishes booting
> is it? Even if the OP had done what you suggested, had enough knowledge
> of Gentoo to think about creating a make.conf file and placing "keyboard
> mouse evdev" in it, burned a new copy, and then rebooted, what changes
> about the environment that is running at that point?
>
>    I'm really confused and I know this because you are, no joke here,
> one of my Gentoo guiding lights! Enlighten me! Please!

Your points are valid (well, I'll take that guiding light thing at face 
value, thanks, but the rest anyway is valid, AFAIK), but that's not 
really what I was commenting on.

Seeing as he had already solved the problem, I was jumping into less 
serious mode, and the bit about not writing to a CD struck my fancy.
As it happens, I do pretty much just what I described with a floppy image 
when I update my BIOS.

My board's BIOS update is designed to install from DOS (it's a several 
years' old server board, after all), but I'm MICROS~1 free, so the first 
BIOS update I did I had to find a different solution.  What I came up 
with was a FreeDOS 1.44 MB floppy OEM image, just the basics, no high 
memory stuff or anything else that might interfere with the BIOS update.

So then I had a 1.44 MB floppy image, but the DOS binaries, etc on it 
only take a couple hundred KB, the rest is free space, but in the image, 
and a second set of files including the BIOS update *.bin image the DOS 
based updater executable, and a DOS batch file that together are smaller 
than the free space on my bootable FreeDOS image, but shipped separately 
in their own 1.44 MB floppy image.

Well, rather than write out two separate floppy images to actual 
floppies, I simply mounted the BIOS update one using the loopback and 
copied the files to my main system's filesystem, then umounted that 
image, now leaving me with separate files and my FreeDOS image.  Then I 
mounted the FreeDOS image read/write on the loopback and copied the 
update files over to it, let it finish the write, and umount.  Viola!  
Single bootable FreeDOS floppy image, now including the BIOS update files 
I needed.

I could then copy that image directly to a floppy using dd, write protect 
it, boot the floppy, and do my update.  Since that point I've updated the 
BIOS further another time or two, only now I already have a proven 
bootable image, so I don't have to download a new version of FreeDOS, 
only the BIOS update, then use a similar procedure to copy the new files 
to a fresh copy of the FreeDOS image, and overwrite my old floppy with 
the new combined image.  (Given floppy technology, I trust overwriting 
then verifying the new image in its entirety, far more than I would 
simply deleting the old update files directly on the floppy and adding 
the new ones.)

I've done the same thing with CD/DVD ISO images as well, only since 
they're cheaper and faster to write than CD-RW/CD+RW, I use burn-once 
discs, and just burn a new one if I need to make changes to the ISO.

So when I saw a post that to me implied that the ISO was read-only, I 
simply pointed out that the ISO could be mounted on the loopback and 
modified that way before actually burning it.  Just because it's an ISO 
image and we're used to thinking of them as CD/DVDs, and used to thinking 
of CD/DVDs as write-once, doesn't mean that the ISOs themselves can't be 
modified before they are burned.  That's really all I was pointing out.

So the bit about whether the file in question was actually there on the 
ISO image to modify, or whether having put it there, it'd actually be of 
any use (whether there was an xorg setup to run on the ISO at all), was 
really beside the point for me.  That wasn't what I was concerned with, 
especially since I'd seen that the problem was already solved.  I was 
simply pointing out that an ISO image isn't necessarily read-only data, 
and that it /can/ be modified.  Realizing that at some point many years 
ago was an epiphany of sorts for me, and given what seemed an implication 
that it couldn't be done, I was simply passing on that hey, ISOs CAN be 
modified. =;^)

Clear as mud?  =;^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman