[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

some hamm install notes

A few days ago I tried doing an install of hamm on a 166MHz NoName
almost from scratch (already had milo in flash mem from previous
redhat install, but I repartitioned the disk and rebuilt the file
systems).  Here are some notes I've got from the attempt.  Some of
it's not specific to the Alpha port, but maybe some of it will help
for updating the install directions or mechanism.

Based on some comments I read here, and heard elsewhere, I:
 * used 1997-08-12 disks but put the October kernel on it (which
   required having a running Linux system, not good)
 * rebooted after running cfdisk (I've heard the changes may not take
   effect right away, at least in the RH install) and restarted the

Since I already had MILO in flash rom, I didn't set up a partition for
it nor build a floppy; just booted the resc1440 (not "rescue...")
disk.  (Is there a reason to prefer loading MILO from disk, now that
I've already got it in flash memory?  Should I attempt to get the DEC
console code restored?)

The bootup and initial install steps went just fine, though it seemed
to spend a lot of time in "examining the system to decide what to do
next" mode.

Since I don't have a cd-rom of hamm nor a local mirror, I wanted to do
the install by ftp, straight from ftp.debian.org.  I didn't see
anything that told me not to, and I certainly didn't want to do it all
by floppy.  But ftp wasn't on my system after I finished with base14-1
through -6.

So I wound up using floppies to transfer netbase, netstd, bash,
libreadline2g, and, um, maybe one or two others, installing them with
dpkg before I could use ftp in dselect.  I had to force dpkg to
upgrade bash and install libreadline2g, because the old bash needed
libreadline which conflicted with libreadline2g which was needed by
the new bash.

The floppy install gave me some "required" packages (e.g., getty)
which I promptly wound up replacing with different required packages
off the ftp site.  Since bo has no alpha distribution, wouldn't it
just be easier to "pre-install" the new versions of the packages?  I
assume (well, hope) there's some install-package-builder package
somewhere, which would've been set up for installing bo, but shouldn't
it be getting updated for hamm?

I haven't found any directions to tell me what options to give to the
ftp install method so that I can install hamm.  I gave it the
directory /debian/dists/unstable on ftp.debian.org, and told it to
look for "main contrib non-free", which worked fine for fetching the
Packages files, but I had to edit the "vars" file squirreled away by
the ftp method to change that path to /debian before fetching the .deb
files, otherwise it complains that it can't find the files; apparently
it thinks it needs to fetch "dists/unstable/...."

So maybe I should've just told it "/debian", but then how would I tell
it where to find the Packages files?

I had experimented with this while trying to update an x86 system to
hamm, and this was the closest to a satisfactory solution I came up
with.  Maybe I'm just missing something....

Through the whole install procedure, and since, the kernel's been

	kernel: unaligned trap at fffffc00003660b8: ....

type messages at me, generally in groups of four (addresses ..5f54,
6010, 60b0, 60b8).  It's probably just one bad driver, but I haven't
tracked it down yet.  Is there any way to redirect the messages to a
different VC, or just the log file, or (less desirable) turn them off

As far as I can see, dselect makes no log file with the dpkg output,
only the console output.  So after it's tried installing a hundred
plus packages, I don't know why the sixth one didn't install properly.
The kernel messages coming up make it even more difficult to scroll
back, read stuff and take notes.

Package ldso wants libc6 which isn't there.  Package libc6.1-dev wants
gcc which wants binutils-alpha which isn't there.  Then several other
packages refuse to install after that.  A couple iterations through
"install" and "configure" steps seemed to resolve some of that (which
suggests the installation order isn't being determined properly?).  I
deinstalled ldso and forced the installation of gcc, and the rest
pretty much went smoothly (except for dselect always complaining to me
about binutils-alpha not being there).

What's the deal with ldconfig?  It was "preinstalled" by the install
procedure as part of the ldconfig package, but now I've gone and
deleted it (hey, it's described in dselect as optional, and there's no
version available now).  That package doesn't exist any more, but my
system really wants it.  Luckily I found the mail from Roberto
Lumbreras, referring to an ftp site where he'd packaged it up.  How
about putting it on the master ftp site, or fixing up the ldso package
to have it?

It's been three weeks since Roberto's mail, but this hasn't been
fixed.  If it's just a matter of recompiling, I can do it, but I don't
know if there's anything else going on I should know about.  (Sorry,
haven't been keeping very close tabs on the mailing list.)

The ncurses3.0 package is listed in dselect as optional, yet dpkg
refuses to remove it because (it says) it's required.

My Linksys 10Mb/100Mb network card seems to have been properly
detected as being connected to a 10Mb network, which is much better
than the RH install I tried; that kernel always thought it was in
100Mb mode.  The Debian kernel is using the tulip driver, whereas the
RH kernel used the de4x5 driver.

I got ssh built, but running "more" over an slogin session seems to
leave my xterm displaying reversed-video text.  And the delete key
tends not to work.  I've also seen the upper-case text problem
previously mentioned on the list when I run xterm on the alpha itself.

That's my experience so far.  Now I'm trying to rebuild some software
I didn't think to keep around from my previous installation....


TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-alpha-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .

Reply to: