Re: New scratch build of boot-floppies (UP1000, serial console, TFTP)
David Butts <dbutts@bbn.com> writes:
> the images. I suspect that I just need a sound beating with a clue
> stick... any volunteers?
No, you own a Multia. It's not your fault :)
> Just out of curiosity, is the console=ttyS0 option a new feature of
> the kernel, or was it always there?
It's not really a feature ... on Sparc, the kernel can automatically
detect if the console is a serial line by asking the firmware, but
there doesn't seem to be any way to do this on Alpha, and therefore
you have to tell the kernel that the console is ttyS0.
> I have a bootp/tftp server running on a Sparc Classic (frozen, thanks
> again :), and I renamed tftpboot.img and put it in /tftpboot. I've set
> ewa0_protocols to bootp on the UDB and configured bootp on the classic
> with the UDB's ethernet address and related information. When I run a
> 'boot ewa0', it grabs the tftpboot.img fine, but, when it's done, the
> SRM console resets. It looks like its generating some errors, but they
> scroll past too quickly for me to see. Unlike the DS10 hangs mentioned
> below, this seems to be quite consistent.
Urgh. It definitely works on my DS10 (more or less). You should use
a serial console, then you can scroll back to see those errors in
minicom (or whatever). Please report them so we can possibly figure
out what the problem is.
> Am I correct in assuming that the boot file (bf) in bootp should
> be the tftpboot.img (as renamed)?
Yes.
> Is the root.tar.gz file needed on the server, and, if so, where?
> If it is needed, does the fact that it "isn't particularly useful"
> preclude booting over the network?
The root.tar.gz isn't useful on alpha, because we don't have a
netbootable kernel image in the boot-floppies yet. On sparc, you'd
untar it into an NFS root directory (specified using rp: or 'option
root-path' in bootptab or dhcpd.conf respectively), then netboot using
a netbootable kernel image.
How were you booting on your Multia previously? Have you installed
the latest firmware updates? It may be that the firmware on it is
just brain-damaged...
--
David Huggins-Daines, Senior Linux Consultant, Linuxcare, Inc.
613.562.1239 desk, 613.223.0225 mobile
dhuggins@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.
Reply to: