Re: some hamm install notes
This is sounding pretty familiar. I went through all this the last
couple of weeks as well. I'll respond where I can. I've snipped the
rest; that doesn't mean those parts are silly (it probably means that I
have the same question :-)
On Tue 24 Feb 1998, Ken Raeburn wrote:
> * rebooted after running cfdisk (I've heard the changes may not take
> effect right away, at least in the RH install) and restarted the
> installation
AFAIK this only happens if some partition on the disk is already in use.
> 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?)
IMHO leave MILO in flash. I understand that doing that saves some memory
(MILO doesn't have to remain resident).
> 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.
Hmmm, didn't notice that on my XLT-300 :-)
> 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.
I got the impression that simply doesn't work yet. I *have* created
a local (sub-)mirror. Luckily on the boss's dime.
> 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?
Yes, I fullheartedly agree here. However, maybe wait to see what the
i386 people are doing with their boot floppies? I gather they've just
released a 2.0 version.
> Through the whole install procedure, and since, the kernel's been
> spewing
>
> 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
I've tracked it down to something like ip_recv in net/ipv4/ip_input.c.
However, I have no idea what to do about unaligned traps :-( It
dissappeared after I built and booted a 2.1.87 kernel.
Can anyone explain what a piece of code that does that looks like, and
what needs to be changed to fix that? I've noticed that vim also
generates an unaligned trap upon startup, and I'd like to have that
fixed as well...
> different VC, or just the log file, or (less desirable) turn them off
> altogether?
Doesn't it go through syslogd?
> 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.
Yeah. I usually simply end up trying the install with dpkg -i by hand,
so that I can wee what goes wrong. Suboptimal. This is a generic dselect
problem, and AFAIK no one is actively working on dselect :-(
> 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
I think the order is not being determined at all :-(
Fixing the boot and base floppies to provide a consistent base for the
rest to build upon would help greatly, I suspect.
> 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.
There's a new XFree on the ftp sites now that has at least the xterm
fixed (at least, that's what it said in the debian-changes digest).
Paul Slootman
--
home: paul@wurtel.demon.nl | work: paul@murphy.nl
http://www.wurtel.demon.nl | Murphy Software, Enschede, the Netherlands
--
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: