Re: New scratch build of boot-floppies (UP1000, serial console, TFTP)
Hello, again-
Thanks for the fast response!
For those of you not looking for suspense, the short answer is that I've
now got it up and running, after ~12 hours of fighting with it. More on
that later :)
On 25 Mar 2000, David Huggins-Daines wrote:
> 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 :)
Of course I am the one who salvaged it from a co-worker's basement
and decided to try to make it useful...
> > 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.
*nod*
I keep meaning to look more closely at the various SRM HOWTOs and FAQs
to see whether I can get the SRM console to run on ttyS0 as well. From
looking at some of the existing environment variables, it seems like I
should be able to...
> > 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.
After much scrutiny, I have decided that the SRM console is rebooting
just before aboot would have started (or, at least, just before aboot
would have given its first line of output). To my untrained eye, it
seemed almost as if aboot weren't where it was expected to be, but,
given that you've gotten it to work on your machine, that seems pretty
unlikely. Could it me an issue with the amount of available memory?
All the recent milos I've found complain that I don't have enough RAM
and them fail to boot... In any case, it certainly wasn't dumping any
registers or anything.
Interestingly, Nikita's earlier tftpboot.img does work, and allowed me
to boot. I'm too lazy to quote the earlier message, but here's the
location: (ftp://genie.ucd.ie/pub/alpha/test/tftpboot.img)
> 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...
*grin*
I expect that the floppy drive is just really marginal, but that the
higher-level environments have enough error correction that they can
cope. A lot of the docs I found out on the web discouraged upgrading
the ARC firmware. Is the SRM firmware better (or at least better-
maintained)?
Here's the history (for the past few weeks) of this particular Multia:
When i got it, it had a milo disk in the drive (linload.exe, milo and
linux), and a seriously hosed copy of RH 5.1 on the hard drive.
In an attempt to preserve what little functionality it had, I stuck
with MILO for the time being, but I haven't managed to get any MILO
since that one to boot the system (they all report that I don't have
enough memory). What I ended up doing was booting the system to
MILO off the old RH milo disk, and then, from there, booting the kernel
off of a 2.1r4 rescue floppy. From there, I did a floppy base install
and essentially left it. In order to get it to boot from the hard
drive, I did a dd from the original MILO disk to a 5MB /dev/sda1. I
wasn't proud of it, but didn't have any other immediate way to get a
FAT partition on the disk :)
But the real fun was getting potato on it this time.
I got the same basic problems as Brian Macy did with his UDB, namely
the install not recognizing vmlinux because it wasn't compressed, the
fact that aboot didn't install automatically, and the fact that I
couldn't reboot the system from within dbootstrap. In my case, they
were more interesting, because my floppy drive is clearly not useful
from the SRM console (although ARC, MILO, and linux are all much more
tolerant). I had to boot to the original MILO disk from ARC, put a
copy of your 03/19 kernel on another DOS floppy (score another one
for the Classic), and booted that kernel (which could read the BSD
disk label) with root=/dev/sda2.
The copy of the kernel I ended up with after the base-install didn't
recognize the ethernet card, either. If I were thinking more clearly,
I would have a better idea of where that kernel (vmlinux-2.2.14) came
from, but I rather suspect it's an artifact of the older tftpboot.img.
In any case, The kernel on your 03/19 rescue disk seems to be working
admirably in its place. On a related note, is it safe to assume that
the aboot and kernel living on the boot block will survive an fdisk,
as long as they aren't explicitly overwritten by one of the new disk
slices? If so, does it make sense to recommend that all subarchs,
not just jensen, reserve space for both, in order to provide a more
complete failsafe, or is that just too paranoid (or, more to the point,
too great a change this late in the game)?
One thing I have noticed that seems conspicuously absent, however,
is pcmcia-module-xxx. ISTR one of the earlier messages to this list
was asking about doing driver development on an Alpha, so I'm hoping
that the modules can be had somewhere, but I haven't found them. Do
I have to compile them from pcmcia-source? I've got a pcmcia modem
in the Multia that I'd like to get set up at some point.
In any case, I'm hopelessly sleep-deprived, and have rambled for far
too long.
My thanks again to you, David, and to Nikita, and everybody else
whose names I haven't yet associated with a solution to one of my
(many) problems.
David
Reply to: