Re: R: ADM64 floppies

> Sorry Bill, I surely didn't mean to be rude not giving any feedback about
> the USB keyboard issue.
> 
> Actually I wasn't able to try it because of a couple of reason. Since
> tomorrow is holiday we worked only half day today and I had some more
> deadline to do before of 31/12.
> 
> Anyhow the problem is that the whole installation has got a lot of "dark
> issues". Let me try to summarize the problems, mainly because I'm the first
> who tends to lose the focus.
> 
> I tried the followings:
> 
>  * FreeBSD 6.0-CURRENT i386 from CDRom: the system won't boot because the
> IBM HS20 has got an USB CDRom... after loading the first step (the Bios
> part) the loader says it's unable to locate a valid Kernel thus it stops.

I'm a little confused: does it actually make it to the intro menu? Are
you able to get it to the OK prompt so you can type commands? If so,
Did you try to do "ls" from the OK prompt in the bootloader to see if
it can access the CD-ROM at all? When the loader starts up, it should print
a list of BIOS disk devices that it recognizes. Is the CD-ROM listed
there somewhere? What devices _are_ listed? Have you verified that the
loader is accessing the right one? When the BTX loader initializes, it
should print something like:

BIOS CD is cd0
BIOS drive C: is disk0

This is very early on during the CD bootstrap phase, before the
intro menu appears. You can also check what devices are visible
by getting to the OK prompt and doing:

OK lsdev

The CD should appear as a device.

Note: if the CD doesn't appear, don't just say "there's no CD
device." Tell us what you _DO_ see, because we're not there to look
over your shoulder.

Since it's a USB CD-ROM, the BIOS in the system is doing some trickery to
let you access it as a bootstrap device (my Sony VAIO does similar trickery
for a PCMCIA CD-ROM). It should make it appear as a valid BIOS drive. It
should be working to some extent since the bootloader runs partway. Is
there an option in the BIOS configuration that controls how the USB CD
is turned into an emulated BIOS CD device? (Like, maybe a 'legacy USB'
selection?)

> had no suggestion on how to fix this, but I'd love to have one. To answer to
> some of your question, the machine doesn't allow me to plug any kind of IDE
> CDRom. It's a "Blade" machine, that means that is nothing more than a
> Notebook's main board with a special case inserted in a Blade Center
> alongside 13 more blades. All the blades share the same CDRom and same
> Floppy, and you can decide which machine should have the CD and FD plugged
> to with a switch on the front. So my decision was to go for a Floppy-boot
> and then start a network install from ftp.freebsd.org trough our internal
> proxy who already got "proxied" almost 80% of the base installation (because
> we always install our machines like this).
> 
>  * FreeBSD 6.0-CURRENT i386 from Floppies: this time everything boots ok.
> The kernel starts ok and mainly probe all the Hardware ok. After the kernel
> loads, when Sysinstall starts the keyboard stops working. As someone
> suggested this probably is an issue with the USB keyboard not getting the
> right priority over the PS/2 one (that is not connected). So I tried using
> the "7th" option from the Bootloader menu that says "Start installation with
> an USB keyboard" that, AFAIK, should mean it automatically does the "set
> hint.atkbd.0.disabled=1" stuff. If that isn't true than that was a wrong
> assumption I made.

Yes, your assumption was wrong. The "7th" option does something else.
I think it's "set hinds.atkbd.0.flags=1". Unfortunately, this only handles
the situation where you have a system with a USB keyboard _only_ and no
trace of atkbd whatsoever. I've had people insist to me this is the
right option to use too, yet it didn't work for me either. On my Opteron
system, the FreeBSD/amd64 kernel doesn't attach atkbd0 so it happens to
work withoyt any intervention, but FreeBSD/i386 stubbornly clings to
the notion that there should be an atkbd0 device, and unless I explicitly
disable it with hint.atkbd.0.disabled=1, that non-functional atkbd0 device
becomes the default keyboard and I'm stuck. When I first ran into this
problem, I got around it by installing using the serial port as a console.
For that, you need to break to the OK prompt during boot and then do:

OK set console=comconsole

This will switch you over to COM1 as the console. You need to immediately
go to the serial console and type "boot" to resume booting. From that
point on, the installation will take place via serial port. When the
install is done, it'll automatically add a line to /boot/loader.conf
that says "console=comconsole" so the system will 'remember' that you
want to use serial console mode for all subsequent boots.

NOTE: while sysinstall is smart enough to edit /boot/loader.conf for
you, it is _NOT_ smart enough to edit /etc/ttys for you too. Hence,
when the system boots, you won't get a login prompt on the serial
console. To fix this, you should boot the system in single user mode
after sysinstall is done, then do:

# mount -u -w /
# mount /var
# mount /usr

Then edit /etc/ttys to set the state of ttyd0 to "on" instead of "off"
so that init(8) will spawn a getty(8) on ttyd0.

> I will try to do that manually as soon as possible (that
> is 2/jan/2006 as of now). Anyhow, booting with "7" made no difference at
> all. As soon as Sysinstall starts, I loose the keyboard. Digging in the
> archives of this list I have found that someone already reported having this
> problem and he wasn't able to solve it as well becase, for what he said, the
> blade has got TWO USB keyboard connected. One that is the one on the local
> console, and the other one being the remote console (that is accessible via
> a web interface). So maybe FreeBSD is correctly using the USB keyboard, but
> not the correct one... :? So my next guess would have been trying to use the
> web interface and see if the remote console was working. The only problem is
> that my machine is a FreeBSD machine as well and I haven't (yet) installed
> Java on it, so I can't access the remote console (and being pre-holiday
> today none of my windows-based colleague was in the office).

The application that connects to the remote console is java? You're
sure there's no way to access it directly via telnet or something?
That's very lame.

> As a final note, a couple of persons told me to try with a PXE remote
> installation. That, alongside the serial-console one, is one of my next try
> (probably the latter first). The only thing is that I don't want to finally
> succeed in installing i386 only to discover I needed amd64, right? :-)

Well, the system will still work with FreeBSD/i386. It just won't be
as sexy.
 
> So to come to an end, you said something I already tought: copying the amd64
> tree and pretend it to be the i386 and installing it with the i386
> installer. But since I wasn't even able to use the keyboard in sysinstall
> that was something I left to investigate later. The only question is whether
> there's a way to have Sysinstall fetch the other branch by himselft from the
> FTP site, maybe by specifying some strange "set hint.thisplatformis = amd64"
> or something.... ?

When you get to the screen where sysinstall asks you what media to
install from, tell it to use a custom FTP URL, then specify a path
that points to the amd64 distribution instead of the i386 one. The
process of partitioning the disk and creating filesystems should be
the same for both i386 and amd64: the difference is it'll load the
amd64 files intead of the i386 ones. I would start by just loading
the base OS at first, just to make sure you can actually produce a
bootable, working system: once you get the system bootstrapped, you
can install packages with pkg_add later.

-Bill

--
=============================================================================
-Bill Paul            (510) 749-2329 | Senior Engineer, Master of Unix-Fu
                 wpaul_at_windriver.com | Wind River Systems
=============================================================================
              <adamw> you're just BEGGING to face the moose
=============================================================================